From: Simone Piccardi <piccardi@gnulinux.it>
Date: Fri, 1 Apr 2011 16:21:08 +0000 (+0000)
Subject: Passaggio a UTF-8 dei sorgenti
X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=193d612d40c5f81f5559ea6e11e70f6b6e51fb39;p=gapil.git

Passaggio a UTF-8 dei sorgenti
---

diff --git a/build.tex b/build.tex
index a9f8b30..5b5d460 100644
--- a/build.tex
+++ b/build.tex
@@ -17,7 +17,7 @@ che vengono utilizzati per programmare in ambito Linux, ed in particolare gli
 strumenti per la compilazione e la costruzione di programmi e librerie, e gli
 strumenti di gestione dei sorgenti e di controllo di versione.
 
-Questo materiale è ripreso da un vecchio articolo, ed al momento è molto
+Questo materiale è ripreso da un vecchio articolo, ed al momento è molto
 obsoleto.
 
 
@@ -28,7 +28,7 @@ Il comando \texttt{make} serve per automatizzare il processo di costruzione di
 un programma ed effettuare una compilazione intelligente di tutti i file
 relativi ad un progetto software, ricompilando solo i file necessari ed
 eseguendo automaticamente tutte le operazioni che possono essere necessarie
-alla produzione del risultato finale.\footnote{in realtà \texttt{make} non si
+alla produzione del risultato finale.\footnote{in realtà \texttt{make} non si
   applica solo ai programmi, ma in generale alla automazione di processi di
   costruzione, ad esempio anche la creazione dei file di questa guida viene
   fatta con \texttt{make}.}
@@ -38,42 +38,42 @@ alla produzione del risultato finale.\footnote{in realt
 \label{sec:make_intro}
 
 Con \texttt{make} si possono definire i simboli del preprocessore C che
-consentono la compilazione condizionale dei programmi (anche in Fortran); è
+consentono la compilazione condizionale dei programmi (anche in Fortran); è
 pertanto possibile gestire la ricompilazione dei programmi con diverse
 configurazioni con la modifica di un unico file.
 
 La sintassi normale del comando (quella che si usa quasi sempre, per le
-opzioni vedere la pagina di manuale) è semplicemente \texttt{make}. Questo
+opzioni vedere la pagina di manuale) è semplicemente \texttt{make}. Questo
 comando esegue le istruzioni contenute in un file standard (usualmente
 \texttt{Makefile}, o \texttt{makefile} nella directory corrente).
 
-Il formato normale dei comandi contenuti in un \texttt{Makefile} è:
+Il formato normale dei comandi contenuti in un \texttt{Makefile} è:
 \begin{verbatim}
 bersaglio: dipendenza1 dipendenza2 ...
         regola1
         regola2
         ...
 \end{verbatim}
-dove lo spazio all'inizio deve essere un tabulatore (metterci degli spazi è un
+dove lo spazio all'inizio deve essere un tabulatore (metterci degli spazi è un
 errore comune, fortunatamente ben segnalato dalle ultime versioni del
 programma), il bersaglio e le dipendenze nomi di file e le regole comandi di
 shell.
 
-Il concetto di base è che se uno dei file di dipendenza è più recente (nel
+Il concetto di base è che se uno dei file di dipendenza è più recente (nel
 senso di tempo di ultima modifica) del file bersaglio quest'ultimo viene
 ricostruito di nuovo usando le regole elencate nelle righe successive.
 
 Il comando \texttt{make} ricostruisce di default il primo bersaglio che viene
 trovato nella scansione del \texttt{Makefile}, se in un \texttt{Makefile} sono
-contenuti più bersagli indipendenti, si può farne ricostruire un altro che non
+contenuti più bersagli indipendenti, si può farne ricostruire un altro che non
 sia il primo passandolo esplicitamente al comando come argomento, con qualcosa
 del tipo di: \texttt{make altrobersaglio}.
 
 Si tenga presente che le dipendenze stesse possono essere dichiarate come 
-bersagli dipendenti da altri file; in questo modo è possibile creare una 
+bersagli dipendenti da altri file; in questo modo è possibile creare una 
 catena di ricostruzioni. 
 
-In esempio comune di quello che si fa è mettere come primo bersaglio il
+In esempio comune di quello che si fa è mettere come primo bersaglio il
 programma principale che si vuole usare, e come dipendenze tutte gli oggetti
 delle funzioni subordinate che utilizza, con i quali deve essere collegato; a
 loro volta questi oggetti sono bersagli che hanno come dipendenza i relativi
@@ -132,11 +132,11 @@ clean:
 \end{verbatim}
 \normalsize
 
-Anzitutto i commenti, ogni linea che inizia con un \texttt{\#} è un
+Anzitutto i commenti, ogni linea che inizia con un \texttt{\#} è un
 commento e non viene presa in considerazione.
 
 Con \texttt{make} possono essere definite delle variabili, da potersi riusare
-a piacimento, per leggibilità si tende a definirle tutte maiuscole,
+a piacimento, per leggibilità si tende a definirle tutte maiuscole,
 nell'esempio ne sono definite varie: \small
 \begin{verbatim}
 FC=g77
@@ -150,7 +150,7 @@ OBJ=cnoise.o fit2.o pedsig.o loop.o badstrp.o cutcn.o readevnt.o \
 \end{verbatim}
 \normalsize
 
-La sintassi è \texttt{NOME=}, alcuni nomi però hanno un significato speciale
+La sintassi è \texttt{NOME=}, alcuni nomi però hanno un significato speciale
 (nel caso \texttt{FC}, \texttt{FLAGS}, \texttt{CC}, \texttt{CFLAGS}) in quanto
 sono usati da \texttt{make} nelle cosiddette \textsl{regole implicite} (su cui
 torneremo dopo).
@@ -165,7 +165,7 @@ nel makefile abbiamo usato:
 \begin{verbatim}
         $(FC) $(FFLAGS) -o riduzione riduzione.F readfile.o $(OBJ) $(LIBS) 
 \end{verbatim}
-e questo significa che la regola verrà trattata come se avessimo scritto 
+e questo significa che la regola verrà trattata come se avessimo scritto 
 esplicitamente i valori delle variabili.
 
 Veniamo ora alla parte principale del makefile che esegue la costruzione del
@@ -178,7 +178,7 @@ readfile.o: readfile.c
 $(OBJ): commondef.f
 \end{verbatim}
 
-Il primo bersaglio del makefile, che definisce il bersaglio di default, è il
+Il primo bersaglio del makefile, che definisce il bersaglio di default, è il
 programma di riduzione dei dati; esso dipende dal suo sorgente da tutti gli
 oggetti definiti dalla variabile \texttt{OBJ}, dal file di definizioni
 \texttt{commondef.f} e dalla routine C \texttt{readfile.o}; si noti il
@@ -193,48 +193,48 @@ librerie.
 Il secondo bersaglio definisce le regole per la compilazione della routine
 in C; essa dipende solo dal suo sorgente. Si noti che per la compilazione
 vengono usate le variabili relative al compilatore C. Si noti anche che se
-questa regola viene usata, allora lo sarà anche la precedente, dato che
+questa regola viene usata, allora lo sarà anche la precedente, dato che
 \texttt{riduzione} dipende da \texttt{readfile.o}.
 
-Il terzo bersaglio è apparentemente incomprensibile dato che vi compare
+Il terzo bersaglio è apparentemente incomprensibile dato che vi compare
 solo il riferimento alla variabile \texttt{OBJ} con una sola dipendenza e
-nessuna regola, essa però mostra le possibilità (oltre che la
-complessità) di \texttt{make} connesse alla presenza di quelle regole
+nessuna regola, essa però mostra le possibilità (oltre che la
+complessità) di \texttt{make} connesse alla presenza di quelle regole
 implicite a cui avevamo accennato.
 
-Anzitutto una peculiarità di \texttt{make} è che si possono anche usare più
+Anzitutto una peculiarità di \texttt{make} è che si possono anche usare più
 bersagli per una stessa regola (nell'esempio quelli contenuti nella variabile
 \texttt{OBJ} che viene espansa in una lista); in questo caso la regola di
-costruzione sarà applicata a ciascuno che si potrà citare nella regola stessa
+costruzione sarà applicata a ciascuno che si potrà citare nella regola stessa
 facendo riferimento con la variabile automatica: \texttt{\$@}.  L'esempio
-usato per la nostra costruzione però sembra non avere neanche la regola di
+usato per la nostra costruzione però sembra non avere neanche la regola di
 costruzione.
 
 Questa mancanza sia di regola che di dipendenze (ad esempio dai vari sorgenti) 
-illustra le capacità di funzionamento automatico di \texttt{make}.
-Infatti è facile immaginarsi che un oggetto dipenda da un sorgente, e che 
+illustra le capacità di funzionamento automatico di \texttt{make}.
+Infatti è facile immaginarsi che un oggetto dipenda da un sorgente, e che 
 per ottenere l'oggetto si debba compilare quest'ultimo.
 
-Il comando \texttt{make} sa tutto questo per cui quando un bersaglio è un
-oggetto (cioè ha un nome tipo \texttt{qualcosa.o}) non è necessario
+Il comando \texttt{make} sa tutto questo per cui quando un bersaglio è un
+oggetto (cioè ha un nome tipo \texttt{qualcosa.o}) non è necessario
 specificare il sorgente, ma il programma lo va a cercare nella directory
-corrente (ma è possibile pure dirgli di cercarlo altrove, il caso è trattato
-nel manuale).  Nel caso specifico allora si è messo come dipendenza solo il
+corrente (ma è possibile pure dirgli di cercarlo altrove, il caso è trattato
+nel manuale).  Nel caso specifico allora si è messo come dipendenza solo il
 file delle definizioni che viene incluso in ogni subroutine.
 
 Inoltre come dicevamo in genere per costruire un oggetto si deve compilarne il
 sorgente; \texttt{make} sa anche questo e sulla base dell'estensione del
-sorgente trovato (che nel caso sarà un \texttt{qualcosa.f}) applica la regola
-implicita.  In questo caso la regola è quella di chiamare il compilatore
+sorgente trovato (che nel caso sarà un \texttt{qualcosa.f}) applica la regola
+implicita.  In questo caso la regola è quella di chiamare il compilatore
 fortran applicato al file oggetto e al relativo sorgente, questo viene fatto
-usando la variabile \texttt{FC} che è una delle variabili standard usata dalle
+usando la variabile \texttt{FC} che è una delle variabili standard usata dalle
 regole implicite (come \texttt{CC} nel caso di file \texttt{.c}); per una
-maggiore flessibilità poi la regola standard usa anche la variabile
+maggiore flessibilità poi la regola standard usa anche la variabile
 \texttt{FFLAGS} per specificare, a scelta dell'utente che non ha che da
 definirla, quali flag di compilazione usare (nella documentazione sono
 riportate tutte le regole implicite e le relative variabili usate).
 
-In questo modo è stato possibile usare una sola riga per indicare la serie di
+In questo modo è stato possibile usare una sola riga per indicare la serie di
 dipendenze e relative compilazioni delle singole subroutine; inoltre con l'uso
 della variabile \texttt{OBJ} l'aggiunta di una nuova eventuale routine
 \texttt{nuova.f} comporta solo l'aggiunta di \texttt{nuova.o} alla definizione
@@ -244,60 +244,60 @@ di \texttt{OBJ}.
 \section{Source Control Management}
 \label{sec:build_scm}
 
-Uno dei problemi più comuni che si hanno nella programmazione è quella di
+Uno dei problemi più comuni che si hanno nella programmazione è quella di
 poter disporre di un sistema che consenta di tenere conto del lavoro
 effettuato, di tracciare l'evoluzione del codice, e, soprattutto nel caso di
-progetti portati avanti da più persone, consentire un accesso opportunamente
+progetti portati avanti da più persone, consentire un accesso opportunamente
 coordinato fra i vari partecipanti alla base comune dei sorgenti dello
 sviluppo.
 
 I programmi che servono a questo scopo vanno sotto il nome comune di SCM
 (\textit{Source Control Manager}), e ne esistono di diversi tipi con diverse
-filosofie progettuali, in particolare nelle modalità con cui gestiscono
+filosofie progettuali, in particolare nelle modalità con cui gestiscono
 l'accesso alla base di codice comune da parte dei singoli programmatori che vi
 accedono.
 
-Fra questi uno dei più usati, nonostante la sua architettura sia considerata
-superata, è Subversion, un sistema di archiviazione centralizzata del codice
+Fra questi uno dei più usati, nonostante la sua architettura sia considerata
+superata, è Subversion, un sistema di archiviazione centralizzata del codice
 che consente di tenere traccia di tutte le modifiche e di condividere un
 archivio comune per progetti portati avanti da diverse persone.
 
 \subsection{Introduzione a Subversion}
 \label{sec:build_subversion}
 
-Subversion è basato sul concetto di \textit{repository}, un archivio
+Subversion è basato sul concetto di \textit{repository}, un archivio
 centralizzato in cui vengono riposti e da cui vengono presi i sorgenti dei
 programmi. L'archivio tiene traccia delle diverse versioni registrate; i
 programmatori inviano le modifiche usando una copia locale che hanno nella
 loro directory di lavoro.
 
-Subversion può gestire più di un progetto all'interno di un singolo server,
+Subversion può gestire più di un progetto all'interno di un singolo server,
 ciascuno dei quali viene associato ad un \textit{repository} distinto, ma si
 possono anche creare sotto-progetti suddividendo un \textit{repository} in
-diverse directory; ma ciascun progetto avrà meccanismi di controllo (ad 
+diverse directory; ma ciascun progetto avrà meccanismi di controllo (ad 
 esempio quelli che consentono di inviare email all'inserimento di nuovo
 codice) comuni.
 
 Una delle caratteristiche che contraddistinguono Subversion dal suo
-predecessore CVS è quella di essere gestibile in maniera molto flessibile
-l'accesso al repository, che può avvenire sia in maniera diretta facendo
-riferimento alla directory in cui questo è stato installato che via rete,
-tramite diversi protocolli. L'accesso più comune è fatto direttamente via
-HTTP, utilizzando opportune estensioni del protocollo DAV, ma è possibile
+predecessore CVS è quella di essere gestibile in maniera molto flessibile
+l'accesso al repository, che può avvenire sia in maniera diretta facendo
+riferimento alla directory in cui questo è stato installato che via rete,
+tramite diversi protocolli. L'accesso più comune è fatto direttamente via
+HTTP, utilizzando opportune estensioni del protocollo DAV, ma è possibile
 passare attraverso SSH o fornire un servizio di rete dedicato.\footnote{esiste
-  all'uopo il programma \texttt{svnserve}, ma il suo uso è sconsigliato per le
-  scarse prestazioni e le difficoltà riscontrate a gestire accessi di utenti
-  diversi; la modalità di accesso preferita resta quella tramite le estensioni
+  all'uopo il programma \texttt{svnserve}, ma il suo uso è sconsigliato per le
+  scarse prestazioni e le difficoltà riscontrate a gestire accessi di utenti
+  diversi; la modalità di accesso preferita resta quella tramite le estensioni
   al protocollo DAV.}
 
-In generale è comunque necessario preoccuparsi delle modalità di accesso al
-codice soltanto in fase di primo accesso al \textit{repository}, che occorrerà
+In generale è comunque necessario preoccuparsi delle modalità di accesso al
+codice soltanto in fase di primo accesso al \textit{repository}, che occorrerà
 identificare o con il pathname alla directory dove questo si trova o con una
 opportuna URL (con il comune accesso via web del tutto analoga a quella che si
-usa in un browser), dopo di che detto indirizzo sarà salvato nella propria
-copia locale dei dati ed il riferimento diventerà implicito.
+usa in un browser), dopo di che detto indirizzo sarà salvato nella propria
+copia locale dei dati ed il riferimento diventerà implicito.
 
-Il programma prevede infatti che in ogni directory che si è ottenuta come
+Il programma prevede infatti che in ogni directory che si è ottenuta come
 copia locale sia presente una directory \texttt{.svn} contenente tutti i dati
 necessari al programma. Inoltre il programma usa la directory
 \texttt{.subversion} nella home dell'utente per mantenere le configurazioni
@@ -306,7 +306,7 @@ generali del client e le eventuali informazioni di autenticazione.
 Tutte le operazioni di lavoro sul \textit{repository} vengono effettuate lato
 client tramite il comando \texttt{svn} che vedremo in
 sez.~\ref{sec:build_subversion} ma la creazione e la inizializzazione dello
-stesso (così come la gestione lato server) devono essere fatte tramite il
+stesso (così come la gestione lato server) devono essere fatte tramite il
 comando \texttt{svnadmin} eseguito sulla macchina che lo ospita. In generale
 infatti il comando \texttt{svn} richiede che si faccia riferimento ad un
 \textit{repository} (al limite anche vuoto) esistente e questo deve essere
@@ -314,13 +314,13 @@ opportunamente creato.
 
 Il comando \texttt{svnadmin} utilizza una sintassi che richiede sempre
 l'ulteriore specificazione di un sotto-comando, seguito da eventuali altri
-argomenti. L'inizializzazione di un \textit{repository} (che sarà creato
+argomenti. L'inizializzazione di un \textit{repository} (che sarà creato
 sempre vuoto) viene eseguita con il comando:
 \begin{verbatim}
 svnadmin create /path/to/repository
 \end{verbatim}
-dove \texttt{/path/to/repository} è la directory dove verranno creati e
-mantenuti tutti i file, una volta creato il \textit{repository} si potrà
+dove \texttt{/path/to/repository} è la directory dove verranno creati e
+mantenuti tutti i file, una volta creato il \textit{repository} si potrà
 iniziare ad utilizzarlo ed inserirvi i contenuti con il comando \texttt{svn}. 
 
 Non essendo questo un testo di amministrazione di sistema non tratteremo qui i
@@ -333,33 +333,33 @@ Srl.\footnote{rispettivamente disponibili su \url{svn.tigris.org} e
 \subsection{Utilizzo di \texttt{svn}}
 \label{sec:build_svn_use}
 
-Una volta che si abbia a disposizione un \textit{repository} si potrà creare
+Una volta che si abbia a disposizione un \textit{repository} si potrà creare
 un nuovo progetto sottoposto a controllo di versione importando al suo interno
-i dati disponibili. In genere è pratica comune suddividere il contenuto di un
+i dati disponibili. In genere è pratica comune suddividere il contenuto di un
 repository in tre directory secondo il seguente schema:
 \begin{basedescript}{\desclabelwidth{2.7cm}\desclabelstyle{\nextlinelabel}}
 \item[\texttt{trunk}] contiene la versione corrente i sviluppo, su cui vengono
   effettuate normalmente le modifiche e gli aggiornamenti;
 \item[\texttt{tags}] contiene le diverse versioni \textsl{fotografate} ad un
   certo istante del processo di sviluppo, ad esempio in occasione del rilascio
-  di una versione stabile, così che sia possibile identificarle facilmente;
+  di una versione stabile, così che sia possibile identificarle facilmente;
 \item[\texttt{branches}] contiene \textsl{rami} alternativi di sviluppo, ad
   esempio quello delle correzioni eseguite ad una versione stabile, che
   vengono portati avanti in maniera indipendente dalla versione principale.
 \end{basedescript}
 
-Questa suddivisione consente di sfruttare la capacità di Subversion di creare
+Questa suddivisione consente di sfruttare la capacità di Subversion di creare
 senza spesa copie diverse del proprio contenuto, pertanto in genere si pone il
 proprio progetto di sviluppo sotto \texttt{trunk}, e si copia quest'ultima in
 occasione delle varie versioni di rilascio in altrettante sottocartelle di
 \texttt{tags} e qualora si voglia aprire un ramo alternativo di sviluppo
-basterà copiarsi il punto di partenza del ramo sotto \texttt{branches} e
+basterà copiarsi il punto di partenza del ramo sotto \texttt{branches} e
 iniziare ad eseguire le modifiche su di esso.
 
 Le operazioni di gestione di un progetto con Subversion vengono eseguite con
 il comando \texttt{svn}, che analogamente al precedente \texttt{svnadmin}
 utilizza una sintassi basata sulla specificazione degli opportuni
-sotto-comandi. Si sono riportati quelli più importanti in
+sotto-comandi. Si sono riportati quelli più importanti in
 tab.~\ref{tab:svn_mainsubcommands}. 
 
 \begin{table}[htb]
@@ -394,26 +394,26 @@ tab.~\ref{tab:svn_mainsubcommands}.
   \label{tab:svn_mainsubcommands}
 \end{table}
 
-In genere però è piuttosto raro iniziare un progetto totalmente da zero, è
-molto più comune avere una qualche versione iniziale dei propri file
-all'interno di una cartella. In questo caso il primo passo è quello di
+In genere però è piuttosto raro iniziare un progetto totalmente da zero, è
+molto più comune avere una qualche versione iniziale dei propri file
+all'interno di una cartella. In questo caso il primo passo è quello di
 eseguire una inizializzazione del \textit{repository} importando al suo
-interno quanto già esistente.  Per far questo occorre eseguire il comando:
+interno quanto già esistente.  Per far questo occorre eseguire il comando:
 \begin{verbatim}
 svn import [/pathname] URL
 \end{verbatim}
-questo può essere eseguito direttamente nella directory contenente la versione
+questo può essere eseguito direttamente nella directory contenente la versione
 iniziale dei propri sorgenti nel qual caso il comando richiede come ulteriore
 argomento la directory o la URL con la quale indicare il \textit{repository}
-da usare. Alternativamente si può passare come primo argomento il pathname
+da usare. Alternativamente si può passare come primo argomento il pathname
 della directory da importare, seguito dall'indicazione della URL del
 \textit{repository}.
 
 Si tenga presente che l'operazione di importazione inserisce sul
 \textit{repository} il contenuto completo della directory indicata, compresi
-eventuali file nascosti e sotto-directory. È anche possibile eseguire
-l'importazione di più directory da inserire in diverse sezioni del
-\textit{repository}, ma un tal caso ciascuna importazione sarà vista con una
+eventuali file nascosti e sotto-directory. È anche possibile eseguire
+l'importazione di più directory da inserire in diverse sezioni del
+\textit{repository}, ma un tal caso ciascuna importazione sarà vista con una
 diversa \textit{release}. Ad ogni operazione di modifica del
 \textit{repository} viene infatti assegnato un numero progressivo che consente
 di identificarne la storia delle modifiche e riportarsi ad un dato punto della
@@ -421,55 +421,55 @@ stessa in ogni momento successivo.\footnote{a differenza di CVS Subversion non
   assegna un numero di versione progressivo distinto ad ogni file, ma un
   numero di \textit{release} progressivo ad ogni cambiamento globale del
   repository, pertanto non esiste il concetto di versione di un singolo file,
-  quanto di stato di tutto il \textit{repository} ad un dato momento, è
+  quanto di stato di tutto il \textit{repository} ad un dato momento, è
   comunque possibile richiedere in maniera indipendente la versione di ogni
   singolo file a qualunque \textit{release} si desideri.}
 
-Una volta eseguita l'importazione di una versione iniziale è d'uopo cancellare
+Una volta eseguita l'importazione di una versione iniziale è d'uopo cancellare
 la directory originale e ripartire dal progetto appena creato. L'operazione di
 recuperare ex-novo di tutti i file che fanno parte di un progetto, chiamata
 usualmente \textit{checkout}, viene eseguita con il
-comando:\footnote{alternativamente si può usare l'abbreviazione \texttt{svn
+comando:\footnote{alternativamente si può usare l'abbreviazione \texttt{svn
     co}.}
 \begin{verbatim}
 svn checkout URL [/pathname]
 \end{verbatim}
-che creerà nella directory corrente una directory corrispondente al nome
+che creerà nella directory corrente una directory corrispondente al nome
 specificato in coda alla URL passata come argomento, scaricando l'ultima
-versione dei file archiviati sul repository; alternativamente si può
+versione dei file archiviati sul repository; alternativamente si può
 specificare come ulteriore argomento la directory su cui scaricare i file.
 
-Sia in caso di \texttt{import} che di \texttt{checkout} è sempre possibile
+Sia in caso di \texttt{import} che di \texttt{checkout} è sempre possibile
 operare su una qualunque sotto cartella contenuta all'interno di un
-\textit{repository}, ignorando totalmente quello che sta al di sopra, basterà
+\textit{repository}, ignorando totalmente quello che sta al di sopra, basterà
 indicare in sede di importazione o di estrazione iniziale un pathname o una
 URL che identifichi quella parte del progetto.
 
-Se quando si effettua lo scaricamento non si vuole usare la versione più
-aggiornata, ma una versione precedente si può usare l'opzione \texttt{-r}
-seguita da un numero che scaricherà esattamente quella \textit{release},
-alternativamente al posto del numero si può indicare una data, e verrà presa
-la \textit{release} più prossima a quella data. 
+Se quando si effettua lo scaricamento non si vuole usare la versione più
+aggiornata, ma una versione precedente si può usare l'opzione \texttt{-r}
+seguita da un numero che scaricherà esattamente quella \textit{release},
+alternativamente al posto del numero si può indicare una data, e verrà presa
+la \textit{release} più prossima a quella data. 
 
 A differenza di CVS Subversion non supporta l'uso di \textsl{etichette}
-associate ad una certa versione del proprio progetto, per questo è invalso
+associate ad una certa versione del proprio progetto, per questo è invalso
 l'uso di strutturare il repository secondo lo schema illustrato inizialmente;
-è infatti molto semplice (e non comporta nessun tipo di aggravio) creare delle
+è infatti molto semplice (e non comporta nessun tipo di aggravio) creare delle
 copie complete di una qualunque parte del \textit{repository} su un'altra
-parte dello stesso, per cui se si è eseguito lo sviluppo sulla cartella
-\texttt{trunk} sarà possibile creare banalmente una versione con etichetta
+parte dello stesso, per cui se si è eseguito lo sviluppo sulla cartella
+\texttt{trunk} sarà possibile creare banalmente una versione con etichetta
 \texttt{label} (o quel che si preferisce) semplicemente con una copia eseguita
 con:
 \begin{verbatim}
 svn cp trunk tags/label
 \end{verbatim}
 
-Il risultato di questo comando è la creazione della nuova cartella
-\texttt{label} sotto \texttt{tags}, che sarà assolutamente identica, nel
+Il risultato di questo comando è la creazione della nuova cartella
+\texttt{label} sotto \texttt{tags}, che sarà assolutamente identica, nel
 contenuto (e nella sua storia) a quanto presente in \texttt{trunk} al momento
 dell'esecuzione del comando. In questo modo, una volta salvate le
-modifiche,\footnote{la copia viene eseguita localmente verrà creata anche sul
-  \textit{repository} solo dopo un \textit{commit}.} si potrà ottenere la
+modifiche,\footnote{la copia viene eseguita localmente verrà creata anche sul
+  \textit{repository} solo dopo un \textit{commit}.} si potrà ottenere la
 versione \texttt{label} del proprio progetto semplicemente eseguendo un
 \textit{checkout} di \texttt{tags/label} in un'altra
 directory.\footnote{ovviamente una volta presa la suddetta versione si deve
@@ -477,7 +477,7 @@ directory.\footnote{ovviamente una volta presa la suddetta versione si deve
   questo se si deve modificare una versione etichettata si usa
   \texttt{branches}.}
 
-Una volta creata la propria copia locale dei programmi, è possibile lavorare
+Una volta creata la propria copia locale dei programmi, è possibile lavorare
 su di essi ponendosi nella relativa directory, e apportare tutte le modifiche
 che si vogliono ai file ivi presenti; due comandi permettono inoltre di
 schedulare la rimozione o l'aggiunta di file al
@@ -494,17 +494,17 @@ che non viene dato il comando:\footnote{in genere anche questo viene
 \begin{verbatim}
 svn commit [file]
 \end{verbatim}
-ed è possibile eseguire il \textit{commit} delle modifiche per un singolo
+ed è possibile eseguire il \textit{commit} delle modifiche per un singolo
 file, indicandolo come ulteriore argomento, mentre se non si indica nulla
 verranno inviate tutte le modifiche presenti.
 
-Si tenga presente però che il \textit{commit} non verrà eseguito se nel
+Si tenga presente però che il \textit{commit} non verrà eseguito se nel
 frattempo i file del \textit{repository} sono stati modificati; in questo caso
-\texttt{svn} rileverà la presenza di differenze fra la propria
-\textit{release} e quella del \textit{repository} e chiederà che si effettui
-preventivamente un aggiornamento. Questa è una delle operazioni di base di
+\texttt{svn} rileverà la presenza di differenze fra la propria
+\textit{release} e quella del \textit{repository} e chiederà che si effettui
+preventivamente un aggiornamento. Questa è una delle operazioni di base di
 Subversion, che in genere si compie tutte le volte che si inizia a lavorare,
-il comando che la esegue è:
+il comando che la esegue è:
 \begin{verbatim}
 svn update
 \end{verbatim}
@@ -521,8 +521,8 @@ con quelle presenti sulla versione del \textit{repository}.
 Fintanto che sono state modificate parti indipendenti di un file di testo in
 genere il processo di \textit{merging} ha successo e le modifiche vengono
 incorporate automaticamente in conseguenza dell'aggiornamento, ma quando le
-modifiche attengono alla stessa parte di un file nel ci si troverà di fronte
-ad un conflitto ed a quel punto sarà richiesto al ``committente'' di
+modifiche attengono alla stessa parte di un file nel ci si troverà di fronte
+ad un conflitto ed a quel punto sarà richiesto al ``committente'' di
 intervenire manualmente sui file per i quali sono stati rilevati i conflitti
 per risolverli.
 
@@ -539,11 +539,11 @@ seguente:
 >>>>>>> r.122
 \end{verbatim}
 
-In questo caso si c'è stata una modifica sul file (mostrata nella parte
+In questo caso si c'è stata una modifica sul file (mostrata nella parte
 superiore) incompatibile con quella fatta nel \textit{repository} (mostrata
-nella parte inferiore). Prima di eseguire un \textit{commit} occorrerà
+nella parte inferiore). Prima di eseguire un \textit{commit} occorrerà
 pertanto integrare le modifiche e salvare nuovamente il file rimuovendo i
-marcatori, inoltre prima che il \textit{commit} ritorni possibile si dovrà
+marcatori, inoltre prima che il \textit{commit} ritorni possibile si dovrà
 esplicitare la risoluzione del conflitto con il comando:
 \begin{verbatim}
 svn resolved file
@@ -570,7 +570,7 @@ svn resolved file
 \end{table}
 
 
-Infine per capire la situazione della propria copia locale si può utilizzare
+Infine per capire la situazione della propria copia locale si può utilizzare
 il comando \texttt{svn status} che confronta i file presenti nella directory
 locale rispetto alla ultima versione scaricata dal \textit{repository} e per
 tutti quelli che non corrispondono stampa a schermo delle informazioni di
diff --git a/errors.tex b/errors.tex
index 7598a88..c8f07ee 100644
--- a/errors.tex
+++ b/errors.tex
@@ -16,17 +16,17 @@ Si riportano in questa appendice tutti i codici di errore. Essi sono
 accessibili attraverso l'inclusione del file di header \file{errno.h}, che
 definisce anche la variabile globale \var{errno}. Per ogni errore definito
 riporteremo la stringa stampata da \func{perror} ed una breve spiegazione. Si
-tenga presente che spiegazioni più particolareggiate del significato
+tenga presente che spiegazioni più particolareggiate del significato
 dell'errore, qualora necessarie per casi specifici, possono essere trovate
-nella descrizione del prototipo della funzione per cui detto errore si è
+nella descrizione del prototipo della funzione per cui detto errore si è
 verificato.
 
 I codici di errore sono riportati come costanti di tipo \ctyp{int}, i valori
 delle costanti sono definiti da macro di preprocessore nel file citato, e
-possono variare da architettura a architettura; è pertanto necessario
+possono variare da architettura a architettura; è pertanto necessario
 riferirsi ad essi tramite i nomi simbolici. Le funzioni \func{perror} e
 \func{strerror} (vedi sez.~\ref{sec:sys_strerror}) possono essere usate per
-ottenere dei messaggi di errore più espliciti.
+ottenere dei messaggi di errore più espliciti.
 
 
 \section{Gli errori dei file}
@@ -37,9 +37,9 @@ attinenti ad errori che riguardano operazioni specifiche relative alla
 gestione dei file.
 
 \begin{description}
-\item \errcode{EPERM} \textit{Operation not permitted}. L'operazione non è
+\item \errcode{EPERM} \textit{Operation not permitted}. L'operazione non è
   permessa: solo il proprietario del file o un processo con sufficienti
-  privilegi può eseguire l'operazione.
+  privilegi può eseguire l'operazione.
 \item \errcode{ENOENT} \textit{No such file or directory}. Il file indicato
   dal \itindex{pathname} \textit{pathname} non esiste: o una delle componenti
   non esiste o il \textit{pathname} contiene un link simbolico spezzato.
@@ -49,98 +49,98 @@ gestione dei file.
   per riportare errori hardware in lettura/scrittura su un dispositivo.
 \item \errcode{ENXIO} \textit{No such device or address}. Dispositivo
   inesistente: il sistema ha tentato di usare un dispositivo attraverso il
-  file specificato, ma non lo ha trovato. Può significare che il file di
-  dispositivo non è corretto, che il modulo relativo non è stato caricato nel
-  kernel, o che il dispositivo è fisicamente assente o non funzionante.
+  file specificato, ma non lo ha trovato. Può significare che il file di
+  dispositivo non è corretto, che il modulo relativo non è stato caricato nel
+  kernel, o che il dispositivo è fisicamente assente o non funzionante.
 \item \errcode{ENOEXEC} \textit{Invalid executable file format}. Il file non ha
-  un formato eseguibile, è un errore riscontrato dalle funzioni \func{exec}.
+  un formato eseguibile, è un errore riscontrato dalle funzioni \func{exec}.
 \item \errcode{EBADF} \textit{Bad file descriptor}. File descriptor non valido:
-  si è usato un file descriptor inesistente, o aperto in sola lettura per
-  scrivere, o viceversa, o si è cercato di eseguire un'operazione non
+  si è usato un file descriptor inesistente, o aperto in sola lettura per
+  scrivere, o viceversa, o si è cercato di eseguire un'operazione non
   consentita per quel tipo di file descriptor.
 \item \errcode{EACCES} \textit{Permission denied}. Permesso negato; l'accesso
-  al file o alla directory non è consentito: i permessi del file o della
+  al file o alla directory non è consentito: i permessi del file o della
   directory non consentono l'operazione richiesta.
 \item \errcode{ELOOP} \textit{Too many symbolic links encountered}. Ci sono
   troppi link simbolici nella risoluzione di un
   \itindex{pathname}\textit{pathname}.
-\item \errcode{ENAMETOOLONG} \textit{File name too long}. Si è indicato un
+\item \errcode{ENAMETOOLONG} \textit{File name too long}. Si è indicato un
   \itindex{pathname} \textit{pathname} troppo lungo per un file o una
   directory.
-\item \errcode{ENOTBLK} \textit{Block device required}. Si è specificato un
-  file che non è un \textit{block device} in un contesto in cui era necessario
-  specificare un \textit{block device} (ad esempio si è tentato di montare un
+\item \errcode{ENOTBLK} \textit{Block device required}. Si è specificato un
+  file che non è un \textit{block device} in un contesto in cui era necessario
+  specificare un \textit{block device} (ad esempio si è tentato di montare un
   file ordinario).
-\item \errcode{EEXIST} \textit{File exists}. Si è specificato un file esistente
+\item \errcode{EEXIST} \textit{File exists}. Si è specificato un file esistente
   in un contesto in cui ha senso solo specificare un nuovo file.
 \item \errcode{EBUSY} \textit{Resource busy}. Una risorsa di sistema che non
-  può essere condivisa è occupata. Ad esempio si è tentato di cancellare la
-  directory su cui si è montato un filesystem.
-\item \errcode{EXDEV} \textit{Cross-device link}. Si è tentato di creare un
+  può essere condivisa è occupata. Ad esempio si è tentato di cancellare la
+  directory su cui si è montato un filesystem.
+\item \errcode{EXDEV} \textit{Cross-device link}. Si è tentato di creare un
   link diretto che attraversa due filesystem differenti.
-\item \errcode{ENODEV} \textit{No such device}. Si è indicato un tipo di device
+\item \errcode{ENODEV} \textit{No such device}. Si è indicato un tipo di device
   sbagliato ad una funzione che ne richiede uno specifico.
-\item \errcode{ENOTDIR} \textit{Not a directory}. Si è specificato un file che
-  non è una directory in una operazione che richiede una directory.
-\item \errcode{EISDIR} \textit{Is a directory}. Il file specificato è una
-  directory; non può essere aperto in scrittura, né si possono creare o
+\item \errcode{ENOTDIR} \textit{Not a directory}. Si è specificato un file che
+  non è una directory in una operazione che richiede una directory.
+\item \errcode{EISDIR} \textit{Is a directory}. Il file specificato è una
+  directory; non può essere aperto in scrittura, né si possono creare o
   rimuovere link diretti ad essa.
 \item \errcode{EMFILE} \textit{Too many open files}. Il processo corrente ha
-  troppi file aperti e non può aprirne altri. Anche i descrittori duplicati ed
+  troppi file aperti e non può aprirne altri. Anche i descrittori duplicati ed
   i socket vengono tenuti in conto.\footnote{il numero massimo di file aperti
-    è controllabile dal sistema; in Linux si può impostare usando il comando
-    \cmd{ulimit}, esso è in genere indicato dalla costante \const{OPEN\_MAX},
+    è controllabile dal sistema; in Linux si può impostare usando il comando
+    \cmd{ulimit}, esso è in genere indicato dalla costante \const{OPEN\_MAX},
     vedi sez.~\ref{sec:sys_limits}.}
 \item \errcode{ENFILE} \textit{File table overflow}. Il sistema ha troppi file
   aperti in contemporanea. Si tenga presente che anche i socket contano come
-  file. Questa è una condizione temporanea, ed è molto difficile che si
+  file. Questa è una condizione temporanea, ed è molto difficile che si
   verifichi nei sistemi moderni.
-\item \errcode{ENOTTY} \textit{Not a terminal}. Si è tentata una operazione di
-  controllo relativa ad un terminale su un file che non lo è.
-\item \errcode{ETXTBSY} \textit{Text file busy}. Si è cercato di eseguire un
-  file che è aperto in scrittura, o di scrivere su un file che è in
+\item \errcode{ENOTTY} \textit{Not a terminal}. Si è tentata una operazione di
+  controllo relativa ad un terminale su un file che non lo è.
+\item \errcode{ETXTBSY} \textit{Text file busy}. Si è cercato di eseguire un
+  file che è aperto in scrittura, o di scrivere su un file che è in
   esecuzione.
-\item \errcode{EFBIG} \textit{File too big}. Si è ecceduto il limite imposto
-  dal sistema sulla dimensione massima che un file può avere.
+\item \errcode{EFBIG} \textit{File too big}. Si è ecceduto il limite imposto
+  dal sistema sulla dimensione massima che un file può avere.
 \item \errcode{ENOSPC} \textit{No space left on device}. La directory in cui si
-  vuole creare il link non ha spazio per ulteriori voci, o si è cercato di
-  scrivere o di creare un nuovo file su un dispositivo che è già pieno.
+  vuole creare il link non ha spazio per ulteriori voci, o si è cercato di
+  scrivere o di creare un nuovo file su un dispositivo che è già pieno.
 \item \errcode{ESPIPE} \textit{Invalid seek operation}. Si cercato di eseguire
   una \func{seek} su un file che non supporta questa operazione (ad esempio su
   una pipe). 
-\item \errcode{EROFS} \textit{Read-only file system}.  Si è cercato di
+\item \errcode{EROFS} \textit{Read-only file system}.  Si è cercato di
   eseguire una operazione di scrittura su un file o una directory che risiede
   su un filesystem montato un sola lettura.
-\item \errcode{EMLINK} \textit{Too many links}. Ci sono già troppi link al
-  file (il numero massimo è specificato dalla variabile \const{LINK\_MAX},
+\item \errcode{EMLINK} \textit{Too many links}. Ci sono già troppi link al
+  file (il numero massimo è specificato dalla variabile \const{LINK\_MAX},
   vedi sez.~\ref{sec:sys_limits}).
-\item \errcode{EPIPE} \textit{Broken pipe}. Non c'è un processo che stia
+\item \errcode{EPIPE} \textit{Broken pipe}. Non c'è un processo che stia
   leggendo l'altro capo della pipe. Ogni funzione che restituisce questo
-  errore genera anche un segnale \const{SIGPIPE}, la cui azione predefinita è
-  terminare il programma; pertanto non si potrà vedere questo errore fintanto
+  errore genera anche un segnale \const{SIGPIPE}, la cui azione predefinita è
+  terminare il programma; pertanto non si potrà vedere questo errore fintanto
   che \const{SIGPIPE} non viene gestito o bloccato.
-\item \errcode{ENOTEMPTY} \textit{Directory not empty}. La directory non è
-  vuota quando l'operazione richiede che lo sia. È l'errore tipico che si ha
+\item \errcode{ENOTEMPTY} \textit{Directory not empty}. La directory non è
+  vuota quando l'operazione richiede che lo sia. È l'errore tipico che si ha
   quando si cerca di cancellare una directory contenente dei file.
 \item \errcode{EUSERS} \textit{Too many users}. Troppi utenti, il sistema delle
   quote rileva troppi utenti nel sistema.
-\item \errcode{EDQUOT} \textit{Quota exceeded}. Si è ecceduta la quota di disco
+\item \errcode{EDQUOT} \textit{Quota exceeded}. Si è ecceduta la quota di disco
   dell'utente.
 \item \errcode{ESTALE} \textit{Stale NFS file handle}. Indica un problema
   interno a NFS causato da cambiamenti del filesystem del sistema remoto. Per
-  recuperare questa condizione in genere è necessario smontare e rimontare il
+  recuperare questa condizione in genere è necessario smontare e rimontare il
   filesystem NFS.
-\item \errcode{EREMOTE} \textit{Object is remote}. Si è fatto un tentativo di
-  montare via NFS un filesystem remoto con un nome  che già specifica un
+\item \errcode{EREMOTE} \textit{Object is remote}. Si è fatto un tentativo di
+  montare via NFS un filesystem remoto con un nome  che già specifica un
   filesystem montato via NFS. 
-\item \errcode{ENOLCK} \textit{No locks available}. È usato dalle utilità per
-  la gestione del file locking; non viene generato da un sistema GNU, ma può
+\item \errcode{ENOLCK} \textit{No locks available}. È usato dalle utilità per
+  la gestione del file locking; non viene generato da un sistema GNU, ma può
   risultare da un'operazione su un server NFS di un altro sistema.
-\item \errcode{EFTYPE} \textit{Inappropriate file type or format}. Il file è
+\item \errcode{EFTYPE} \textit{Inappropriate file type or format}. Il file è
   di tipo sbagliato rispetto all'operazione richiesta o un file di dati ha un
   formato sbagliato. Alcuni sistemi restituiscono questo errore quando si
   cerca di impostare lo \itindex{sticky~bit} \textit{sticky bit} su un file che
-  non è una directory.
+  non è una directory.
 \end{description}
 
 
@@ -156,15 +156,15 @@ gestione dei processi.
   Non esiste un processo o un \itindex{process~group} \textit{process group}
   corrispondenti al valore dell'identificativo specificato.
 \item \errcode{E2BIG} \textit{Argument list too long}. La lista degli
-  argomenti passati è troppo lunga: è una condizione prevista da POSIX quando
+  argomenti passati è troppo lunga: è una condizione prevista da POSIX quando
   la lista degli argomenti passata ad una delle funzioni \func{exec} occupa
-  troppa memoria, non può mai accadere in GNU/Linux.
+  troppa memoria, non può mai accadere in GNU/Linux.
 \item \errcode{ECHILD} \textit{There are no child processes}. Non esistono
   processi figli di cui attendere la terminazione. Viene rilevato dalle
   funzioni \func{wait} e \func{waitpid} (vedi sez.~\ref{sec:proc_wait}).
 \item \errcode{EPROCLIM} \textit{Too many processes}.  Il limite dell'utente
-  per nuovi processi (vedi sez.~\ref{sec:sys_resource_limit}) sarà ecceduto
-  alla prossima \func{fork}; è un codice di errore di BSD, che non viene
+  per nuovi processi (vedi sez.~\ref{sec:sys_resource_limit}) sarà ecceduto
+  alla prossima \func{fork}; è un codice di errore di BSD, che non viene
   utilizzato al momento su Linux. 
 \end{description}
 
@@ -178,8 +178,8 @@ gestione dei socket e delle connessioni di rete.
 
 
 \begin{description}
-\item \errcode{ENOTSOCK} \textit{Socket operation on non-socket}. Si è tentata
-  un'operazione su un file descriptor che non è un socket quando invece era
+\item \errcode{ENOTSOCK} \textit{Socket operation on non-socket}. Si è tentata
+  un'operazione su un file descriptor che non è un socket quando invece era
   richiesto un socket.
 \item \errcode{EMSGSIZE} \textit{Message too long}. Le dimensioni di un
   messaggio inviato su un socket sono eccedono la massima lunghezza supportata.
@@ -187,58 +187,58 @@ gestione dei socket e delle connessioni di rete.
   sbagliato per il socket. Il socket usato non supporta il protocollo di
   comunicazione richiesto. 
 \item \errcode{ENOPROTOOPT} \textit{Protocol not available}. Protocollo non
-  disponibile. Si è richiesta un'opzione per il socket non disponibile con il
+  disponibile. Si è richiesta un'opzione per il socket non disponibile con il
   protocollo usato.
 \item \errcode{EPROTONOSUPPORT} \textit{Protocol not supported}. Protocollo non
   supportato. Il tipo di socket non supporta il protocollo richiesto (un
   probabile errore nella specificazione del protocollo).
 \item \errcode{ESOCKTNOSUPPORT} \textit{Socket type not supported}. Socket non
-  supportato. Il tipo di socket scelto non è supportato.
+  supportato. Il tipo di socket scelto non è supportato.
 \item \errcode{EOPNOTSUPP} \textit{Operation not supported on transport
-    endpoint}. L'operazione richiesta non è supportata. Alcune funzioni non
+    endpoint}. L'operazione richiesta non è supportata. Alcune funzioni non
   hanno senso per tutti i tipi di socket, ed altre non sono implementate per
   tutti i protocolli di trasmissione. Questo errore quando un socket non
   supporta una particolare operazione, e costituisce una indicazione generica
   che il server non sa cosa fare per la chiamata effettuata.
 \item \errcode{EPFNOSUPPORT} \textit{Protocol family not supported}. Famiglia
-  di protocolli non supportata. La famiglia di protocolli richiesta non è
+  di protocolli non supportata. La famiglia di protocolli richiesta non è
   supportata.
 \item \errcode{EAFNOSUPPORT} \textit{Address family not supported by protocol}.
   Famiglia di indirizzi non supportata. La famiglia di indirizzi richiesta non
-  è supportata, o è inconsistente con il protocollo usato dal socket.
+  è supportata, o è inconsistente con il protocollo usato dal socket.
 \item \errcode{EADDRINUSE} \textit{Address already in use}. L'indirizzo del
-  socket richiesto è già utilizzato (ad esempio si è eseguita \func{bind}
-  su una porta già in uso).
+  socket richiesto è già utilizzato (ad esempio si è eseguita \func{bind}
+  su una porta già in uso).
 \item \errcode{EADDRNOTAVAIL} \textit{Cannot assign requested
-    address}.  L'indirizzo richiesto non è disponibile (ad esempio si
-  è cercato di dare al socket un nome che non corrisponde al nome
+    address}.  L'indirizzo richiesto non è disponibile (ad esempio si
+  è cercato di dare al socket un nome che non corrisponde al nome
   della stazione locale), o l'interfaccia richiesta non esiste.
-\item \errcode{ENETDOWN} \textit{Network is down}. L'operazione sul socket è
-  fallita perché la rete è sconnessa.
-\item \errcode{ENETUNREACH} \textit{Network is unreachable}. L'operazione è
-  fallita perché l'indirizzo richiesto è irraggiungibile (ad esempio la
-  sottorete della stazione remota è irraggiungibile).
+\item \errcode{ENETDOWN} \textit{Network is down}. L'operazione sul socket è
+  fallita perché la rete è sconnessa.
+\item \errcode{ENETUNREACH} \textit{Network is unreachable}. L'operazione è
+  fallita perché l'indirizzo richiesto è irraggiungibile (ad esempio la
+  sottorete della stazione remota è irraggiungibile).
 \item \errcode{ENETRESET} \textit{Network dropped connection because of reset}.
-  Una connessione è stata cancellata perché l'host remoto è caduto.
+  Una connessione è stata cancellata perché l'host remoto è caduto.
 \item \errcode{ECONNABORTED} \textit{Software caused connection abort}. Una
-  connessione è stata abortita localmente. 
-\item \errcode{ECONNRESET} \textit{Connection reset by peer}. Una connessione è
+  connessione è stata abortita localmente. 
+\item \errcode{ECONNRESET} \textit{Connection reset by peer}. Una connessione è
   stata chiusa per ragioni fuori dal controllo dell'host locale, come il
   riavvio di una macchina remota o un qualche errore non recuperabile sul
   protocollo.
 \item \errcode{ENOBUFS} \textit{No buffer space available}. Tutti i buffer per
-  le operazioni di I/O del kernel sono occupati. In generale questo errore è
+  le operazioni di I/O del kernel sono occupati. In generale questo errore è
   sinonimo di \errcode{ENOMEM}, ma attiene alle funzioni di input/output. In
-  caso di operazioni sulla rete si può ottenere questo errore invece
+  caso di operazioni sulla rete si può ottenere questo errore invece
   dell'altro.
-\item \errcode{EISCONN} \textit{Transport endpoint is already connected}. Si è
-  tentato di connettere un socket che è già connesso.
+\item \errcode{EISCONN} \textit{Transport endpoint is already connected}. Si è
+  tentato di connettere un socket che è già connesso.
 \item \errcode{ENOTCONN} \textit{Transport endpoint is not connected}. Il
-  socket non è connesso a niente. Si ottiene questo errore quando si cerca di
+  socket non è connesso a niente. Si ottiene questo errore quando si cerca di
   trasmettere dati su un socket senza avere specificato in precedenza la loro
   destinazione. Nel caso di socket senza connessione (ad esempio socket UDP)
-  l'errore che si ottiene è \errcode{EDESTADDRREQ}.
-\item \errcode{EDESTADDRREQ} \textit{Destination address required}. Non c'è un
+  l'errore che si ottiene è \errcode{EDESTADDRREQ}.
+\item \errcode{EDESTADDRREQ} \textit{Destination address required}. Non c'è un
   indirizzo di destinazione predefinito per il socket. Si ottiene questo
   errore mandando dato su un socket senza connessione senza averne prima
   specificato una destinazione.
@@ -250,12 +250,12 @@ gestione dei socket e delle connessioni di rete.
 \item \errcode{ETIMEDOUT} \textit{Connection timed out}. Un'operazione sul
   socket non ha avuto risposta entro il periodo di timeout.
 \item \errcode{ECONNREFUSED} \textit{Connection refused}. Un host remoto ha
-  rifiutato la connessione (in genere dipende dal fatto che non c'è un server
+  rifiutato la connessione (in genere dipende dal fatto che non c'è un server
   per soddisfare il servizio richiesto).  
 \item \errcode{EHOSTDOWN} \textit{Host is down}. L'host remoto di una
-  connessione è giù.
+  connessione è giù.
 \item \errcode{EHOSTUNREACH} \textit{No route to host}.  L'host remoto di una
-  connessione non è raggiungibile.
+  connessione non è raggiungibile.
 \end{description}
 
 \section{Errori generici}
@@ -266,76 +266,76 @@ specificati nelle sezioni precedenti.
 
 \begin{description}
 \item \errcode{EINTR} \textit{Interrupted function call}. Una funzione di
-  libreria è stata interrotta. In genere questo avviene causa di un segnale
+  libreria è stata interrotta. In genere questo avviene causa di un segnale
   asincrono al processo che impedisce la conclusione della chiamata, la
   funzione ritorna con questo errore una volta che si sia correttamente
-  eseguito il gestore del segnale. In questo caso è necessario ripetere la
+  eseguito il gestore del segnale. In questo caso è necessario ripetere la
   chiamata alla funzione.
-\item \errcode{ENOMEM} \textit{No memory available}. Il kernel non è in grado
+\item \errcode{ENOMEM} \textit{No memory available}. Il kernel non è in grado
   di allocare ulteriore memoria per completare l'operazione richiesta.
 \item \errcode{EDEADLK} \textit{Deadlock avoided}. L'allocazione di una
   risorsa avrebbe causato un \itindex{deadlock} \textit{deadlock}. Non sempre
-  il sistema è in grado di riconoscere queste situazioni, nel qual caso si
+  il sistema è in grado di riconoscere queste situazioni, nel qual caso si
   avrebbe il blocco.
 \item \errcode{EFAULT} \textit{Bad address}. Una stringa passata come
-  argomento è fuori dello spazio di indirizzi del processo, in genere questa
+  argomento è fuori dello spazio di indirizzi del processo, in genere questa
   situazione provoca direttamente l'emissione di un segnale di
   \itindex{segment~violation} \textit{segment violation} (\const{SIGSEGV}).
 \item \errcode{EINVAL} \textit{Invalid argument}. Errore utilizzato per
   segnalare vari tipi di problemi dovuti all'aver passato un argomento
   sbagliato ad una funzione di libreria.
-\item \errcode{EDOM} \textit{Domain error}. È usato dalle funzioni matematiche
-  quando il valore di un argomento è al di fuori dell'intervallo in cui esse
+\item \errcode{EDOM} \textit{Domain error}. È usato dalle funzioni matematiche
+  quando il valore di un argomento è al di fuori dell'intervallo in cui esse
   sono definite.
-\item \errcode{ERANGE} \textit{Range error}. È usato dalle funzioni
-  matematiche quando il risultato dell'operazione non è rappresentabile nel
+\item \errcode{ERANGE} \textit{Range error}. È usato dalle funzioni
+  matematiche quando il risultato dell'operazione non è rappresentabile nel
   valore di ritorno a causa di un overflow o di un underflow.
-\item \errcode{EAGAIN} \textit{Resource temporarily unavailable}. La funzione è
+\item \errcode{EAGAIN} \textit{Resource temporarily unavailable}. La funzione è
   fallita ma potrebbe funzionare se la chiamata fosse ripetuta. Questo errore
   accade in due tipologie di situazioni:
   \begin{itemize}
-  \item Si è effettuata un'operazione che si sarebbe bloccata su un oggetto
-    che è stato posto in modalità non bloccante. Nei vecchi sistemi questo era
+  \item Si è effettuata un'operazione che si sarebbe bloccata su un oggetto
+    che è stato posto in modalità non bloccante. Nei vecchi sistemi questo era
     un codice diverso, \errcode{EWOULDBLOCK}. In genere questo ha a che fare
-    con file o socket, per i quali si può usare la funzione \func{select} per
+    con file o socket, per i quali si può usare la funzione \func{select} per
     vedere quando l'operazione richiesta (lettura, scrittura o connessione)
     diventa possibile.
-  \item Indica la carenza di una risorsa di sistema che non è al momento
-    disponibile (ad esempio \func{fork} può fallire con questo errore se si è
+  \item Indica la carenza di una risorsa di sistema che non è al momento
+    disponibile (ad esempio \func{fork} può fallire con questo errore se si è
     esaurito il numero di processi contemporanei disponibili). La ripetizione
     della chiamata in un periodo successivo, in cui la carenza della risorsa
-    richiesta può essersi attenuata, può avere successo. Questo tipo di
-    carenza è spesso indice di qualcosa che non va nel sistema, è pertanto
+    richiesta può essersi attenuata, può avere successo. Questo tipo di
+    carenza è spesso indice di qualcosa che non va nel sistema, è pertanto
     opportuno segnalare esplicitamente questo tipo di errori.
   \end{itemize}
 \item \errcode{EWOULDBLOCK} \textit{Operation would block}. Indica che
   l'operazione richiesta si bloccherebbe, ad esempio se si apre un file in
-  modalità non bloccante, una \func{read} restituirebbe questo errore per
-  indicare che non ci sono dati; in Linux è identico a \errcode{EAGAIN}, ma in
-  altri sistemi può essere specificato un valore diverso.
+  modalità non bloccante, una \func{read} restituirebbe questo errore per
+  indicare che non ci sono dati; in Linux è identico a \errcode{EAGAIN}, ma in
+  altri sistemi può essere specificato un valore diverso.
 \item \errcode{EINPROGRESS} \textit{Operation now in progress}. Operazione in
-  corso. Un'operazione che non può essere completata immediatamente è stata
-  avviata su un oggetto posto in modalità non-bloccante. Questo errore viene
+  corso. Un'operazione che non può essere completata immediatamente è stata
+  avviata su un oggetto posto in modalità non-bloccante. Questo errore viene
   riportato per operazioni che si dovrebbero sempre bloccare (come per una
   \func{connect}) e che pertanto non possono riportare \errcode{EAGAIN},
-  l'errore indica che l'operazione è stata avviata correttamente e occorrerà
-  del tempo perché si possa completare. La ripetizione della chiamata darebbe
+  l'errore indica che l'operazione è stata avviata correttamente e occorrerà
+  del tempo perché si possa completare. La ripetizione della chiamata darebbe
   luogo ad un errore \errcode{EALREADY}.
-\item \errcode{EALREADY} \textit{Operation already in progress}. L'operazione è
-  già in corso. Si è tentata un'operazione già in corso su un oggetto posto in
-  modalità non-bloccante.
+\item \errcode{EALREADY} \textit{Operation already in progress}. L'operazione è
+  già in corso. Si è tentata un'operazione già in corso su un oggetto posto in
+  modalità non-bloccante.
 \item \errcode{ENOSYS} \textit{Function not implemented}. Indica che la
-  funzione non è supportata o nelle librerie del C o nel kernel. Può dipendere
-  sia dalla mancanza di una implementazione, che dal fatto che non si è
-  abilitato l'opportuno supporto nel kernel; nel caso di Linux questo può
-  voler dire anche che un modulo necessario non è stato caricato nel sistema.
+  funzione non è supportata o nelle librerie del C o nel kernel. Può dipendere
+  sia dalla mancanza di una implementazione, che dal fatto che non si è
+  abilitato l'opportuno supporto nel kernel; nel caso di Linux questo può
+  voler dire anche che un modulo necessario non è stato caricato nel sistema.
 \item \errcode{ENOTSUP} \textit{Not supported}. Una funzione ritorna questo
-  errore quando gli argomenti sono validi ma l'operazione richiesta non è
+  errore quando gli argomenti sono validi ma l'operazione richiesta non è
   supportata. Questo significa che la funzione non implementa quel particolare
   comando o opzione o che, in caso di oggetti specifici (file descriptor o
-  altro) non è in grado di supportare i parametri richiesti.
+  altro) non è in grado di supportare i parametri richiesti.
 \item \errcode{EILSEQ} \textit{Illegal byte sequence}. Nella decodifica di un
-  carattere esteso si è avuta una sequenza errata o incompleta o si è
+  carattere esteso si è avuta una sequenza errata o incompleta o si è
   specificato un valore non valido.
 \end{description}
 
@@ -364,55 +364,55 @@ essendo gli stream definiti su Linux il kernel non genera mai questo tipo di
 messaggio. 
 
 \item \errcode{EMULTIHOP} \textit{Multihop attempted}. Definito da POSIX come
-  errore dovuto all'accesso a file remoti attraverso più macchine, quando ciò
-  non è consentito. Non viene mai generato su Linux.
+  errore dovuto all'accesso a file remoti attraverso più macchine, quando ciò
+  non è consentito. Non viene mai generato su Linux.
 
 \item \errcode{EIDRM} \textit{Identifier removed}. Indica che l'oggetto del
-  \textit{SysV IPC} a cui si fa riferimento è stato cancellato.
+  \textit{SysV IPC} a cui si fa riferimento è stato cancellato.
 
 \item \errcode{ENODATA} \textit{No data available}. Viene indicato da POSIX
   come restituito da una \func{read} eseguita su un file descriptor in
-  modalità non bloccante quando non ci sono dati. In realtà in questo caso su
-  Linux viene utilizzato \errcode{EAGAIN}. Lo stesso valore valore però viene
+  modalità non bloccante quando non ci sono dati. In realtà in questo caso su
+  Linux viene utilizzato \errcode{EAGAIN}. Lo stesso valore valore però viene
   usato come sinonimo di \errcode{ENOATTR}. 
 
-\item \errcode{ENOATTR} \textit{No such attribute}. È un codice di errore
+\item \errcode{ENOATTR} \textit{No such attribute}. È un codice di errore
   specifico di Linux utilizzato dalle funzioni per la gestione degli attributi
   estesi dei file (vedi sez.~\ref{sec:file_xattr}) quando il nome
   dell'attributo richiesto non viene trovato.
 
-\item \errcode{ENOLINK} \textit{Link has been severed}. È un errore il cui
-  valore è indicato come \textsl{riservato} nelle \textit{Single Unix
-    Specification}. Dovrebbe indicare l'impossibilità di accedere ad un file a
+\item \errcode{ENOLINK} \textit{Link has been severed}. È un errore il cui
+  valore è indicato come \textsl{riservato} nelle \textit{Single Unix
+    Specification}. Dovrebbe indicare l'impossibilità di accedere ad un file a
   causa di un errore sul collegamento di rete, ma non ci sono indicazioni
   precise del suo utilizzo. Per quanto riguarda Linux viene riportato nei
   sorgenti del kernel in alcune operazioni relative ad operazioni di rete. 
 
 \item \errcode{ENOMSG} \textit{No message of desired type}. Indica che in una
-  coda di messaggi del \textit{SysV IPC} non è presente nessun messaggio del
+  coda di messaggi del \textit{SysV IPC} non è presente nessun messaggio del
   tipo desiderato.
 
 \item \errcode{ENOSR} \textit{Out of streams resources}. Errore relativo agli
   \textit{STREAMS}, che indica l'assenza di risorse sufficienti a completare
   l'operazione richiesta. Quella degli \textit{STREAMS}\footnote{che non vanno
-    confusi con gli \textit{stream} di cap.~\ref{cha:files_std_interface}.}  è
-  interfaccia di programmazione originaria di System V, che non è implementata
+    confusi con gli \textit{stream} di cap.~\ref{cha:files_std_interface}.}  è
+  interfaccia di programmazione originaria di System V, che non è implementata
   da Linux, per cui questo errore non viene utilizzato.
 
 \item \errcode{ENOSTR} \textit{Device not a stream}. Altro errore relativo
   agli \textit{STREAMS}, anch'esso non utilizzato da Linux.
 
-\item \errcode{EOVERFLOW} \textit{Value too large for defined data type}. Si è
+\item \errcode{EOVERFLOW} \textit{Value too large for defined data type}. Si è
   chiesta la lettura di un dato dal \textit{SysV IPC} con \const{IPC\_STAT} ma
   il valore eccede la dimensione usata nel buffer di lettura.
 
-\item \errcode{EPROTO} \textit{Protocol error}. Indica che c'è stato un errore
+\item \errcode{EPROTO} \textit{Protocol error}. Indica che c'è stato un errore
   nel protocollo di rete usato dal socket; viene usato come errore generico
-  dall'interfaccia degli \textit{STREAMS} quando non si è in grado di
-  specificare un altro codice di errore che esprima più accuratamente la
+  dall'interfaccia degli \textit{STREAMS} quando non si è in grado di
+  specificare un altro codice di errore che esprima più accuratamente la
   situazione.
 
-\item \errcode{ETIME} \textit{Timer expired}. Indica che è avvenuto un timeout
+\item \errcode{ETIME} \textit{Timer expired}. Indica che è avvenuto un timeout
   nell'accesso ad una risorsa (ad esempio un semaforo). Compare nei sorgenti
   del kernel (in particolare per le funzioni relativa al bus USB) come
   indicazione di una mancata risposta di un dispositivo, con una descrizione
diff --git a/fileadv.tex b/fileadv.tex
index 814cf9e..2a32a3e 100644
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -12,12 +12,12 @@
 \label{cha:file_advanced}
 In questo capitolo affronteremo le tematiche relative alla gestione avanzata
 dei file. Inizieremo con la trattazione delle problematiche del \textit{file
-  locking} e poi prenderemo in esame le varie funzionalità avanzate che
-permettono una gestione più sofisticata dell'I/O su file, a partire da quelle
-che consentono di gestire l'accesso contemporaneo a più file esaminando le
-varie modalità alternative di gestire l'I/O per concludere con la gestione dei
+  locking} e poi prenderemo in esame le varie funzionalità avanzate che
+permettono una gestione più sofisticata dell'I/O su file, a partire da quelle
+che consentono di gestire l'accesso contemporaneo a più file esaminando le
+varie modalità alternative di gestire l'I/O per concludere con la gestione dei
 file mappati in memoria e le altre funzioni avanzate che consentono un
-controllo più dettagliato delle modalità di I/O.
+controllo più dettagliato delle modalità di I/O.
 
 
 \section{Il \textit{file locking}}
@@ -25,75 +25,75 @@ controllo pi
 
 \index{file!locking|(}
 
-In sez.~\ref{sec:file_sharing} abbiamo preso in esame le modalità in cui un
+In sez.~\ref{sec:file_sharing} abbiamo preso in esame le modalità in cui un
 sistema unix-like gestisce la condivisione dei file da parte di processi
-diversi. In quell'occasione si è visto come, con l'eccezione dei file aperti
-in \itindex{append~mode} \textit{append mode}, quando più processi scrivono
-contemporaneamente sullo stesso file non è possibile determinare la sequenza
+diversi. In quell'occasione si è visto come, con l'eccezione dei file aperti
+in \itindex{append~mode} \textit{append mode}, quando più processi scrivono
+contemporaneamente sullo stesso file non è possibile determinare la sequenza
 in cui essi opereranno.
 
-Questo causa la possibilità di una \itindex{race~condition} \textit{race
-  condition}; in generale le situazioni più comuni sono due: l'interazione fra
+Questo causa la possibilità di una \itindex{race~condition} \textit{race
+  condition}; in generale le situazioni più comuni sono due: l'interazione fra
 un processo che scrive e altri che leggono, in cui questi ultimi possono
 leggere informazioni scritte solo in maniera parziale o incompleta; o quella
 in cui diversi processi scrivono, mescolando in maniera imprevedibile il loro
 output sul file.
 
-In tutti questi casi il \textit{file locking} è la tecnica che permette di
+In tutti questi casi il \textit{file locking} è la tecnica che permette di
 evitare le \itindex{race~condition} \textit{race condition}, attraverso una
 serie di funzioni che permettono di bloccare l'accesso al file da parte di
-altri processi, così da evitare le sovrapposizioni, e garantire la atomicità
+altri processi, così da evitare le sovrapposizioni, e garantire la atomicità
 delle operazioni di lettura o scrittura.
 
 
 \subsection{L'\textit{advisory locking}}
 \label{sec:file_record_locking}
 
-La prima modalità di \textit{file locking} che è stata implementata nei
-sistemi unix-like è quella che viene usualmente chiamata \textit{advisory
+La prima modalità di \textit{file locking} che è stata implementata nei
+sistemi unix-like è quella che viene usualmente chiamata \textit{advisory
   locking},\footnote{Stevens in \cite{APUE} fa riferimento a questo argomento
   come al \textit{record locking}, dizione utilizzata anche dal manuale delle
   \acr{glibc}; nelle pagine di manuale si parla di \textit{discrectionary file
     lock} per \func{fcntl} e di \textit{advisory locking} per \func{flock},
   mentre questo nome viene usato da Stevens per riferirsi al \textit{file
-    locking} POSIX. Dato che la dizione \textit{record locking} è quantomeno
+    locking} POSIX. Dato che la dizione \textit{record locking} è quantomeno
   ambigua, in quanto in un sistema Unix non esiste niente che possa fare
-  riferimento al concetto di \textit{record}, alla fine si è scelto di
+  riferimento al concetto di \textit{record}, alla fine si è scelto di
   mantenere il nome \textit{advisory locking}.} in quanto sono i singoli
 processi, e non il sistema, che si incaricano di asserire e verificare se
 esistono delle condizioni di blocco per l'accesso ai file. 
 
 Questo significa che le funzioni \func{read} o \func{write} vengono eseguite
 comunque e non risentono affatto della presenza di un eventuale \textit{lock};
-pertanto è sempre compito dei vari processi che intendono usare il
+pertanto è sempre compito dei vari processi che intendono usare il
 \textit{file locking}, controllare esplicitamente lo stato dei file condivisi
 prima di accedervi, utilizzando le relative funzioni.
 
 In generale si distinguono due tipologie di \textit{file lock};\footnote{di
   seguito ci riferiremo sempre ai blocchi di accesso ai file con la
-  nomenclatura inglese di \textit{file lock}, o più brevemente con
+  nomenclatura inglese di \textit{file lock}, o più brevemente con
   \textit{lock}, per evitare confusioni linguistiche con il blocco di un
-  processo (cioè la condizione in cui il processo viene posto in stato di
-  \textit{sleep}).} la prima è il cosiddetto \textit{shared lock}, detto anche
+  processo (cioè la condizione in cui il processo viene posto in stato di
+  \textit{sleep}).} la prima è il cosiddetto \textit{shared lock}, detto anche
 \textit{read lock} in quanto serve a bloccare l'accesso in scrittura su un
-file affinché il suo contenuto non venga modificato mentre lo si legge. Si
-parla appunto di \textsl{blocco condiviso} in quanto più processi possono
+file affinché il suo contenuto non venga modificato mentre lo si legge. Si
+parla appunto di \textsl{blocco condiviso} in quanto più processi possono
 richiedere contemporaneamente uno \textit{shared lock} su un file per
 proteggere il loro accesso in lettura.
 
-La seconda tipologia è il cosiddetto \textit{exclusive lock}, detto anche
+La seconda tipologia è il cosiddetto \textit{exclusive lock}, detto anche
 \textit{write lock} in quanto serve a bloccare l'accesso su un file (sia in
 lettura che in scrittura) da parte di altri processi mentre lo si sta
-scrivendo. Si parla di \textsl{blocco esclusivo} appunto perché un solo
-processo alla volta può richiedere un \textit{exclusive lock} su un file per
+scrivendo. Si parla di \textsl{blocco esclusivo} appunto perché un solo
+processo alla volta può richiedere un \textit{exclusive lock} su un file per
 proteggere il suo accesso in scrittura.
 
 In Linux sono disponibili due interfacce per utilizzare l'\textit{advisory
-  locking}, la prima è quella derivata da BSD, che è basata sulla funzione
-\func{flock}, la seconda è quella recepita dallo standard POSIX.1 (che è
-derivata dall'interfaccia usata in System V), che è basata sulla funzione
+  locking}, la prima è quella derivata da BSD, che è basata sulla funzione
+\func{flock}, la seconda è quella recepita dallo standard POSIX.1 (che è
+derivata dall'interfaccia usata in System V), che è basata sulla funzione
 \func{fcntl}.  I \textit{file lock} sono implementati in maniera completamente
-indipendente nelle due interfacce,\footnote{in realtà con Linux questo avviene
+indipendente nelle due interfacce,\footnote{in realtà con Linux questo avviene
   solo dalla serie 2.0 dei kernel.}  che pertanto possono coesistere senza
 interferenze.
 
@@ -105,9 +105,9 @@ il processo prosegue l'esecuzione, altrimenti (a meno di non aver richiesto un
 comportamento non bloccante) viene posto in stato di sleep. Una volta finite
 le operazioni sul file si deve provvedere a rimuovere il blocco. 
 
-La situazione delle varie possibilità che si possono verificare è riassunta in
+La situazione delle varie possibilità che si possono verificare è riassunta in
 tab.~\ref{tab:file_file_lock}, dove si sono riportati, a seconda delle varie
-tipologie di blocco già presenti su un file, il risultato che si avrebbe in
+tipologie di blocco già presenti su un file, il risultato che si avrebbe in
 corrispondenza di una ulteriore richiesta da parte di un processo di un blocco
 nelle due tipologie di \textit{file lock} menzionate, con un successo o meno
 della richiesta.
@@ -132,14 +132,14 @@ della richiesta.
 
 Si tenga presente infine che il controllo di accesso e la gestione dei
 permessi viene effettuata quando si apre un file, l'unico controllo residuo
-che si può avere riguardo il \textit{file locking} è che il tipo di blocco che
-si vuole ottenere su un file deve essere compatibile con le modalità di
+che si può avere riguardo il \textit{file locking} è che il tipo di blocco che
+si vuole ottenere su un file deve essere compatibile con le modalità di
 apertura dello stesso (in lettura per un \textit{read lock} e in scrittura per
 un \textit{write lock}).
 
 %%  Si ricordi che
-%% la condizione per acquisire uno \textit{shared lock} è che il file non abbia
-%% già un \textit{exclusive lock} attivo, mentre per acquisire un
+%% la condizione per acquisire uno \textit{shared lock} è che il file non abbia
+%% già un \textit{exclusive lock} attivo, mentre per acquisire un
 %% \textit{exclusive lock} non deve essere presente nessun tipo di blocco.
 
 
@@ -148,22 +148,22 @@ un \textit{write lock}).
 
 La prima interfaccia per il \textit{file locking}, quella derivata da BSD,
 permette di eseguire un blocco solo su un intero file; la funzione usata per
-richiedere e rimuovere un \textit{file lock} è \funcd{flock}, ed il suo
-prototipo è:
+richiedere e rimuovere un \textit{file lock} è \funcd{flock}, ed il suo
+prototipo è:
 \begin{prototype}{sys/file.h}{int flock(int fd, int operation)}
   
   Applica o rimuove un \textit{file lock} sul file \param{fd}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
-    \item[\errcode{EWOULDBLOCK}] il file ha già un blocco attivo, e si è
+    \item[\errcode{EWOULDBLOCK}] il file ha già un blocco attivo, e si è
       specificato \const{LOCK\_NB}.
     \end{errlist}
   }
 \end{prototype}
 
-La funzione può essere usata per acquisire o rilasciare un \textit{file lock}
+La funzione può essere usata per acquisire o rilasciare un \textit{file lock}
 a seconda di quanto specificato tramite il valore dell'argomento
 \param{operation}; questo viene interpretato come maschera binaria, e deve
 essere passato costruendo il valore con un OR aritmetico delle costanti
@@ -191,45 +191,45 @@ riportate in tab.~\ref{tab:file_flock_operation}.
 I primi due valori, \const{LOCK\_SH} e \const{LOCK\_EX} permettono di
 richiedere un \textit{file lock}, ed ovviamente devono essere usati in maniera
 alternativa. Se si specifica anche \const{LOCK\_NB} la funzione non si
-bloccherà qualora il \textit{file lock} non possa essere acquisito, ma
-ritornerà subito con un errore di \errcode{EWOULDBLOCK}. Per rilasciare un
-\textit{file lock} si dovrà invece usare \const{LOCK\_UN}.
+bloccherà qualora il \textit{file lock} non possa essere acquisito, ma
+ritornerà subito con un errore di \errcode{EWOULDBLOCK}. Per rilasciare un
+\textit{file lock} si dovrà invece usare \const{LOCK\_UN}.
 
-Si tenga presente che non esiste una modalità per eseguire atomicamente un
+Si tenga presente che non esiste una modalità per eseguire atomicamente un
 cambiamento del tipo di blocco (da \textit{shared lock} a \textit{esclusive
-  lock}), il blocco deve essere prima rilasciato e poi richiesto, ed è sempre
+  lock}), il blocco deve essere prima rilasciato e poi richiesto, ed è sempre
 possibile che nel frattempo abbia successo un'altra richiesta pendente,
 facendo fallire la riacquisizione.
 
-Si tenga presente infine che \func{flock} non è supportata per i file
-mantenuti su NFS, in questo caso, se si ha la necessità di utilizzare il
+Si tenga presente infine che \func{flock} non è supportata per i file
+mantenuti su NFS, in questo caso, se si ha la necessità di utilizzare il
 \textit{file locking}, occorre usare l'interfaccia del \textit{file locking}
-POSIX basata su \func{fcntl} che è in grado di funzionare anche attraverso
+POSIX basata su \func{fcntl} che è in grado di funzionare anche attraverso
 NFS, a condizione ovviamente che sia il client che il server supportino questa
-funzionalità.
+funzionalità.
 
-La semantica del \textit{file locking} di BSD inoltre è diversa da quella del
+La semantica del \textit{file locking} di BSD inoltre è diversa da quella del
 \textit{file locking} POSIX, in particolare per quanto riguarda il
 comportamento dei \textit{file lock} nei confronti delle due funzioni
 \func{dup} e \func{fork}.  Per capire queste differenze occorre descrivere con
 maggiore dettaglio come viene realizzato dal kernel il \textit{file locking}
 per entrambe le interfacce.
 
-In fig.~\ref{fig:file_flock_struct} si è riportato uno schema essenziale
+In fig.~\ref{fig:file_flock_struct} si è riportato uno schema essenziale
 dell'implementazione del \textit{file locking} in stile BSD su Linux. Il punto
-fondamentale da capire è che un \textit{file lock}, qualunque sia
+fondamentale da capire è che un \textit{file lock}, qualunque sia
 l'interfaccia che si usa, anche se richiesto attraverso un file descriptor,
-agisce sempre su di un file; perciò le informazioni relative agli eventuali
+agisce sempre su di un file; perciò le informazioni relative agli eventuali
 \textit{file lock} sono mantenute dal kernel a livello di
 inode\index{inode},\footnote{in particolare, come accennato in
   fig.~\ref{fig:file_flock_struct}, i \textit{file lock} sono mantenuti in una
   \itindex{linked~list} \textit{linked list} di strutture
-  \struct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
+  \struct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
   mantenuto dal campo \var{i\_flock} della struttura \struct{inode} (per le
   definizioni esatte si faccia riferimento al file \file{fs.h} nei sorgenti
   del kernel).  Un bit del campo \var{fl\_flags} di specifica se si tratta di
   un lock in semantica BSD (\const{FL\_FLOCK}) o POSIX (\const{FL\_POSIX}).}
-dato che questo è l'unico riferimento in comune che possono avere due processi
+dato che questo è l'unico riferimento in comune che possono avere due processi
 diversi che aprono lo stesso file.
 
 \begin{figure}[htb]
@@ -241,37 +241,37 @@ diversi che aprono lo stesso file.
 \end{figure}
 
 La richiesta di un \textit{file lock} prevede una scansione della lista per
-determinare se l'acquisizione è possibile, ed in caso positivo l'aggiunta di
-un nuovo elemento.\footnote{cioè una nuova struttura \struct{file\_lock}.}
+determinare se l'acquisizione è possibile, ed in caso positivo l'aggiunta di
+un nuovo elemento.\footnote{cioè una nuova struttura \struct{file\_lock}.}
 Nel caso dei blocchi creati con \func{flock} la semantica della funzione
 prevede che sia \func{dup} che \func{fork} non creino ulteriori istanze di un
 \textit{file lock} quanto piuttosto degli ulteriori riferimenti allo
 stesso. Questo viene realizzato dal kernel secondo lo schema di
 fig.~\ref{fig:file_flock_struct}, associando ad ogni nuovo \textit{file lock}
-un puntatore\footnote{il puntatore è mantenuto nel campo \var{fl\_file} di
+un puntatore\footnote{il puntatore è mantenuto nel campo \var{fl\_file} di
   \struct{file\_lock}, e viene utilizzato solo per i \textit{file lock} creati
   con la semantica BSD.} alla voce nella \itindex{file~table} \textit{file
-  table} da cui si è richiesto il blocco, che così ne identifica il titolare.
+  table} da cui si è richiesto il blocco, che così ne identifica il titolare.
 
 Questa struttura prevede che, quando si richiede la rimozione di un
 \textit{file lock}, il kernel acconsenta solo se la richiesta proviene da un
 file descriptor che fa riferimento ad una voce nella \itindex{file~table}
 \textit{file table} corrispondente a quella registrata nel blocco.  Allora se
 ricordiamo quanto visto in sez.~\ref{sec:file_dup} e
-sez.~\ref{sec:file_sharing}, e cioè che i file descriptor duplicati e quelli
+sez.~\ref{sec:file_sharing}, e cioè che i file descriptor duplicati e quelli
 ereditati in un processo figlio puntano sempre alla stessa voce nella
-\itindex{file~table} \textit{file table}, si può capire immediatamente quali
+\itindex{file~table} \textit{file table}, si può capire immediatamente quali
 sono le conseguenze nei confronti delle funzioni \func{dup} e \func{fork}.
 
-Sarà così possibile rimuovere un \textit{file lock} attraverso uno qualunque
+Sarà così possibile rimuovere un \textit{file lock} attraverso uno qualunque
 dei file descriptor che fanno riferimento alla stessa voce nella
-\itindex{file~table} \textit{file table}, anche se questo è diverso da quello
-con cui lo si è creato,\footnote{attenzione, questo non vale se il file
+\itindex{file~table} \textit{file table}, anche se questo è diverso da quello
+con cui lo si è creato,\footnote{attenzione, questo non vale se il file
   descriptor fa riferimento allo stesso file, ma attraverso una voce diversa
   della \itindex{file~table} \textit{file table}, come accade tutte le volte
-  che si apre più volte lo stesso file.} o se si esegue la rimozione in un
+  che si apre più volte lo stesso file.} o se si esegue la rimozione in un
 processo figlio. Inoltre una volta tolto un \textit{file lock} su un file, la
-rimozione avrà effetto su tutti i file descriptor che condividono la stessa
+rimozione avrà effetto su tutti i file descriptor che condividono la stessa
 voce nella \itindex{file~table} \textit{file table}, e quindi, nel caso di
 file descriptor ereditati attraverso una \func{fork}, anche per processi
 diversi.
@@ -280,9 +280,9 @@ Infine, per evitare che la terminazione imprevista di un processo lasci attivi
 dei \textit{file lock}, quando un file viene chiuso il kernel provvede anche a
 rimuovere tutti i blocchi ad esso associati. Anche in questo caso occorre
 tenere presente cosa succede quando si hanno file descriptor duplicati; in tal
-caso infatti il file non verrà effettivamente chiuso (ed il blocco rimosso)
+caso infatti il file non verrà effettivamente chiuso (ed il blocco rimosso)
 fintanto che non viene rilasciata la relativa voce nella \itindex{file~table}
-\textit{file table}; e questo avverrà solo quando tutti i file descriptor che
+\textit{file table}; e questo avverrà solo quando tutti i file descriptor che
 fanno riferimento alla stessa voce sono stati chiusi.  Quindi, nel caso ci
 siano duplicati o processi figli che mantengono ancora aperto un file
 descriptor, il \textit{file lock} non viene rilasciato.
@@ -291,9 +291,9 @@ descriptor, il \textit{file lock} non viene rilasciato.
 \subsection{Il \textit{file locking} POSIX}
 \label{sec:file_posix_lock}
 
-La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è
+La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è
 quella standardizzata da POSIX, basata sulla funzione \func{fcntl}. Abbiamo
-già trattato questa funzione nelle sue molteplici possibilità di utilizzo in
+già trattato questa funzione nelle sue molteplici possibilità di utilizzo in
 sez.~\ref{sec:file_fcntl}. Quando la si impiega per il \textit{file locking}
 essa viene usata solo secondo il seguente prototipo:
 \begin{prototype}{fcntl.h}{int fcntl(int fd, int cmd, struct flock *lock)}
@@ -301,19 +301,19 @@ essa viene usata solo secondo il seguente prototipo:
   Applica o rimuove un \textit{file lock} sul file \param{fd}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
-    \item[\errcode{EACCES}] l'operazione è proibita per la presenza di
+    \item[\errcode{EACCES}] l'operazione è proibita per la presenza di
       \textit{file lock} da parte di altri processi.
     \item[\errcode{ENOLCK}] il sistema non ha le risorse per il blocco: ci
-      sono troppi segmenti di \textit{lock} aperti, si è esaurita la tabella
-      dei \textit{file lock}, o il protocollo per il blocco remoto è fallito.
-    \item[\errcode{EDEADLK}] si è richiesto un \textit{lock} su una regione
-      bloccata da un altro processo che è a sua volta in attesa dello sblocco
+      sono troppi segmenti di \textit{lock} aperti, si è esaurita la tabella
+      dei \textit{file lock}, o il protocollo per il blocco remoto è fallito.
+    \item[\errcode{EDEADLK}] si è richiesto un \textit{lock} su una regione
+      bloccata da un altro processo che è a sua volta in attesa dello sblocco
       di un \textit{lock} mantenuto dal processo corrente; si avrebbe pertanto
-      un \itindex{deadlock} \textit{deadlock}. Non è garantito che il sistema
+      un \itindex{deadlock} \textit{deadlock}. Non è garantito che il sistema
       riconosca sempre questa situazione.
-    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima
+    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima
       di poter acquisire un \textit{file lock}.
     \end{errlist}
     ed inoltre \errval{EBADF}, \errval{EFAULT}.
@@ -321,14 +321,14 @@ essa viene usata solo secondo il seguente prototipo:
 \end{prototype}
 
 Al contrario di quanto avviene con l'interfaccia basata su \func{flock} con
-\func{fcntl} è possibile bloccare anche delle singole sezioni di un file, fino
+\func{fcntl} è possibile bloccare anche delle singole sezioni di un file, fino
 al singolo byte. Inoltre la funzione permette di ottenere alcune informazioni
 relative agli eventuali blocchi preesistenti.  Per poter fare tutto questo la
 funzione utilizza come terzo argomento una apposita struttura \struct{flock}
-(la cui definizione è riportata in fig.~\ref{fig:struct_flock}) nella quale
+(la cui definizione è riportata in fig.~\ref{fig:struct_flock}) nella quale
 inserire tutti i dati relativi ad un determinato blocco. Si tenga presente poi
 che un \textit{file lock} fa sempre riferimento ad una regione, per cui si
-potrà avere un conflitto anche se c'è soltanto una sovrapposizione parziale
+potrà avere un conflitto anche se c'è soltanto una sovrapposizione parziale
 con un'altra regione bloccata.
 
 \begin{figure}[!bht]
@@ -352,11 +352,11 @@ dell'omonimo argomento di \func{lseek}, coi tre possibili valori
 \const{SEEK\_SET}, \const{SEEK\_CUR} e \const{SEEK\_END}, (si vedano le
 relative descrizioni in sez.~\ref{sec:file_lseek}).
 
-Si tenga presente che un \textit{file lock} può essere richiesto anche per una
-regione al di là della corrente fine del file, così che una eventuale
+Si tenga presente che un \textit{file lock} può essere richiesto anche per una
+regione al di là della corrente fine del file, così che una eventuale
 estensione dello stesso resti coperta dal blocco. Inoltre se si specifica un
 valore nullo per \var{l\_len} il blocco si considera esteso fino alla
-dimensione massima del file; in questo modo è possibile bloccare una qualunque
+dimensione massima del file; in questo modo è possibile bloccare una qualunque
 regione a partire da un certo punto fino alla fine del file, coprendo
 automaticamente quanto eventualmente aggiunto in coda allo stesso.
 
@@ -378,7 +378,7 @@ automaticamente quanto eventualmente aggiunto in coda allo stesso.
 \end{table}
 
 Il tipo di \textit{file lock} richiesto viene specificato dal campo
-\var{l\_type}, esso può assumere i tre valori definiti dalle costanti
+\var{l\_type}, esso può assumere i tre valori definiti dalle costanti
 riportate in tab.~\ref{tab:file_flock_type}, che permettono di richiedere
 rispettivamente uno \textit{shared lock}, un \textit{esclusive lock}, e la
 rimozione di un blocco precedentemente acquisito. Infine il campo \var{l\_pid}
@@ -387,47 +387,47 @@ viene usato solo in caso di lettura, quando si chiama \func{fcntl} con
 \textit{file lock}.
 
 Oltre a quanto richiesto tramite i campi di \struct{flock}, l'operazione
-effettivamente svolta dalla funzione è stabilita dal valore dall'argomento
-\param{cmd} che, come già riportato in sez.~\ref{sec:file_fcntl}, specifica
+effettivamente svolta dalla funzione è stabilita dal valore dall'argomento
+\param{cmd} che, come già riportato in sez.~\ref{sec:file_fcntl}, specifica
 l'azione da compiere; i valori relativi al \textit{file locking} sono tre:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\const{F\_GETLK}] verifica se il \textit{file lock} specificato dalla
-  struttura puntata da \param{lock} può essere acquisito: in caso negativo
-  sovrascrive la struttura \param{flock} con i valori relativi al blocco già
+  struttura puntata da \param{lock} può essere acquisito: in caso negativo
+  sovrascrive la struttura \param{flock} con i valori relativi al blocco già
   esistente che ne blocca l'acquisizione, altrimenti si limita a impostarne il
   campo \var{l\_type} con il valore \const{F\_UNLCK}.
 \item[\const{F\_SETLK}] se il campo \var{l\_type} della struttura puntata da
-  \param{lock} è \const{F\_RDLCK} o \const{F\_WRLCK} richiede il
-  corrispondente \textit{file lock}, se è \const{F\_UNLCK} lo rilascia. Nel
+  \param{lock} è \const{F\_RDLCK} o \const{F\_WRLCK} richiede il
+  corrispondente \textit{file lock}, se è \const{F\_UNLCK} lo rilascia. Nel
   caso la richiesta non possa essere soddisfatta a causa di un blocco
   preesistente la funzione ritorna immediatamente con un errore di
   \errcode{EACCES} o di \errcode{EAGAIN}.
-\item[\const{F\_SETLKW}] è identica a \const{F\_SETLK}, ma se la richiesta di
-  non può essere soddisfatta per la presenza di un altro blocco, mette il
+\item[\const{F\_SETLKW}] è identica a \const{F\_SETLK}, ma se la richiesta di
+  non può essere soddisfatta per la presenza di un altro blocco, mette il
   processo in stato di attesa fintanto che il blocco precedente non viene
   rilasciato. Se l'attesa viene interrotta da un segnale la funzione ritorna
   con un errore di \errcode{EINTR}.
 \end{basedescript}
 
 Si noti che per quanto detto il comando \const{F\_GETLK} non serve a rilevare
-una presenza generica di blocco su un file, perché se ne esistono altri
+una presenza generica di blocco su un file, perché se ne esistono altri
 compatibili con quello richiesto, la funzione ritorna comunque impostando
 \var{l\_type} a \const{F\_UNLCK}.  Inoltre a seconda del valore di
-\var{l\_type} si potrà controllare o l'esistenza di un qualunque tipo di
-blocco (se è \const{F\_WRLCK}) o di \textit{write lock} (se è
-\const{F\_RDLCK}). Si consideri poi che può esserci più di un blocco che
+\var{l\_type} si potrà controllare o l'esistenza di un qualunque tipo di
+blocco (se è \const{F\_WRLCK}) o di \textit{write lock} (se è
+\const{F\_RDLCK}). Si consideri poi che può esserci più di un blocco che
 impedisce l'acquisizione di quello richiesto (basta che le regioni si
-sovrappongano), ma la funzione ne riporterà sempre soltanto uno, impostando
+sovrappongano), ma la funzione ne riporterà sempre soltanto uno, impostando
 \var{l\_whence} a \const{SEEK\_SET} ed i valori \var{l\_start} e \var{l\_len}
-per indicare quale è la regione bloccata.
+per indicare quale è la regione bloccata.
 
 Infine si tenga presente che effettuare un controllo con il comando
-\const{F\_GETLK} e poi tentare l'acquisizione con \const{F\_SETLK} non è una
+\const{F\_GETLK} e poi tentare l'acquisizione con \const{F\_SETLK} non è una
 operazione atomica (un altro processo potrebbe acquisire un blocco fra le due
 chiamate) per cui si deve sempre verificare il codice di ritorno di
 \func{fcntl}\footnote{controllare il codice di ritorno delle funzioni invocate
-  è comunque una buona norma di programmazione, che permette di evitare un
-  sacco di errori difficili da tracciare proprio perché non vengono rilevati.}
+  è comunque una buona norma di programmazione, che permette di evitare un
+  sacco di errori difficili da tracciare proprio perché non vengono rilevati.}
 quando la si invoca con \const{F\_SETLK}, per controllare che il blocco sia
 stato effettivamente acquisito.
 
@@ -441,10 +441,10 @@ Non operando a livello di interi file, il \textit{file locking} POSIX
 introduce un'ulteriore complicazione; consideriamo la situazione illustrata in
 fig.~\ref{fig:file_flock_dead}, in cui il processo A blocca la regione 1 e il
 processo B la regione 2. Supponiamo che successivamente il processo A richieda
-un lock sulla regione 2 che non può essere acquisito per il preesistente lock
-del processo 2; il processo 1 si bloccherà fintanto che il processo 2 non
+un lock sulla regione 2 che non può essere acquisito per il preesistente lock
+del processo 2; il processo 1 si bloccherà fintanto che il processo 2 non
 rilasci il blocco. Ma cosa accade se il processo 2 nel frattempo tenta a sua
-volta di ottenere un lock sulla regione A? Questa è una tipica situazione che
+volta di ottenere un lock sulla regione A? Questa è una tipica situazione che
 porta ad un \itindex{deadlock} \textit{deadlock}, dato che a quel punto anche
 il processo 2 si bloccherebbe, e niente potrebbe sbloccare l'altro processo.
 Per questo motivo il kernel si incarica di rilevare situazioni di questo tipo,
@@ -454,18 +454,18 @@ cerca di acquisire un blocco che porterebbe ad un \itindex{deadlock}
 
 Per capire meglio il funzionamento del \textit{file locking} in semantica
 POSIX (che differisce alquanto rispetto da quello di BSD, visto
-sez.~\ref{sec:file_flock}) esaminiamo più in dettaglio come viene gestito dal
-kernel. Lo schema delle strutture utilizzate è riportato in
-fig.~\ref{fig:file_posix_lock}; come si vede esso è molto simile all'analogo
+sez.~\ref{sec:file_flock}) esaminiamo più in dettaglio come viene gestito dal
+kernel. Lo schema delle strutture utilizzate è riportato in
+fig.~\ref{fig:file_posix_lock}; come si vede esso è molto simile all'analogo
 di fig.~\ref{fig:file_flock_struct}:\footnote{in questo caso nella figura si
   sono evidenziati solo i campi di \struct{file\_lock} significativi per la
   semantica POSIX, in particolare adesso ciascuna struttura contiene, oltre al
   \acr{pid} del processo in \var{fl\_pid}, la sezione di file che viene
-  bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}.  La struttura è
-  comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è
+  bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}.  La struttura è
+  comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è
   impostato il bit \const{FL\_POSIX} ed il campo \var{fl\_file} non viene
-  usato.} il blocco è sempre associato \index{inode} all'inode, solo che in
-questo caso la titolarità non viene identificata con il riferimento ad una
+  usato.} il blocco è sempre associato \index{inode} all'inode, solo che in
+questo caso la titolarità non viene identificata con il riferimento ad una
 voce nella \itindex{file~table} \textit{file table}, ma con il valore del
 \acr{pid} del processo.
 
@@ -477,58 +477,58 @@ voce nella \itindex{file~table} \textit{file table}, ma con il valore del
 \end{figure}
 
 Quando si richiede un \textit{file lock} il kernel effettua una scansione di
-tutti i blocchi presenti sul file\footnote{scandisce cioè la
+tutti i blocchi presenti sul file\footnote{scandisce cioè la
   \itindex{linked~list} \textit{linked list} delle strutture
   \struct{file\_lock}, scartando automaticamente quelle per cui
-  \var{fl\_flags} non è \const{FL\_POSIX}, così che le due interfacce restano
+  \var{fl\_flags} non è \const{FL\_POSIX}, così che le due interfacce restano
   ben separate.}  per verificare se la regione richiesta non si sovrappone ad
-una già bloccata, in caso affermativo decide in base al tipo di blocco, in
+una già bloccata, in caso affermativo decide in base al tipo di blocco, in
 caso negativo il nuovo blocco viene comunque acquisito ed aggiunto alla lista.
 
 Nel caso di rimozione invece questa viene effettuata controllando che il
 \acr{pid} del processo richiedente corrisponda a quello contenuto nel blocco.
-Questa diversa modalità ha delle conseguenze precise riguardo il comportamento
-dei \textit{file lock} POSIX. La prima conseguenza è che un \textit{file lock}
+Questa diversa modalità ha delle conseguenze precise riguardo il comportamento
+dei \textit{file lock} POSIX. La prima conseguenza è che un \textit{file lock}
 POSIX non viene mai ereditato attraverso una \func{fork}, dato che il processo
-figlio avrà un \acr{pid} diverso, mentre passa indenne attraverso una
+figlio avrà un \acr{pid} diverso, mentre passa indenne attraverso una
 \func{exec} in quanto il \acr{pid} resta lo stesso.  Questo comporta che, al
 contrario di quanto avveniva con la semantica BSD, quando un processo termina
 tutti i \textit{file lock} da esso detenuti vengono immediatamente rilasciati.
 
-La seconda conseguenza è che qualunque file descriptor che faccia riferimento
+La seconda conseguenza è che qualunque file descriptor che faccia riferimento
 allo stesso file (che sia stato ottenuto con una \func{dup} o con una
-\func{open} in questo caso non fa differenza) può essere usato per rimuovere
-un blocco, dato che quello che conta è solo il \acr{pid} del processo. Da
+\func{open} in questo caso non fa differenza) può essere usato per rimuovere
+un blocco, dato che quello che conta è solo il \acr{pid} del processo. Da
 questo deriva una ulteriore sottile differenza di comportamento: dato che alla
 chiusura di un file i blocchi ad esso associati vengono rimossi, nella
-semantica POSIX basterà chiudere un file descriptor qualunque per cancellare
+semantica POSIX basterà chiudere un file descriptor qualunque per cancellare
 tutti i blocchi relativi al file cui esso faceva riferimento, anche se questi
 fossero stati creati usando altri file descriptor che restano aperti.
 
 Dato che il controllo sull'accesso ai blocchi viene eseguito sulla base del
 \acr{pid} del processo, possiamo anche prendere in considerazione un altro
-degli aspetti meno chiari di questa interfaccia e cioè cosa succede quando si
+degli aspetti meno chiari di questa interfaccia e cioè cosa succede quando si
 richiedono dei blocchi su regioni che si sovrappongono fra loro all'interno
 stesso processo. Siccome il controllo, come nel caso della rimozione, si basa
 solo sul \acr{pid} del processo che chiama la funzione, queste richieste
 avranno sempre successo.
 
 Nel caso della semantica BSD, essendo i lock relativi a tutto un file e non
-accumulandosi,\footnote{questa ultima caratteristica è vera in generale, se
-  cioè si richiede più volte lo stesso \textit{file lock}, o più blocchi sulla
+accumulandosi,\footnote{questa ultima caratteristica è vera in generale, se
+  cioè si richiede più volte lo stesso \textit{file lock}, o più blocchi sulla
   stessa sezione di file, le richieste non si cumulano e basta una sola
   richiesta di rilascio per cancellare il blocco.}  la cosa non ha alcun
 effetto; la funzione ritorna con successo, senza che il kernel debba
 modificare la lista dei \textit{file lock}.  In questo caso invece si possono
-avere una serie di situazioni diverse: ad esempio è possibile rimuovere con
-una sola chiamata più \textit{file lock} distinti (indicando in una regione
+avere una serie di situazioni diverse: ad esempio è possibile rimuovere con
+una sola chiamata più \textit{file lock} distinti (indicando in una regione
 che si sovrapponga completamente a quelle di questi ultimi), o rimuovere solo
 una parte di un blocco preesistente (indicando una regione contenuta in quella
 di un altro blocco), creando un buco, o coprire con un nuovo blocco altri
-\textit{file lock} già ottenuti, e così via, a secondo di come si
+\textit{file lock} già ottenuti, e così via, a secondo di come si
 sovrappongono le regioni richieste e del tipo di operazione richiesta.  Il
 comportamento seguito in questo caso che la funzione ha successo ed esegue
-l'operazione richiesta sulla regione indicata; è compito del kernel
+l'operazione richiesta sulla regione indicata; è compito del kernel
 preoccuparsi di accorpare o dividere le voci nella lista dei \textit{file
   lock} per far si che le regioni bloccate da essa risultanti siano coerenti
 con quanto necessario a soddisfare l'operazione richiesta.
@@ -543,23 +543,23 @@ con quanto necessario a soddisfare l'operazione richiesta.
   \label{fig:file_flock_code}
 \end{figure}
 
-Per fare qualche esempio sul \textit{file locking} si è scritto un programma che
+Per fare qualche esempio sul \textit{file locking} si è scritto un programma che
 permette di bloccare una sezione di un file usando la semantica POSIX, o un
-intero file usando la semantica BSD; in fig.~\ref{fig:file_flock_code} è
-riportata il corpo principale del codice del programma, (il testo completo è
+intero file usando la semantica BSD; in fig.~\ref{fig:file_flock_code} è
+riportata il corpo principale del codice del programma, (il testo completo è
 allegato nella directory dei sorgenti).
 
-La sezione relativa alla gestione delle opzioni al solito si è omessa, come la
+La sezione relativa alla gestione delle opzioni al solito si è omessa, come la
 funzione che stampa le istruzioni per l'uso del programma, essa si cura di
 impostare le variabili \var{type}, \var{start} e \var{len}; queste ultime due
 vengono inizializzate al valore numerico fornito rispettivamente tramite gli
 switch \code{-s} e \cmd{-l}, mentre il valore della prima viene impostato con
 le opzioni \cmd{-w} e \cmd{-r} si richiede rispettivamente o un \textit{write
   lock} o \textit{read lock} (i due valori sono esclusivi, la variabile
-assumerà quello che si è specificato per ultimo). Oltre a queste tre vengono
+assumerà quello che si è specificato per ultimo). Oltre a queste tre vengono
 pure impostate la variabile \var{bsd}, che abilita la semantica omonima quando
-si invoca l'opzione \cmd{-f} (il valore preimpostato è nullo, ad indicare la
-semantica POSIX), e la variabile \var{cmd} che specifica la modalità di
+si invoca l'opzione \cmd{-f} (il valore preimpostato è nullo, ad indicare la
+semantica POSIX), e la variabile \var{cmd} che specifica la modalità di
 richiesta del \textit{file lock} (bloccante o meno), a seconda dell'opzione
 \cmd{-b}.
 
@@ -571,7 +571,7 @@ comportamento dipende dalla semantica scelta; nel caso sia BSD occorre
 reimpostare il valore di \var{cmd} per l'uso con \func{flock}; infatti il
 valore preimpostato fa riferimento alla semantica POSIX e vale rispettivamente
 \const{F\_SETLKW} o \const{F\_SETLK} a seconda che si sia impostato o meno la
-modalità bloccante.
+modalità bloccante.
 
 Nel caso si sia scelta la semantica BSD (\texttt{\small 25--34}) prima si
 controlla (\texttt{\small 27--31}) il valore di \var{cmd} per determinare se
@@ -579,14 +579,14 @@ si vuole effettuare una chiamata bloccante o meno, reimpostandone il valore
 opportunamente, dopo di che a seconda del tipo di blocco al valore viene
 aggiunta la relativa opzione (con un OR aritmetico, dato che \func{flock}
 vuole un argomento \param{operation} in forma di maschera binaria.  Nel caso
-invece che si sia scelta la semantica POSIX le operazioni sono molto più
+invece che si sia scelta la semantica POSIX le operazioni sono molto più
 immediate, si prepara (\texttt{\small 36--40}) la struttura per il lock, e lo
 esegue (\texttt{\small 41}).
 
 In entrambi i casi dopo aver richiesto il blocco viene controllato il
 risultato uscendo (\texttt{\small 44--46}) in caso di errore, o stampando un
 messaggio (\texttt{\small 47--49}) in caso di successo. Infine il programma si
-pone in attesa (\texttt{\small 50}) finché un segnale (ad esempio un \cmd{C-c}
+pone in attesa (\texttt{\small 50}) finché un segnale (ad esempio un \cmd{C-c}
 dato da tastiera) non lo interrompa; in questo caso il programma termina, e
 tutti i blocchi vengono rilasciati.
 
@@ -602,8 +602,8 @@ Lock acquired
 \end{verbatim}%$
 \end{minipage}\vspace{1mm}
 \par\noindent
-il programma segnalerà di aver acquisito un blocco e si bloccherà; in questo
-caso si è usato il \textit{file locking} POSIX e non avendo specificato niente
+il programma segnalerà di aver acquisito un blocco e si bloccherà; in questo
+caso si è usato il \textit{file locking} POSIX e non avendo specificato niente
 riguardo alla sezione che si vuole bloccare sono stati usati i valori
 preimpostati che bloccano tutto il file. A questo punto se proviamo ad
 eseguire lo stesso comando in un altro terminale, e avremo lo stesso
@@ -617,9 +617,9 @@ Failed lock: Resource temporarily unavailable
 \end{verbatim}%$
 \end{minipage}\vspace{1mm}
 \par\noindent
-come ci aspettiamo il programma terminerà segnalando l'indisponibilità del
-blocco, dato che il file è bloccato dal precedente \textit{read lock}. Si noti
-che il risultato è lo stesso anche se si richiede il blocco su una sola parte
+come ci aspettiamo il programma terminerà segnalando l'indisponibilità del
+blocco, dato che il file è bloccato dal precedente \textit{read lock}. Si noti
+che il risultato è lo stesso anche se si richiede il blocco su una sola parte
 del file con il comando:
 
 \vspace{1mm}
@@ -674,10 +674,10 @@ Failed lock: Resource temporarily unavailable
 \end{verbatim}%$
 \end{minipage}\vspace{1mm}
 \par\noindent
-come ci aspettiamo questo non sarà consentito.
+come ci aspettiamo questo non sarà consentito.
 
-Il programma di norma esegue il tentativo di acquisire il lock in modalità non
-bloccante, se però usiamo l'opzione \cmd{-b} possiamo impostare la modalità
+Il programma di norma esegue il tentativo di acquisire il lock in modalità non
+bloccante, se però usiamo l'opzione \cmd{-b} possiamo impostare la modalità
 bloccante, riproviamo allora a ripetere le prove precedenti con questa
 opzione:
 
@@ -689,7 +689,7 @@ opzione:
 \end{minipage}\vspace{1mm}
 \par\noindent
 il primo comando acquisisce subito un \textit{read lock}, e quindi non cambia
-nulla, ma se proviamo adesso a richiedere un \textit{write lock} che non potrà
+nulla, ma se proviamo adesso a richiedere un \textit{write lock} che non potrà
 essere acquisito otterremo:
 
 \vspace{1mm}
@@ -699,7 +699,7 @@ essere acquisito otterremo:
 \end{verbatim}%$
 \end{minipage}\vspace{1mm}
 \par\noindent
-il programma cioè si bloccherà nella chiamata a \func{fcntl}; se a questo
+il programma cioè si bloccherà nella chiamata a \func{fcntl}; se a questo
 punto rilasciamo il precedente blocco (terminando il primo comando un
 \texttt{C-c} sul terminale) potremo verificare che sull'altro terminale il
 blocco viene acquisito, con la comparsa di una nuova riga:
@@ -713,8 +713,8 @@ Lock acquired
 \end{minipage}\vspace{3mm}
 \par\noindent
 
-Un'altra cosa che si può controllare con il nostro programma è l'interazione
-fra i due tipi di blocco; se ripartiamo dal primo comando con cui si è
+Un'altra cosa che si può controllare con il nostro programma è l'interazione
+fra i due tipi di blocco; se ripartiamo dal primo comando con cui si è
 ottenuto un blocco in lettura sull'intero file, possiamo verificare cosa
 succede quando si cerca di ottenere un blocco in scrittura con la semantica
 BSD:
@@ -738,22 +738,22 @@ blocchi applicati con l'altra non avrebbero nessun effetto.
 \label{sec:file_lockf}
 
 Abbiamo visto come l'interfaccia POSIX per il \textit{file locking} sia molto
-più potente e flessibile di quella di BSD, questo comporta anche una maggiore
-complessità per via delle varie opzioni da passare a \func{fcntl}. Per questo
-motivo è disponibile anche una interfaccia semplificata (ripresa da System V)
-che utilizza la funzione \funcd{lockf}, il cui prototipo è:
+più potente e flessibile di quella di BSD, questo comporta anche una maggiore
+complessità per via delle varie opzioni da passare a \func{fcntl}. Per questo
+motivo è disponibile anche una interfaccia semplificata (ripresa da System V)
+che utilizza la funzione \funcd{lockf}, il cui prototipo è:
 \begin{prototype}{sys/file.h}{int lockf(int fd, int cmd, off\_t len)}
   
   Applica, controlla o rimuove un \textit{file lock} sul file \param{fd}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
-    \item[\errcode{EWOULDBLOCK}] non è possibile acquisire il lock, e si è
-      selezionato \const{LOCK\_NB}, oppure l'operazione è proibita perché il
-      file è mappato in memoria.
+    \item[\errcode{EWOULDBLOCK}] non è possibile acquisire il lock, e si è
+      selezionato \const{LOCK\_NB}, oppure l'operazione è proibita perché il
+      file è mappato in memoria.
     \item[\errcode{ENOLCK}] il sistema non ha le risorse per il blocco: ci
-      sono troppi segmenti di \textit{lock} aperti, si è esaurita la tabella
+      sono troppi segmenti di \textit{lock} aperti, si è esaurita la tabella
       dei \textit{file lock}.
     \end{errlist}
     ed inoltre \errval{EBADF}, \errval{EINVAL}.
@@ -772,12 +772,12 @@ tab.~\ref{tab:file_lockf_type}.
     \textbf{Valore} & \textbf{Significato} \\
     \hline
     \hline
-    \const{LOCK\_SH}& Richiede uno \textit{shared lock}. Più processi possono
+    \const{LOCK\_SH}& Richiede uno \textit{shared lock}. Più processi possono
                       mantenere un blocco condiviso sullo stesso file.\\
     \const{LOCK\_EX}& Richiede un \textit{exclusive lock}. Un solo processo
-                      alla volta può mantenere un blocco esclusivo su un file.\\
+                      alla volta può mantenere un blocco esclusivo su un file.\\
     \const{LOCK\_UN}& Sblocca il file.\\
-    \const{LOCK\_NB}& Non blocca la funzione quando il blocco non è disponibile,
+    \const{LOCK\_NB}& Non blocca la funzione quando il blocco non è disponibile,
                       si specifica sempre insieme ad una delle altre operazioni
                       con un OR aritmetico dei valori.\\ 
     \hline    
@@ -787,9 +787,9 @@ tab.~\ref{tab:file_lockf_type}.
 \end{table}
 
 Qualora il blocco non possa essere acquisito, a meno di non aver specificato
-\const{LOCK\_NB}, la funzione si blocca fino alla disponibilità dello stesso.
-Dato che la funzione è implementata utilizzando \func{fcntl} la semantica
-delle operazioni è la stessa di quest'ultima (pertanto la funzione non è
+\const{LOCK\_NB}, la funzione si blocca fino alla disponibilità dello stesso.
+Dato che la funzione è implementata utilizzando \func{fcntl} la semantica
+delle operazioni è la stessa di quest'ultima (pertanto la funzione non è
 affatto equivalente a \func{flock}).
 
 
@@ -799,39 +799,39 @@ affatto equivalente a \func{flock}).
 
 \itindbeg{mandatory~locking|(}
 
-Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
+Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
 per introdurre un \textit{file locking} che, come dice il nome, fosse
 effettivo indipendentemente dai controlli eseguiti da un processo. Con il
-\textit{mandatory locking} infatti è possibile far eseguire il blocco del file
-direttamente al sistema, così che, anche qualora non si predisponessero le
+\textit{mandatory locking} infatti è possibile far eseguire il blocco del file
+direttamente al sistema, così che, anche qualora non si predisponessero le
 opportune verifiche nei processi, questo verrebbe comunque rispettato.
 
-Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
+Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
 utilizzo particolare del bit \itindex{sgid~bit} \acr{sgid}. Se si ricorda
 quanto esposto in sez.~\ref{sec:file_special_perm}), esso viene di norma
 utilizzato per cambiare il group-ID effettivo con cui viene eseguito un
-programma, ed è pertanto sempre associato alla presenza del permesso di
+programma, ed è pertanto sempre associato alla presenza del permesso di
 esecuzione per il gruppo. Impostando questo bit su un file senza permesso di
-esecuzione in un sistema che supporta il \textit{mandatory locking}, fa sì che
+esecuzione in un sistema che supporta il \textit{mandatory locking}, fa sì che
 quest'ultimo venga attivato per il file in questione. In questo modo una
 combinazione dei permessi originariamente non contemplata, in quanto senza
 significato, diventa l'indicazione della presenza o meno del \textit{mandatory
   locking}.\footnote{un lettore attento potrebbe ricordare quanto detto in
-  sez.~\ref{sec:file_perm_management} e cioè che il bit \acr{sgid} viene
+  sez.~\ref{sec:file_perm_management} e cioè che il bit \acr{sgid} viene
   cancellato (come misura di sicurezza) quando di scrive su un file, questo
   non vale quando esso viene utilizzato per attivare il \textit{mandatory
     locking}.}
 
 L'uso del \textit{mandatory locking} presenta vari aspetti delicati, dato che
-neanche l'amministratore può passare sopra ad un \textit{file lock}; pertanto
-un processo che blocchi un file cruciale può renderlo completamente
+neanche l'amministratore può passare sopra ad un \textit{file lock}; pertanto
+un processo che blocchi un file cruciale può renderlo completamente
 inaccessibile, rendendo completamente inutilizzabile il sistema\footnote{il
   problema si potrebbe risolvere rimuovendo il bit \itindex{sgid~bit}
-  \acr{sgid}, ma non è detto che sia così facile fare questa operazione con un
-  sistema bloccato.}  inoltre con il \textit{mandatory locking} si può
+  \acr{sgid}, ma non è detto che sia così facile fare questa operazione con un
+  sistema bloccato.}  inoltre con il \textit{mandatory locking} si può
 bloccare completamente un server NFS richiedendo una lettura su un file su cui
-è attivo un blocco. Per questo motivo l'abilitazione del \textit{mandatory
-  locking} è di norma disabilitata, e deve essere attivata filesystem per
+è attivo un blocco. Per questo motivo l'abilitazione del \textit{mandatory
+  locking} è di norma disabilitata, e deve essere attivata filesystem per
 filesystem in fase di montaggio (specificando l'apposita opzione di
 \func{mount} riportata in tab.~\ref{tab:sys_mount_flags}, o con l'opzione
 \code{-o mand} per il comando omonimo).
@@ -839,32 +839,32 @@ filesystem in fase di montaggio (specificando l'apposita opzione di
 Si tenga presente inoltre che il \textit{mandatory locking} funziona solo
 sull'interfaccia POSIX di \func{fcntl}. Questo ha due conseguenze: che non si
 ha nessun effetto sui \textit{file lock} richiesti con l'interfaccia di
-\func{flock}, e che la granularità del blocco è quella del singolo byte, come
+\func{flock}, e che la granularità del blocco è quella del singolo byte, come
 per \func{fcntl}.
 
-La sintassi di acquisizione dei blocchi è esattamente la stessa vista in
-precedenza per \func{fcntl} e \func{lockf}, la differenza è che in caso di
-\textit{mandatory lock} attivato non è più necessario controllare la
-disponibilità di accesso al file, ma si potranno usare direttamente le
-ordinarie funzioni di lettura e scrittura e sarà compito del kernel gestire
+La sintassi di acquisizione dei blocchi è esattamente la stessa vista in
+precedenza per \func{fcntl} e \func{lockf}, la differenza è che in caso di
+\textit{mandatory lock} attivato non è più necessario controllare la
+disponibilità di accesso al file, ma si potranno usare direttamente le
+ordinarie funzioni di lettura e scrittura e sarà compito del kernel gestire
 direttamente il \textit{file locking}.
 
-Questo significa che in caso di \textit{read lock} la lettura dal file potrà
-avvenire normalmente con \func{read}, mentre una \func{write} si bloccherà
+Questo significa che in caso di \textit{read lock} la lettura dal file potrà
+avvenire normalmente con \func{read}, mentre una \func{write} si bloccherà
 fino al rilascio del blocco, a meno di non aver aperto il file con
-\const{O\_NONBLOCK}, nel qual caso essa ritornerà immediatamente con un errore
+\const{O\_NONBLOCK}, nel qual caso essa ritornerà immediatamente con un errore
 di \errcode{EAGAIN}.
 
-Se invece si è acquisito un \textit{write lock} tutti i tentativi di leggere o
+Se invece si è acquisito un \textit{write lock} tutti i tentativi di leggere o
 scrivere sulla regione del file bloccata fermeranno il processo fino al
 rilascio del blocco, a meno che il file non sia stato aperto con
-\const{O\_NONBLOCK}, nel qual caso di nuovo si otterrà un ritorno immediato
+\const{O\_NONBLOCK}, nel qual caso di nuovo si otterrà un ritorno immediato
 con l'errore di \errcode{EAGAIN}.
 
 Infine occorre ricordare che le funzioni di lettura e scrittura non sono le
 sole ad operare sui contenuti di un file, e che sia \func{creat} che
 \func{open} (quando chiamata con \const{O\_TRUNC}) effettuano dei cambiamenti,
-così come \func{truncate}, riducendone le dimensioni (a zero nei primi due
+così come \func{truncate}, riducendone le dimensioni (a zero nei primi due
 casi, a quanto specificato nel secondo). Queste operazioni sono assimilate a
 degli accessi in scrittura e pertanto non potranno essere eseguite (fallendo
 con un errore di \errcode{EAGAIN}) su un file su cui sia presente un qualunque
@@ -872,21 +872,21 @@ blocco (le prime due sempre, la terza solo nel caso che la riduzione delle
 dimensioni del file vada a sovrapporsi ad una regione bloccata).
 
 L'ultimo aspetto della interazione del \textit{mandatory locking} con le
-funzioni di accesso ai file è quello relativo ai file mappati in memoria (che
+funzioni di accesso ai file è quello relativo ai file mappati in memoria (che
 abbiamo trattato in sez.~\ref{sec:file_memory_map}); anche in tal caso
 infatti, quando si esegue la mappatura con l'opzione \const{MAP\_SHARED}, si
 ha un accesso al contenuto del file. Lo standard SVID prevede che sia
 impossibile eseguire il memory mapping di un file su cui sono presenti dei
-blocchi\footnote{alcuni sistemi, come HP-UX, sono ancora più restrittivi e lo
+blocchi\footnote{alcuni sistemi, come HP-UX, sono ancora più restrittivi e lo
   impediscono anche in caso di \textit{advisory locking}, anche se questo
   comportamento non ha molto senso, dato che comunque qualunque accesso
-  diretto al file è consentito.} in Linux è stata però fatta la scelta
+  diretto al file è consentito.} in Linux è stata però fatta la scelta
 implementativa\footnote{per i dettagli si possono leggere le note relative
   all'implementazione, mantenute insieme ai sorgenti del kernel nel file
   \file{Documentation/mandatory.txt}.}  di seguire questo comportamento
 soltanto quando si chiama \func{mmap} con l'opzione \const{MAP\_SHARED} (nel
 qual caso la funzione fallisce con il solito \errcode{EAGAIN}) che comporta la
-possibilità di modificare il file.
+possibilità di modificare il file.
 
 \index{file!locking|)}
 
@@ -899,11 +899,11 @@ possibilit
 
 Uno dei problemi che si presentano quando si deve operare contemporaneamente
 su molti file usando le funzioni illustrate in
-cap.~\ref{cha:file_unix_interface} e cap.~\ref{cha:files_std_interface} è che
-si può essere bloccati nelle operazioni su un file mentre un altro potrebbe
+cap.~\ref{cha:file_unix_interface} e cap.~\ref{cha:files_std_interface} è che
+si può essere bloccati nelle operazioni su un file mentre un altro potrebbe
 essere disponibile. L'\textit{I/O multiplexing} nasce risposta a questo
 problema. In questa sezione forniremo una introduzione a questa problematica
-ed analizzeremo le varie funzioni usate per implementare questa modalità di
+ed analizzeremo le varie funzioni usate per implementare questa modalità di
 I/O.
 
 
@@ -913,48 +913,48 @@ I/O.
 Abbiamo visto in sez.~\ref{sec:sig_gen_beha}, affrontando la suddivisione fra
 \textit{fast} e \textit{slow} system call,\index{system~call~lente} che in
 certi casi le funzioni di I/O possono bloccarsi indefinitamente.\footnote{si
-  ricordi però che questo può accadere solo per le pipe, i socket ed alcuni
+  ricordi però che questo può accadere solo per le pipe, i socket ed alcuni
   file di dispositivo\index{file!di~dispositivo}; sui file normali le funzioni
   di lettura e scrittura ritornano sempre subito.}  Ad esempio le operazioni
 di lettura possono bloccarsi quando non ci sono dati disponibili sul
 descrittore su cui si sta operando.
 
-Questo comportamento causa uno dei problemi più comuni che ci si trova ad
+Questo comportamento causa uno dei problemi più comuni che ci si trova ad
 affrontare nelle operazioni di I/O, che si verifica quando si deve operare con
-più file descriptor eseguendo funzioni che possono bloccarsi senza che sia
-possibile prevedere quando questo può avvenire (il caso più classico è quello
-di un server in attesa di dati in ingresso da vari client). Quello che può
-accadere è di restare bloccati nell'eseguire una operazione su un file
-descriptor che non è ``\textsl{pronto}'', quando ce ne potrebbe essere un
+più file descriptor eseguendo funzioni che possono bloccarsi senza che sia
+possibile prevedere quando questo può avvenire (il caso più classico è quello
+di un server in attesa di dati in ingresso da vari client). Quello che può
+accadere è di restare bloccati nell'eseguire una operazione su un file
+descriptor che non è ``\textsl{pronto}'', quando ce ne potrebbe essere un
 altro disponibile. Questo comporta nel migliore dei casi una operazione
 ritardata inutilmente nell'attesa del completamento di quella bloccata, mentre
 nel peggiore dei casi (quando la conclusione della operazione bloccata dipende
 da quanto si otterrebbe dal file descriptor ``\textsl{disponibile}'') si
 potrebbe addirittura arrivare ad un \itindex{deadlock} \textit{deadlock}.
 
-Abbiamo già accennato in sez.~\ref{sec:file_open} che è possibile prevenire
+Abbiamo già accennato in sez.~\ref{sec:file_open} che è possibile prevenire
 questo tipo di comportamento delle funzioni di I/O aprendo un file in
-\textsl{modalità non-bloccante}, attraverso l'uso del flag \const{O\_NONBLOCK}
+\textsl{modalità non-bloccante}, attraverso l'uso del flag \const{O\_NONBLOCK}
 nella chiamata di \func{open}. In questo caso le funzioni di input/output
 eseguite sul file che si sarebbero bloccate, ritornano immediatamente,
-restituendo l'errore \errcode{EAGAIN}.  L'utilizzo di questa modalità di I/O
+restituendo l'errore \errcode{EAGAIN}.  L'utilizzo di questa modalità di I/O
 permette di risolvere il problema controllando a turno i vari file descriptor,
 in un ciclo in cui si ripete l'accesso fintanto che esso non viene garantito.
-Ovviamente questa tecnica, detta \itindex{polling} \textit{polling}, è
+Ovviamente questa tecnica, detta \itindex{polling} \textit{polling}, è
 estremamente inefficiente: si tiene costantemente impiegata la CPU solo per
 eseguire in continuazione delle system call che nella gran parte dei casi
 falliranno.
 
-Per superare questo problema è stato introdotto il concetto di \textit{I/O
-  multiplexing}, una nuova modalità di operazioni che consente di tenere sotto
-controllo più file descriptor in contemporanea, permettendo di bloccare un
+Per superare questo problema è stato introdotto il concetto di \textit{I/O
+  multiplexing}, una nuova modalità di operazioni che consente di tenere sotto
+controllo più file descriptor in contemporanea, permettendo di bloccare un
 processo quando le operazioni volute non sono possibili, e di riprenderne
 l'esecuzione una volta che almeno una di quelle richieste sia effettuabile, in
 modo da poterla eseguire con la sicurezza di non restare bloccati.
 
-Dato che, come abbiamo già accennato, per i normali file su disco non si ha
-mai un accesso bloccante, l'uso più comune delle funzioni che esamineremo nei
-prossimi paragrafi è per i server di rete, in cui esse vengono utilizzate per
+Dato che, come abbiamo già accennato, per i normali file su disco non si ha
+mai un accesso bloccante, l'uso più comune delle funzioni che esamineremo nei
+prossimi paragrafi è per i server di rete, in cui esse vengono utilizzate per
 tenere sotto controllo dei socket; pertanto ritorneremo su di esse con
 ulteriori dettagli e qualche esempio di utilizzo concreto in
 sez.~\ref{sec:TCP_sock_multiplexing}.
@@ -964,10 +964,10 @@ sez.~\ref{sec:TCP_sock_multiplexing}.
 \label{sec:file_select}
 
 Il primo kernel unix-like ad introdurre una interfaccia per l'\textit{I/O
-  multiplexing} è stato BSD,\footnote{la funzione \func{select} è apparsa in
-  BSD4.2 e standardizzata in BSD4.4, ma è stata portata su tutti i sistemi che
+  multiplexing} è stato BSD,\footnote{la funzione \func{select} è apparsa in
+  BSD4.2 e standardizzata in BSD4.4, ma è stata portata su tutti i sistemi che
   supportano i socket, compreso le varianti di System V.}  con la funzione
-\funcd{select}, il cui prototipo è:
+\funcd{select}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/time.h}
   \headdecl{sys/types.h}
@@ -980,12 +980,12 @@ Il primo kernel unix-like ad introdurre una interfaccia per l'\textit{I/O
   
   \bodydesc{La funzione in caso di successo restituisce il numero di file
     descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual
-    caso \var{errno} assumerà uno dei valori:
+    caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
+  \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
     degli insiemi.
-  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
-  \item[\errcode{EINVAL}] si è specificato per \param{ndfs} un valore negativo
+  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+  \item[\errcode{EINVAL}] si è specificato per \param{ndfs} un valore negativo
     o un valore non valido per \param{timeout}.
   \end{errlist}
   ed inoltre \errval{ENOMEM}.
@@ -1021,109 +1021,109 @@ opportune macro di preprocessore:
   Rimuove il file descriptor \param{fd} dall'insieme.
   
   \funcdecl{int \macro{FD\_ISSET}(int fd, fd\_set *set)}
-  Controlla se il file descriptor \param{fd} è nell'insieme.
+  Controlla se il file descriptor \param{fd} è nell'insieme.
 \end{functions}
 
-In genere un \textit{file descriptor set} può contenere fino ad un massimo di
+In genere un \textit{file descriptor set} può contenere fino ad un massimo di
 \const{FD\_SETSIZE} file descriptor.  Questo valore in origine corrispondeva
 al limite per il numero massimo di file aperti\footnote{ad esempio in Linux,
   fino alla serie 2.0.x, c'era un limite di 256 file per processo.}, ma da
-quando, come nelle versioni più recenti del kernel, questo limite è stato
+quando, come nelle versioni più recenti del kernel, questo limite è stato
 rimosso, esso indica le dimensioni massime dei numeri usati nei \textit{file
   descriptor set}.\footnote{il suo valore, secondo lo standard POSIX
-  1003.1-2001, è definito in \file{sys/select.h}, ed è pari a 1024.} 
+  1003.1-2001, è definito in \file{sys/select.h}, ed è pari a 1024.} 
 
 Si tenga presente che i \textit{file descriptor set} devono sempre essere
 inizializzati con \macro{FD\_ZERO}; passare a \func{select} un valore non
-inizializzato può dar luogo a comportamenti non prevedibili; allo stesso modo
+inizializzato può dar luogo a comportamenti non prevedibili; allo stesso modo
 usare \macro{FD\_SET} o \macro{FD\_CLR} con un file descriptor il cui valore
-eccede \const{FD\_SETSIZE} può dare luogo ad un comportamento indefinito.
+eccede \const{FD\_SETSIZE} può dare luogo ad un comportamento indefinito.
 
 La funzione richiede di specificare tre insiemi distinti di file descriptor;
-il primo, \param{readfds}, verrà osservato per rilevare la disponibilità di
-effettuare una lettura,\footnote{per essere precisi la funzione ritornerà in
+il primo, \param{readfds}, verrà osservato per rilevare la disponibilità di
+effettuare una lettura,\footnote{per essere precisi la funzione ritornerà in
   tutti i casi in cui la successiva esecuzione di \func{read} risulti non
   bloccante, quindi anche in caso di \textit{end-of-file}; inoltre con Linux
   possono verificarsi casi particolari, ad esempio quando arrivano dati su un
-  socket dalla rete che poi risultano corrotti e vengono scartati, può
+  socket dalla rete che poi risultano corrotti e vengono scartati, può
   accadere che \func{select} riporti il relativo file descriptor come
   leggibile, ma una successiva \func{read} si blocchi.} il secondo,
-\param{writefds}, per verificare la possibilità di effettuare una scrittura ed
+\param{writefds}, per verificare la possibilità di effettuare una scrittura ed
 il terzo, \param{exceptfds}, per verificare l'esistenza di eccezioni (come i
 dati urgenti \itindex{out-of-band} su un socket, vedi
 sez.~\ref{sec:TCP_urgent_data}).
 
 Dato che in genere non si tengono mai sotto controllo fino a
 \const{FD\_SETSIZE} file contemporaneamente la funzione richiede di
-specificare qual è il valore più alto fra i file descriptor indicati nei tre
+specificare qual è il valore più alto fra i file descriptor indicati nei tre
 insiemi precedenti. Questo viene fatto per efficienza, per evitare di passare
-e far controllare al kernel una quantità di memoria superiore a quella
+e far controllare al kernel una quantità di memoria superiore a quella
 necessaria. Questo limite viene indicato tramite l'argomento \param{ndfs}, che
 deve corrispondere al valore massimo aumentato di uno.\footnote{si ricordi che
   i file descriptor sono numerati progressivamente a partire da zero, ed il
-  valore indica il numero più alto fra quelli da tenere sotto controllo;
-  dimenticarsi di aumentare di uno il valore di \param{ndfs} è un errore
+  valore indica il numero più alto fra quelli da tenere sotto controllo;
+  dimenticarsi di aumentare di uno il valore di \param{ndfs} è un errore
   comune.}  
 
 Infine l'argomento \param{timeout}, espresso con una struttura di tipo
 \struct{timeval} (vedi fig.~\ref{fig:sys_timeval_struct}) specifica un tempo
 massimo di attesa prima che la funzione ritorni; se impostato a \val{NULL} la
-funzione attende indefinitamente. Si può specificare anche un tempo nullo
-(cioè una struttura \struct{timeval} con i campi impostati a zero), qualora si
+funzione attende indefinitamente. Si può specificare anche un tempo nullo
+(cioè una struttura \struct{timeval} con i campi impostati a zero), qualora si
 voglia semplicemente controllare lo stato corrente dei file descriptor.
 
-La funzione restituisce il numero di file descriptor pronti,\footnote{questo è
+La funzione restituisce il numero di file descriptor pronti,\footnote{questo è
   il comportamento previsto dallo standard, ma la standardizzazione della
-  funzione è recente, ed esistono ancora alcune versioni di Unix che non si
+  funzione è recente, ed esistono ancora alcune versioni di Unix che non si
   comportano in questo modo.}  e ciascun insieme viene sovrascritto per
 indicare quali sono i file descriptor pronti per le operazioni ad esso
 relative, in modo da poterli controllare con \macro{FD\_ISSET}.  Se invece si
 ha un timeout viene restituito un valore nullo e gli insiemi non vengono
 modificati.  In caso di errore la funzione restituisce -1, ed i valori dei tre
-insiemi sono indefiniti e non si può fare nessun affidamento sul loro
+insiemi sono indefiniti e non si può fare nessun affidamento sul loro
 contenuto.
 
 \itindend{file~descriptor~set}
 
-Una volta ritornata la funzione si potrà controllare quali sono i file
-descriptor pronti ed operare su di essi, si tenga presente però che si tratta
+Una volta ritornata la funzione si potrà controllare quali sono i file
+descriptor pronti ed operare su di essi, si tenga presente però che si tratta
 solo di un suggerimento, esistono infatti condizioni\footnote{ad esempio
-  quando su un socket arrivano dei dati che poi vengono scartati perché
-  corrotti.} in cui \func{select} può riportare in maniera spuria che un file
-descriptor è pronto in lettura, quando una successiva lettura si bloccherebbe.
-Per questo quando si usa \textit{I/O multiplexing} è sempre raccomandato l'uso
-delle funzioni di lettura e scrittura in modalità non bloccante.
+  quando su un socket arrivano dei dati che poi vengono scartati perché
+  corrotti.} in cui \func{select} può riportare in maniera spuria che un file
+descriptor è pronto in lettura, quando una successiva lettura si bloccherebbe.
+Per questo quando si usa \textit{I/O multiplexing} è sempre raccomandato l'uso
+delle funzioni di lettura e scrittura in modalità non bloccante.
 
 In Linux \func{select} modifica anche il valore di \param{timeout},
 impostandolo al tempo restante, quando la funzione viene interrotta da un
 segnale. In tal caso infatti si ha un errore di \errcode{EINTR}, ed occorre
-rilanciare la funzione; in questo modo non è necessario ricalcolare tutte le
-volte il tempo rimanente. Questo può causare problemi di portabilità sia
+rilanciare la funzione; in questo modo non è necessario ricalcolare tutte le
+volte il tempo rimanente. Questo può causare problemi di portabilità sia
 quando si usa codice scritto su Linux che legge questo valore, sia quando si
 usano programmi scritti per altri sistemi che non dispongono di questa
 caratteristica e ricalcolano \param{timeout} tutte le volte.\footnote{in
-  genere questa caratteristica è disponibile nei sistemi che derivano da
-  System V e non è disponibile per quelli che derivano da BSD; lo standard
+  genere questa caratteristica è disponibile nei sistemi che derivano da
+  System V e non è disponibile per quelli che derivano da BSD; lo standard
   POSIX.1-2001 non permette questo comportamento.}
 
-Uno dei problemi che si presentano con l'uso di \func{select} è che il suo
+Uno dei problemi che si presentano con l'uso di \func{select} è che il suo
 comportamento dipende dal valore del file descriptor che si vuole tenere sotto
 controllo.  Infatti il kernel riceve con \param{ndfs} un limite massimo per
 tale valore, e per capire quali sono i file descriptor da tenere sotto
-controllo dovrà effettuare una scansione su tutto l'intervallo, che può anche
-essere molto ampio anche se i file descriptor sono solo poche unità; tutto ciò
+controllo dovrà effettuare una scansione su tutto l'intervallo, che può anche
+essere molto ampio anche se i file descriptor sono solo poche unità; tutto ciò
 ha ovviamente delle conseguenze ampiamente negative per le prestazioni.
 
-Inoltre c'è anche il problema che il numero massimo dei file che si possono
-tenere sotto controllo, la funzione è nata quando il kernel consentiva un
-numero massimo di 1024 file descriptor per processo, adesso che il numero può
+Inoltre c'è anche il problema che il numero massimo dei file che si possono
+tenere sotto controllo, la funzione è nata quando il kernel consentiva un
+numero massimo di 1024 file descriptor per processo, adesso che il numero può
 essere arbitrario si viene a creare una dipendenza del tutto artificiale dalle
-dimensioni della struttura \type{fd\_set}, che può necessitare di essere
+dimensioni della struttura \type{fd\_set}, che può necessitare di essere
 estesa, con ulteriori perdite di prestazioni. 
 
-Lo standard POSIX è rimasto a lungo senza primitive per l'\textit{I/O
+Lo standard POSIX è rimasto a lungo senza primitive per l'\textit{I/O
   multiplexing}, introdotto solo con le ultime revisioni dello standard (POSIX
-1003.1g-2000 e POSIX 1003.1-2001). La scelta è stata quella di seguire
+1003.1g-2000 e POSIX 1003.1-2001). La scelta è stata quella di seguire
 l'interfaccia creata da BSD, ma prevede che tutte le funzioni ad esso relative
 vengano dichiarate nell'header \file{sys/select.h}, che sostituisce i
 precedenti, ed inoltre aggiunge a \func{select} una nuova funzione
@@ -1131,10 +1131,10 @@ precedenti, ed inoltre aggiunge a \func{select} una nuova funzione
   l'header \file{sys/select.h}, compaiono in Linux a partire dalle \acr{glibc}
   2.1. Le \acr{libc4} e \acr{libc5} non contengono questo header, le
   \acr{glibc} 2.0 contengono una definizione sbagliata di \func{psignal},
-  senza l'argomento \param{sigmask}, la definizione corretta è presente dalle
-  \acr{glibc} 2.1-2.2.1 se si è definito \macro{\_GNU\_SOURCE} e nelle
-  \acr{glibc} 2.2.2-2.2.4 se si è definito \macro{\_XOPEN\_SOURCE} con valore
-  maggiore di 600.} il cui prototipo è:
+  senza l'argomento \param{sigmask}, la definizione corretta è presente dalle
+  \acr{glibc} 2.1-2.2.1 se si è definito \macro{\_GNU\_SOURCE} e nelle
+  \acr{glibc} 2.2.2-2.2.4 se si è definito \macro{\_XOPEN\_SOURCE} con valore
+  maggiore di 600.} il cui prototipo è:
 \begin{prototype}{sys/select.h}
   {int pselect(int n, fd\_set *readfds, fd\_set *writefds, fd\_set *exceptfds,
     struct timespec *timeout, sigset\_t *sigmask)}
@@ -1144,33 +1144,33 @@ precedenti, ed inoltre aggiunge a \func{select} una nuova funzione
   
   \bodydesc{La funzione in caso di successo restituisce il numero di file
     descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual
-    caso \var{errno} assumerà uno dei valori:
+    caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
+  \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
     degli insiemi.
-  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
-  \item[\errcode{EINVAL}] si è specificato per \param{ndfs} un valore negativo
+  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+  \item[\errcode{EINVAL}] si è specificato per \param{ndfs} un valore negativo
     o un valore non valido per \param{timeout}.
   \end{errlist}
   ed inoltre \errval{ENOMEM}.}
 \end{prototype}
 
-La funzione è sostanzialmente identica a \func{select}, solo che usa una
+La funzione è sostanzialmente identica a \func{select}, solo che usa una
 struttura \struct{timespec} (vedi fig.~\ref{fig:sys_timespec_struct}) per
 indicare con maggiore precisione il timeout e non ne aggiorna il valore in
-caso di interruzione.\footnote{in realtà la system call di Linux aggiorna il
+caso di interruzione.\footnote{in realtà la system call di Linux aggiorna il
   valore al tempo rimanente, ma la funzione fornita dalle \acr{glibc} modifica
   questo comportamento passando alla system call una variabile locale, in modo
   da mantenere l'aderenza allo standard POSIX che richiede che il valore di
   \param{timeout} non sia modificato.} Inoltre prende un argomento aggiuntivo
-\param{sigmask} che è il puntatore ad una maschera di segnali (si veda
+\param{sigmask} che è il puntatore ad una maschera di segnali (si veda
 sez.~\ref{sec:sig_sigmask}).  La maschera corrente viene sostituita da questa
 immediatamente prima di eseguire l'attesa, e ripristinata al ritorno della
 funzione.
 
-L'uso di \param{sigmask} è stato introdotto allo scopo di prevenire possibili
+L'uso di \param{sigmask} è stato introdotto allo scopo di prevenire possibili
 \textit{race condition} \itindex{race~condition} quando ci si deve porre in
-attesa sia di un segnale che di dati. La tecnica classica è quella di
+attesa sia di un segnale che di dati. La tecnica classica è quella di
 utilizzare il gestore per impostare una variabile globale e controllare questa
 nel corpo principale del programma; abbiamo visto in
 sez.~\ref{sec:sig_example} come questo lasci spazio a possibili race
@@ -1181,32 +1181,32 @@ l'arrivo di un segnale immediatamente dopo il controllo, che andrebbe perso.
 
 Nel nostro caso il problema si pone quando oltre al segnale si devono tenere
 sotto controllo anche dei file descriptor con \func{select}, in questo caso si
-può fare conto sul fatto che all'arrivo di un segnale essa verrebbe interrotta
+può fare conto sul fatto che all'arrivo di un segnale essa verrebbe interrotta
 e si potrebbero eseguire di conseguenza le operazioni relative al segnale e
 alla gestione dati con un ciclo del tipo:
 \includecodesnip{listati/select_race.c} 
-qui però emerge una \itindex{race~condition} \textit{race condition}, perché
-se il segnale arriva prima della chiamata a \func{select}, questa non verrà
-interrotta, e la ricezione del segnale non sarà rilevata.
+qui però emerge una \itindex{race~condition} \textit{race condition}, perché
+se il segnale arriva prima della chiamata a \func{select}, questa non verrà
+interrotta, e la ricezione del segnale non sarà rilevata.
 
-Per questo è stata introdotta \func{pselect} che attraverso l'argomento
+Per questo è stata introdotta \func{pselect} che attraverso l'argomento
 \param{sigmask} permette di riabilitare la ricezione il segnale
-contestualmente all'esecuzione della funzione,\footnote{in Linux però, fino al
+contestualmente all'esecuzione della funzione,\footnote{in Linux però, fino al
   kernel 2.6.16, non era presente la relativa system call, e la funzione era
   implementata nelle \acr{glibc} attraverso \func{select} (vedi \texttt{man
-    select\_tut}) per cui la possibilità di \itindex{race~condition}
-  \textit{race condition} permaneva; in tale situazione si può ricorrere ad una
+    select\_tut}) per cui la possibilità di \itindex{race~condition}
+  \textit{race condition} permaneva; in tale situazione si può ricorrere ad una
   soluzione alternativa, chiamata \itindex{self-pipe trick} \textit{self-pipe
     trick}, che consiste nell'aprire una pipe (vedi sez.~\ref{sec:ipc_pipes})
-  ed usare \func{select} sul capo in lettura della stessa; si può indicare
+  ed usare \func{select} sul capo in lettura della stessa; si può indicare
   l'arrivo di un segnale scrivendo sul capo in scrittura all'interno del
   gestore dello stesso; in questo modo anche se il segnale va perso prima
-  della chiamata di \func{select} questa lo riconoscerà comunque dalla
-  presenza di dati sulla pipe.} ribloccandolo non appena essa ritorna, così
+  della chiamata di \func{select} questa lo riconoscerà comunque dalla
+  presenza di dati sulla pipe.} ribloccandolo non appena essa ritorna, così
 che il precedente codice potrebbe essere riscritto nel seguente modo:
 \includecodesnip{listati/pselect_norace.c} 
 in questo caso utilizzando \var{oldmask} durante l'esecuzione di
-\func{pselect} la ricezione del segnale sarà abilitata, ed in caso di
+\func{pselect} la ricezione del segnale sarà abilitata, ed in caso di
 interruzione si potranno eseguire le relative operazioni.
 
 
@@ -1214,24 +1214,24 @@ interruzione si potranno eseguire le relative operazioni.
 \label{sec:file_poll}
 
 Nello sviluppo di System V, invece di utilizzare l'interfaccia di
-\func{select}, che è una estensione tipica di BSD, è stata introdotta un'altra
-interfaccia, basata sulla funzione \funcd{poll},\footnote{la funzione è
-  prevista dallo standard XPG4, ed è stata introdotta in Linux come system
+\func{select}, che è una estensione tipica di BSD, è stata introdotta un'altra
+interfaccia, basata sulla funzione \funcd{poll},\footnote{la funzione è
+  prevista dallo standard XPG4, ed è stata introdotta in Linux come system
   call a partire dal kernel 2.1.23 ed inserita nelle \acr{libc} 5.4.28.} il
-cui prototipo è:
+cui prototipo è:
 \begin{prototype}{sys/poll.h}
   {int poll(struct pollfd *ufds, unsigned int nfds, int timeout)}
   
   La funzione attende un cambiamento di stato su un insieme di file
   descriptor.
   
-  \bodydesc{La funzione restituisce il numero di file descriptor con attività
-    in caso di successo, o 0 se c'è stato un timeout e -1 in caso di errore,
-    ed in quest'ultimo caso \var{errno} assumerà uno dei valori:
+  \bodydesc{La funzione restituisce il numero di file descriptor con attività
+    in caso di successo, o 0 se c'è stato un timeout e -1 in caso di errore,
+    ed in quest'ultimo caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
+  \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
     degli insiemi.
-  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
   \item[\errcode{EINVAL}] il valore di \param{nfds} eccede il limite
     \macro{RLIMIT\_NOFILE}.
   \end{errlist}
@@ -1240,24 +1240,24 @@ cui prototipo 
 
 La funzione permette di tenere sotto controllo contemporaneamente \param{ndfs}
 file descriptor, specificati attraverso il puntatore \param{ufds} ad un
-vettore di strutture \struct{pollfd}.  Come con \func{select} si può
+vettore di strutture \struct{pollfd}.  Come con \func{select} si può
 interrompere l'attesa dopo un certo tempo, questo deve essere specificato con
 l'argomento \param{timeout} in numero di millisecondi: un valore negativo
 indica un'attesa indefinita, mentre un valore nullo comporta il ritorno
-immediato (e può essere utilizzato per impiegare \func{poll} in modalità
+immediato (e può essere utilizzato per impiegare \func{poll} in modalità
 \textsl{non-bloccante}).
 
 Per ciascun file da controllare deve essere inizializzata una struttura
 \struct{pollfd} nel vettore indicato dall'argomento \param{ufds}.  La
-struttura, la cui definizione è riportata in fig.~\ref{fig:file_pollfd},
+struttura, la cui definizione è riportata in fig.~\ref{fig:file_pollfd},
 prevede tre campi: in \var{fd} deve essere indicato il numero del file
 descriptor da controllare, in \var{events} deve essere specificata una
 maschera binaria di flag che indichino il tipo di evento che si vuole
-controllare, mentre in \var{revents} il kernel restituirà il relativo
+controllare, mentre in \var{revents} il kernel restituirà il relativo
 risultato.  Usando un valore negativo per \param{fd} la corrispondente
-struttura sarà ignorata da \func{poll}. Dato che i dati in ingresso sono del
+struttura sarà ignorata da \func{poll}. Dato che i dati in ingresso sono del
 tutto indipendenti da quelli in uscita (che vengono restituiti in
-\var{revents}) non è necessario reinizializzare tutte le volte il valore delle
+\var{revents}) non è necessario reinizializzare tutte le volte il valore delle
 strutture \struct{pollfd} a meno di non voler cambiare qualche condizione.
 
 \begin{figure}[!htb]
@@ -1267,7 +1267,7 @@ strutture \struct{pollfd} a meno di non voler cambiare qualche condizione.
   \end{minipage} 
   \normalsize 
   \caption{La struttura \structd{pollfd}, utilizzata per specificare le
-    modalità di controllo di un file descriptor alla funzione \func{poll}.}
+    modalità di controllo di un file descriptor alla funzione \func{poll}.}
   \label{fig:file_pollfd}
 \end{figure}
 
@@ -1275,7 +1275,7 @@ Le costanti che definiscono i valori relativi ai bit usati nelle maschere
 binarie dei campi \var{events} e \var{revents} sono riportati in
 tab.~\ref{tab:file_pollfd_flags}, insieme al loro significato. Le si sono
 suddivise in tre gruppi, nel primo gruppo si sono indicati i bit utilizzati
-per controllare l'attività in ingresso, nel secondo quelli per l'attività in
+per controllare l'attività in ingresso, nel secondo quelli per l'attività in
 uscita, mentre il terzo gruppo contiene dei valori che vengono utilizzati solo
 nel campo \var{revents} per notificare delle condizioni di errore. 
 
@@ -1287,23 +1287,23 @@ nel campo \var{revents} per notificare delle condizioni di errore.
     \textbf{Flag}  & \textbf{Significato} \\
     \hline
     \hline
-    \const{POLLIN}    & È possibile la lettura.\\
+    \const{POLLIN}    & È possibile la lettura.\\
     \const{POLLRDNORM}& Sono disponibili in lettura dati normali.\\ 
     \const{POLLRDBAND}& Sono disponibili in lettura dati prioritari.\\
-    \const{POLLPRI}   & È possibile la lettura di \itindex{out-of-band} dati
+    \const{POLLPRI}   & È possibile la lettura di \itindex{out-of-band} dati
                         urgenti.\\ 
     \hline
-    \const{POLLOUT}   & È possibile la scrittura immediata.\\
-    \const{POLLWRNORM}& È possibile la scrittura di dati normali.\\ 
-    \const{POLLWRBAND}& È possibile la scrittura di dati prioritari.\\
+    \const{POLLOUT}   & È possibile la scrittura immediata.\\
+    \const{POLLWRNORM}& È possibile la scrittura di dati normali.\\ 
+    \const{POLLWRBAND}& È possibile la scrittura di dati prioritari.\\
     \hline
-    \const{POLLERR}   & C'è una condizione di errore.\\
-    \const{POLLHUP}   & Si è verificato un hung-up.\\
-    \const{POLLRDHUP} & Si è avuta una \textsl{half-close} su un
+    \const{POLLERR}   & C'è una condizione di errore.\\
+    \const{POLLHUP}   & Si è verificato un hung-up.\\
+    \const{POLLRDHUP} & Si è avuta una \textsl{half-close} su un
                         socket.\footnotemark\\ 
-    \const{POLLNVAL}  & Il file descriptor non è aperto.\\
+    \const{POLLNVAL}  & Il file descriptor non è aperto.\\
     \hline
-    \const{POLLMSG}   & Definito per compatibilità con SysV.\\
+    \const{POLLMSG}   & Definito per compatibilità con SysV.\\
     \hline    
   \end{tabular}
   \caption{Costanti per l'identificazione dei vari bit dei campi
@@ -1318,11 +1318,11 @@ nel campo \var{revents} per notificare delle condizioni di errore.
   \textit{half-close} (\textsl{mezza chiusura}) su cui torneremo con maggiori
   dettagli in sez.~\ref{sec:TCP_shutdown}.}
 
-Il valore \const{POLLMSG} non viene utilizzato ed è definito solo per
-compatibilità con l'implementazione di SysV che usa gli
+Il valore \const{POLLMSG} non viene utilizzato ed è definito solo per
+compatibilità con l'implementazione di SysV che usa gli
 \textit{stream};\footnote{essi sono una interfaccia specifica di SysV non
   presente in Linux, e non hanno nulla a che fare con i file \textit{stream}
-  delle librerie standard del C.} è da questi che derivano i nomi di alcune
+  delle librerie standard del C.} è da questi che derivano i nomi di alcune
 costanti, in quanto per essi sono definite tre classi di dati:
 \textsl{normali}, \textit{prioritari} ed \textit{urgenti}.  In Linux la
 distinzione ha senso solo per i dati urgenti \itindex{out-of-band} dei socket
@@ -1336,14 +1336,14 @@ normali e prioritari, vale a dire \const{POLLRDNORM}, \const{POLLWRNORM},
 in stile SysV (in particolare le ultime due non vengono usate su Linux), e
 sono utilizzabili soltanto qualora si sia definita la macro
 \macro{\_XOPEN\_SOURCE}.\footnote{e ci si ricordi di farlo sempre in testa al
-  file, definirla soltanto prima di includere \file{sys/poll.h} non è
+  file, definirla soltanto prima di includere \file{sys/poll.h} non è
   sufficiente.}
 
 In caso di successo funzione ritorna restituendo il numero di file (un valore
-positivo) per i quali si è verificata una delle condizioni di attesa richieste
-o per i quali si è verificato un errore, nel qual caso vengono utilizzati i
+positivo) per i quali si è verificata una delle condizioni di attesa richieste
+o per i quali si è verificato un errore, nel qual caso vengono utilizzati i
 valori di tab.~\ref{tab:file_pollfd_flags} esclusivi di \var{revents}. Un
-valore nullo indica che si è raggiunto il timeout, mentre un valore negativo
+valore nullo indica che si è raggiunto il timeout, mentre un valore negativo
 indica un errore nella chiamata, il cui codice viene riportato al solito
 tramite \var{errno}.
 
@@ -1354,29 +1354,29 @@ limite introdotto dalle dimensioni massime di un \itindex{file~descriptor~set}
 \textit{file descriptor set} e la dimensione dei dati passati al kernel
 dipende solo dal numero dei file descriptor che si vogliono controllare, non
 dal loro valore.\footnote{anche se usando dei bit un \textit{file descriptor
-    set} può essere più efficiente di un vettore di strutture \struct{pollfd},
+    set} può essere più efficiente di un vettore di strutture \struct{pollfd},
   qualora si debba osservare un solo file descriptor con un valore molto alto
-  ci si troverà ad utilizzare inutilmente un maggiore quantitativo di
+  ci si troverà ad utilizzare inutilmente un maggiore quantitativo di
   memoria.}
 
 Inoltre con \func{select} lo stesso \itindex{file~descriptor~set} \textit{file
-  descriptor set} è usato sia in ingresso che in uscita, e questo significa
+  descriptor set} è usato sia in ingresso che in uscita, e questo significa
 che tutte le volte che si vuole ripetere l'operazione occorre reinizializzarlo
-da capo. Questa operazione, che può essere molto onerosa se i file descriptor
-da tenere sotto osservazione sono molti, non è invece necessaria con
+da capo. Questa operazione, che può essere molto onerosa se i file descriptor
+da tenere sotto osservazione sono molti, non è invece necessaria con
 \func{poll}.
 
 Abbiamo visto in sez.~\ref{sec:file_select} come lo standard POSIX preveda una
 variante di \func{select} che consente di gestire correttamente la ricezione
 dei segnali nell'attesa su un file descriptor.  Con l'introduzione di una
-implementazione reale di \func{pselect} nel kernel 2.6.16, è stata aggiunta
+implementazione reale di \func{pselect} nel kernel 2.6.16, è stata aggiunta
 anche una analoga funzione che svolga lo stesso ruolo per \func{poll}.
 
-In questo caso si tratta di una estensione che è specifica di Linux e non è
-prevista da nessuno standard; essa può essere utilizzata esclusivamente se si
+In questo caso si tratta di una estensione che è specifica di Linux e non è
+prevista da nessuno standard; essa può essere utilizzata esclusivamente se si
 definisce la macro \macro{\_GNU\_SOURCE} ed ovviamente non deve essere usata
-se si ha a cuore la portabilità. La funzione è \funcd{ppoll}, ed il suo
-prototipo è:
+se si ha a cuore la portabilità. La funzione è \funcd{ppoll}, ed il suo
+prototipo è:
 \begin{prototype}{sys/poll.h}
   {int ppoll(struct pollfd *fds, nfds\_t nfds, const struct timespec *timeout,
     const sigset\_t *sigmask)}
@@ -1384,24 +1384,24 @@ prototipo 
   La funzione attende un cambiamento di stato su un insieme di file
   descriptor.
   
-  \bodydesc{La funzione restituisce il numero di file descriptor con attività
-    in caso di successo, o 0 se c'è stato un timeout e -1 in caso di errore,
-    ed in quest'ultimo caso \var{errno} assumerà uno dei valori:
+  \bodydesc{La funzione restituisce il numero di file descriptor con attività
+    in caso di successo, o 0 se c'è stato un timeout e -1 in caso di errore,
+    ed in quest'ultimo caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
+  \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
     degli insiemi.
-  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
   \item[\errcode{EINVAL}] il valore di \param{nfds} eccede il limite
     \macro{RLIMIT\_NOFILE}.
   \end{errlist}
   ed inoltre \errval{EFAULT} e \errval{ENOMEM}.}
 \end{prototype}
 
-La funzione ha lo stesso comportamento di \func{poll}, solo che si può
+La funzione ha lo stesso comportamento di \func{poll}, solo che si può
 specificare, con l'argomento \param{sigmask}, il puntatore ad una maschera di
-segnali; questa sarà la maschera utilizzata per tutto il tempo che la funzione
-resterà in attesa, all'uscita viene ripristinata la maschera originale.  L'uso
-di questa funzione è cioè equivalente, come illustrato nella pagina di
+segnali; questa sarà la maschera utilizzata per tutto il tempo che la funzione
+resterà in attesa, all'uscita viene ripristinata la maschera originale.  L'uso
+di questa funzione è cioè equivalente, come illustrato nella pagina di
 manuale, all'esecuzione atomica del seguente codice:
 \includecodesnip{listati/ppoll_means.c} 
 
@@ -1423,21 +1423,21 @@ comportamento non modificando mai il valore di \param{timeout}.\footnote{anche
 \itindbeg{epoll}
 
 Nonostante \func{poll} presenti alcuni vantaggi rispetto a \func{select},
-anche questa funzione non è molto efficiente quando deve essere utilizzata con
+anche questa funzione non è molto efficiente quando deve essere utilizzata con
 un gran numero di file descriptor,\footnote{in casi del genere \func{select}
-  viene scartata a priori, perché può avvenire che il numero di file
+  viene scartata a priori, perché può avvenire che il numero di file
   descriptor ecceda le dimensioni massime di un \itindex{file~descriptor~set}
   \textit{file descriptor set}.} in particolare nel caso in cui solo pochi di
-questi diventano attivi. Il problema in questo caso è che il tempo impiegato
-da \func{poll} a trasferire i dati da e verso il kernel è proporzionale al
-numero di file descriptor osservati, non a quelli che presentano attività.
+questi diventano attivi. Il problema in questo caso è che il tempo impiegato
+da \func{poll} a trasferire i dati da e verso il kernel è proporzionale al
+numero di file descriptor osservati, non a quelli che presentano attività.
 
 Quando ci sono decine di migliaia di file descriptor osservati e migliaia di
-eventi al secondo,\footnote{il caso classico è quello di un server web di un
-  sito con molti accessi.} l'uso di \func{poll} comporta la necessità di
+eventi al secondo,\footnote{il caso classico è quello di un server web di un
+  sito con molti accessi.} l'uso di \func{poll} comporta la necessità di
 trasferire avanti ed indietro da user space a kernel space la lunga lista
 delle strutture \struct{pollfd} migliaia di volte al secondo. A questo poi si
-aggiunge il fatto che la maggior parte del tempo di esecuzione sarà impegnato
+aggiunge il fatto che la maggior parte del tempo di esecuzione sarà impegnato
 ad eseguire una scansione su tutti i file descriptor tenuti sotto controllo
 per determinare quali di essi (in genere una piccola percentuale) sono
 diventati attivi. In una situazione come questa l'uso delle funzioni classiche
@@ -1446,59 +1446,59 @@ bottiglia che degrada irrimediabilmente le prestazioni.
 
 Per risolvere questo tipo di situazioni sono state ideate delle interfacce
 specialistiche\footnote{come \texttt{/dev/poll} in Solaris, o \texttt{kqueue}
-  in BSD.} il cui scopo fondamentale è quello di restituire solamente le
+  in BSD.} il cui scopo fondamentale è quello di restituire solamente le
 informazioni relative ai file descriptor osservati che presentano una
-attività, evitando così le problematiche appena illustrate. In genere queste
+attività, evitando così le problematiche appena illustrate. In genere queste
 prevedono che si registrino una sola volta i file descriptor da tenere sotto
 osservazione, e forniscono un meccanismo che notifica quali di questi
-presentano attività.
+presentano attività.
 
-Le modalità con cui avviene la notifica sono due, la prima è quella classica
+Le modalità con cui avviene la notifica sono due, la prima è quella classica
 (quella usata da \func{poll} e \func{select}) che viene chiamata \textit{level
-  triggered}.\footnote{la nomenclatura è stata introdotta da Jonathan Lemon in
+  triggered}.\footnote{la nomenclatura è stata introdotta da Jonathan Lemon in
   un articolo su \texttt{kqueue} al BSDCON 2000, e deriva da quella usata
-  nell'elettronica digitale.} In questa modalità vengono notificati i file
+  nell'elettronica digitale.} In questa modalità vengono notificati i file
 descriptor che sono \textsl{pronti} per l'operazione richiesta, e questo
 avviene indipendentemente dalle operazioni che possono essere state fatte su
 di essi a partire dalla precedente notifica.  Per chiarire meglio il concetto
 ricorriamo ad un esempio: se su un file descriptor sono diventati disponibili
-in lettura 2000 byte ma dopo la notifica ne sono letti solo 1000 (ed è quindi
-possibile eseguire una ulteriore lettura dei restanti 1000), in modalità
-\textit{level triggered} questo sarà nuovamente notificato come
+in lettura 2000 byte ma dopo la notifica ne sono letti solo 1000 (ed è quindi
+possibile eseguire una ulteriore lettura dei restanti 1000), in modalità
+\textit{level triggered} questo sarà nuovamente notificato come
 \textsl{pronto}.
 
-La seconda modalità, è detta \textit{edge triggered}, e prevede che invece
+La seconda modalità, è detta \textit{edge triggered}, e prevede che invece
 vengano notificati solo i file descriptor che hanno subito una transizione da
-\textsl{non pronti} a \textsl{pronti}. Questo significa che in modalità
+\textsl{non pronti} a \textsl{pronti}. Questo significa che in modalità
 \textit{edge triggered} nel caso del precedente esempio il file descriptor
-diventato pronto da cui si sono letti solo 1000 byte non verrà nuovamente
+diventato pronto da cui si sono letti solo 1000 byte non verrà nuovamente
 notificato come pronto, nonostante siano ancora disponibili in lettura 1000
 byte. Solo una volta che si saranno esauriti tutti i dati disponibili, e che
-il file descriptor sia tornato non essere pronto, si potrà ricevere una
+il file descriptor sia tornato non essere pronto, si potrà ricevere una
 ulteriore notifica qualora ritornasse pronto.
 
 Nel caso di Linux al momento la sola interfaccia che fornisce questo tipo di
-servizio è \textit{epoll},\footnote{l'interfaccia è stata creata da Davide
-  Libenzi, ed è stata introdotta per la prima volta nel kernel 2.5.44, ma la
-  sua forma definitiva è stata raggiunta nel kernel 2.5.66.} anche se sono in
+servizio è \textit{epoll},\footnote{l'interfaccia è stata creata da Davide
+  Libenzi, ed è stata introdotta per la prima volta nel kernel 2.5.44, ma la
+  sua forma definitiva è stata raggiunta nel kernel 2.5.66.} anche se sono in
 discussione altre interfacce con le quali si potranno effettuare lo stesso
 tipo di operazioni;\footnote{al momento della stesura di queste note (Giugno
-  2007) un'altra interfaccia proposta è quella di \textit{kevent}, che
+  2007) un'altra interfaccia proposta è quella di \textit{kevent}, che
   fornisce un sistema di notifica di eventi generico in grado di fornire le
-  stesse funzionalità di \textit{epoll}, esiste però una forte discussione
-  intorno a tutto ciò e niente di definito.}  \textit{epoll} è in grado di
-operare sia in modalità \textit{level triggered} che \textit{edge triggered}.
+  stesse funzionalità di \textit{epoll}, esiste però una forte discussione
+  intorno a tutto ciò e niente di definito.}  \textit{epoll} è in grado di
+operare sia in modalità \textit{level triggered} che \textit{edge triggered}.
 
 La prima versione \textit{epoll} prevedeva l'apertura di uno speciale file di
 dispositivo, \texttt{/dev/epoll}, per ottenere un file descriptor da
 utilizzare con le funzioni dell'interfaccia,\footnote{il backporting
   dell'interfaccia per il kernel 2.4, non ufficiale, utilizza sempre questo
-  file.} ma poi si è passati all'uso di apposite \textit{system call}.  Il
-primo passo per usare l'interfaccia di \textit{epoll} è pertanto quello
+  file.} ma poi si è passati all'uso di apposite \textit{system call}.  Il
+primo passo per usare l'interfaccia di \textit{epoll} è pertanto quello
 ottenere detto file descriptor chiamando una delle funzioni
 \funcd{epoll\_create} e \funcd{epoll\_create1},\footnote{l'interfaccia di
-  \textit{epoll} è stata inserita nel kernel a partire dalla versione 2.5.44,
-  ed il supporto è stato aggiunto alle \acr{glibc} 2.3.2.} i cui prototipi
+  \textit{epoll} è stata inserita nel kernel a partire dalla versione 2.5.44,
+  ed il supporto è stato aggiunto alle \acr{glibc} 2.3.2.} i cui prototipi
 sono:
 \begin{functions}
   \headdecl{sys/epoll.h}
@@ -1510,24 +1510,24 @@ sono:
   
   \bodydesc{Le funzioni restituiscono un file descriptor per \textit{epoll} in
     caso di successo, o $-1$ in caso di errore, nel qual caso \var{errno}
-    assumerà uno dei valori:
+    assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] si è specificato un valore di \param{size} non
+  \item[\errcode{EINVAL}] si è specificato un valore di \param{size} non
     positivo o non valido per \param{flags}.
-  \item[\errcode{ENFILE}] si è raggiunto il massimo di file descriptor aperti
+  \item[\errcode{ENFILE}] si è raggiunto il massimo di file descriptor aperti
     nel sistema.
-  \item[\errcode{EMFILE}] si è raggiunto il limite sul numero massimo di
+  \item[\errcode{EMFILE}] si è raggiunto il limite sul numero massimo di
     istanze di \textit{epoll} per utente stabilito da
     \procfile{/proc/sys/fs/epoll/max\_user\_instances}.
-  \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel per creare
+  \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel per creare
     l'istanza.
   \end{errlist}
 }
 \end{functions}
 
 Entrambe le funzioni restituiscono un file descriptor speciale,\footnote{esso
-  non è associato a nessun file su disco, inoltre a differenza dei normali
-  file descriptor non può essere inviato ad un altro processo attraverso un
+  non è associato a nessun file su disco, inoltre a differenza dei normali
+  file descriptor non può essere inviato ad un altro processo attraverso un
   socket locale (vedi sez.~\ref{sec:sock_fd_passing}).} detto anche
 \textit{epoll descriptor}, che viene associato alla infrastruttura utilizzata
 dal kernel per gestire la notifica degli eventi. Nel caso di
@@ -1535,43 +1535,43 @@ dal kernel per gestire la notifica degli eventi. Nel caso di
 numero di file descriptor che si vorranno tenere sotto controllo, e costituiva
 solo un suggerimento per semplificare l'allocazione di risorse sufficienti,
 non un valore massimo.\footnote{ma a partire dal kernel 2.6.8 esso viene
-  totalmente ignorato e l'allocazione è sempre dinamica.}
+  totalmente ignorato e l'allocazione è sempre dinamica.}
 
-La seconda versione della funzione, \func{epoll\_create1} è stata
-introdotta\footnote{è disponibile solo a partire dal kernel 2.6.27.} come
+La seconda versione della funzione, \func{epoll\_create1} è stata
+introdotta\footnote{è disponibile solo a partire dal kernel 2.6.27.} come
 estensione della precedente, per poter passare dei flag di controllo come
 maschera binaria in fase di creazione del file descriptor. Al momento l'unico
-valore legale per \param{flags} (a parte lo zero) è \const{EPOLL\_CLOEXEC},
+valore legale per \param{flags} (a parte lo zero) è \const{EPOLL\_CLOEXEC},
 che consente di impostare in maniera atomica sul file descriptor il flag di
 \itindex{close-on-exec} \textit{close-on-exec} (si veda il significato di
 \const{O\_CLOEXEC} in tab.~\ref{tab:file_open_flags}), senza che sia
 necessaria una successiva chiamata a \func{fcntl}.
 
-Una volta ottenuto un file descriptor per \textit{epoll} il passo successivo è
+Una volta ottenuto un file descriptor per \textit{epoll} il passo successivo è
 indicare quali file descriptor mettere sotto osservazione e quali operazioni
 controllare, per questo si deve usare la seconda funzione dell'interfaccia,
-\funcd{epoll\_ctl}, il cui prototipo è:
+\funcd{epoll\_ctl}, il cui prototipo è:
 \begin{prototype}{sys/epoll.h}
   {int epoll\_ctl(int epfd, int op, int fd, struct epoll\_event *event)}
   
   Esegue le operazioni di controllo di \textit{epoll}.
   
   \bodydesc{La funzione restituisce $0$ in caso di successo o $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
   \item[\errcode{EBADF}] il file descriptor \param{epfd} o \param{fd} non sono
     validi.
-  \item[\errcode{EEXIST}] l'operazione richiesta è \const{EPOLL\_CTL\_ADD} ma
-    \param{fd} è già stato inserito in \param{epfd}.
-  \item[\errcode{EINVAL}] il file descriptor \param{epfd} non è stato ottenuto
-    con \func{epoll\_create}, o \param{fd} è lo stesso \param{epfd} o
-    l'operazione richiesta con \param{op} non è supportata.
-  \item[\errcode{ENOENT}] l'operazione richiesta è \const{EPOLL\_CTL\_MOD} o
-    \const{EPOLL\_CTL\_DEL} ma \param{fd} non è inserito in \param{epfd}.
-  \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel gestire
+  \item[\errcode{EEXIST}] l'operazione richiesta è \const{EPOLL\_CTL\_ADD} ma
+    \param{fd} è già stato inserito in \param{epfd}.
+  \item[\errcode{EINVAL}] il file descriptor \param{epfd} non è stato ottenuto
+    con \func{epoll\_create}, o \param{fd} è lo stesso \param{epfd} o
+    l'operazione richiesta con \param{op} non è supportata.
+  \item[\errcode{ENOENT}] l'operazione richiesta è \const{EPOLL\_CTL\_MOD} o
+    \const{EPOLL\_CTL\_DEL} ma \param{fd} non è inserito in \param{epfd}.
+  \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel gestire
     l'operazione richiesta.
   \item[\errcode{EPERM}] il file \param{fd} non supporta \textit{epoll}.
-  \item[\errcode{ENOSPC}] si è raggiunto il limite massimo di registrazioni
+  \item[\errcode{ENOSPC}] si è raggiunto il limite massimo di registrazioni
     per utente di file descriptor da osservare imposto da
     \procfile{/proc/sys/fs/epoll/max\_user\_watches}.
   \end{errlist}
@@ -1596,8 +1596,8 @@ delle operazioni cui fanno riferimento.
                              \param{fd} alla lista dei file descriptor
                              controllati tramite \param{epfd}, in
                              \param{event} devono essere specificate le
-                             modalità di osservazione.\\
-    \const{EPOLL\_CTL\_MOD}& Modifica le modalità di osservazione del file
+                             modalità di osservazione.\\
+    \const{EPOLL\_CTL\_MOD}& Modifica le modalità di osservazione del file
                              descriptor \param{fd} secondo il contenuto di
                              \param{event}.\\
     \const{EPOLL\_CTL\_DEL}& Rimuove il file descriptor \param{fd} dalla lista
@@ -1612,7 +1612,7 @@ delle operazioni cui fanno riferimento.
 La funzione prende sempre come primo argomento un file descriptor di
 \textit{epoll}, \param{epfd}, che deve essere stato ottenuto in precedenza con
 una chiamata a \func{epoll\_create}. L'argomento \param{fd} indica invece il
-file descriptor che si vuole tenere sotto controllo, quest'ultimo può essere
+file descriptor che si vuole tenere sotto controllo, quest'ultimo può essere
 un qualunque file descriptor utilizzabile con \func{poll}, ed anche un altro
 file descriptor di \textit{epoll}, ma non lo stesso \param{epfd}.
 
@@ -1623,8 +1623,8 @@ indicare quale tipo di evento relativo ad \param{fd} si vuole che sia tenuto
 sotto controllo.  L'argomento viene ignorato con l'operazione
 \const{EPOLL\_CTL\_DEL}.\footnote{fino al kernel 2.6.9 era comunque richiesto
   che questo fosse un puntatore valido, anche se poi veniva ignorato; a
-  partire dal 2.6.9 si può specificare anche un valore \texttt{NULL} ma se si
-  vuole mantenere la compatibilità con le versioni precedenti occorre usare un
+  partire dal 2.6.9 si può specificare anche un valore \texttt{NULL} ma se si
+  vuole mantenere la compatibilità con le versioni precedenti occorre usare un
   puntatore valido.}
 
 \begin{figure}[!htb]
@@ -1639,20 +1639,20 @@ sotto controllo.  L'argomento viene ignorato con l'operazione
   \label{fig:epoll_event}
 \end{figure}
 
-La struttura \struct{epoll\_event} è l'analoga di \struct{pollfd} e come
+La struttura \struct{epoll\_event} è l'analoga di \struct{pollfd} e come
 quest'ultima serve sia in ingresso (quando usata con \func{epoll\_ctl}) ad
 impostare quali eventi osservare, che in uscita (nei risultati ottenuti con
 \func{epoll\_wait}) per ricevere le notifiche degli eventi avvenuti.  La sua
-definizione è riportata in fig.~\ref{fig:epoll_event}. 
+definizione è riportata in fig.~\ref{fig:epoll_event}. 
 
-Il primo campo, \var{events}, è una maschera binaria in cui ciascun bit
-corrisponde o ad un tipo di evento, o una modalità di notifica; detto campo
+Il primo campo, \var{events}, è una maschera binaria in cui ciascun bit
+corrisponde o ad un tipo di evento, o una modalità di notifica; detto campo
 deve essere specificato come OR aritmetico delle costanti riportate in
-tab.~\ref{tab:epoll_events}. Il secondo campo, \var{data}, è una \ctyp{union}
+tab.~\ref{tab:epoll_events}. Il secondo campo, \var{data}, è una \ctyp{union}
 che serve a identificare il file descriptor a cui si intende fare riferimento,
-ed in astratto può contenere un valore qualsiasi (specificabile in diverse
-forme) che ne permetta una indicazione univoca. Il modo più comune di usarlo
-però è quello in cui si specifica il terzo argomento di \func{epoll\_ctl}
+ed in astratto può contenere un valore qualsiasi (specificabile in diverse
+forme) che ne permetta una indicazione univoca. Il modo più comune di usarlo
+però è quello in cui si specifica il terzo argomento di \func{epoll\_ctl}
 nella forma \var{event.data.fd}, assegnando come valore di questo campo lo
 stesso valore dell'argomento \param{fd}, cosa che permette una immediata
 identificazione del file descriptor.
@@ -1665,9 +1665,9 @@ identificazione del file descriptor.
     \textbf{Valore}  & \textbf{Significato} \\
     \hline
     \hline
-    \const{EPOLLIN}     & Il file è pronto per le operazioni di lettura
+    \const{EPOLLIN}     & Il file è pronto per le operazioni di lettura
                           (analogo di \const{POLLIN}).\\
-    \const{EPOLLOUT}    & Il file è pronto per le operazioni di scrittura
+    \const{EPOLLOUT}    & Il file è pronto per le operazioni di scrittura
                           (analogo di \const{POLLOUT}).\\
     \const{EPOLLRDHUP}  & L'altro capo di un socket di tipo
                           \const{SOCK\_STREAM} (vedi sez.~\ref{sec:sock_type})
@@ -1677,18 +1677,18 @@ identificazione del file descriptor.
     \const{EPOLLPRI}    & Ci sono \itindex{out-of-band} dati urgenti
                           disponibili in lettura (analogo di
                           \const{POLLPRI}); questa condizione viene comunque
-                          riportata in uscita, e non è necessaria impostarla
+                          riportata in uscita, e non è necessaria impostarla
                           in ingresso.\\ 
-    \const{EPOLLERR}    & Si è verificata una condizione di errore 
+    \const{EPOLLERR}    & Si è verificata una condizione di errore 
                           (analogo di \const{POLLERR}); questa condizione
-                          viene comunque riportata in uscita, e non è
+                          viene comunque riportata in uscita, e non è
                           necessaria impostarla in ingresso.\\
-    \const{EPOLLHUP}    & Si è verificata una condizione di hung-up; questa
+    \const{EPOLLHUP}    & Si è verificata una condizione di hung-up; questa
                           condizione viene comunque riportata in uscita, e non
-                          è necessaria impostarla in ingresso.\\
-    \const{EPOLLET}     & Imposta la notifica in modalità \textit{edge
+                          è necessaria impostarla in ingresso.\\
+    \const{EPOLLET}     & Imposta la notifica in modalità \textit{edge
                             triggered} per il file descriptor associato.\\ 
-    \const{EPOLLONESHOT}& Imposta la modalità \textit{one-shot} per il file
+    \const{EPOLLONESHOT}& Imposta la modalità \textit{one-shot} per il file
                           descriptor associato.\footnotemark\\
     \hline    
   \end{tabular}
@@ -1697,61 +1697,61 @@ identificazione del file descriptor.
   \label{tab:epoll_events}
 \end{table}
 
-\footnotetext{questa modalità è disponibile solo a partire dal kernel 2.6.17,
-  ed è utile per riconoscere la chiusura di una connessione dall'altro capo
-  quando si lavora in modalità \textit{edge triggered}.}
+\footnotetext{questa modalità è disponibile solo a partire dal kernel 2.6.17,
+  ed è utile per riconoscere la chiusura di una connessione dall'altro capo
+  quando si lavora in modalità \textit{edge triggered}.}
 
-\footnotetext[48]{questa modalità è disponibile solo a partire dal kernel
+\footnotetext[48]{questa modalità è disponibile solo a partire dal kernel
   2.6.2.}
 
-Le modalità di utilizzo di \textit{epoll} prevedono che si definisca qual'è
+Le modalità di utilizzo di \textit{epoll} prevedono che si definisca qual'è
 l'insieme dei file descriptor da tenere sotto controllo tramite un certo
 \textit{epoll descriptor} \param{epfd} attraverso una serie di chiamate a
-\const{EPOLL\_CTL\_ADD}.\footnote{un difetto dell'interfaccia è che queste
+\const{EPOLL\_CTL\_ADD}.\footnote{un difetto dell'interfaccia è che queste
   chiamate devono essere ripetute per ciascun file descriptor, incorrendo in
   una perdita di prestazioni qualora il numero di file descriptor sia molto
-  grande; per questo è stato proposto di introdurre come estensione una
+  grande; per questo è stato proposto di introdurre come estensione una
   funzione \func{epoll\_ctlv} che consenta di effettuare con una sola chiamata
   le impostazioni per un blocco di file descriptor.} L'uso di
-\const{EPOLL\_CTL\_MOD} consente in seguito di modificare le modalità di
-osservazione di un file descriptor che sia già stato aggiunto alla lista di
+\const{EPOLL\_CTL\_MOD} consente in seguito di modificare le modalità di
+osservazione di un file descriptor che sia già stato aggiunto alla lista di
 osservazione.
 
 Le impostazioni di default prevedono che la notifica degli eventi richiesti
-sia effettuata in modalità \textit{level triggered}, a meno che sul file
-descriptor non si sia impostata la modalità \textit{edge triggered},
+sia effettuata in modalità \textit{level triggered}, a meno che sul file
+descriptor non si sia impostata la modalità \textit{edge triggered},
 registrandolo con \const{EPOLLET} attivo nel campo \var{events}.  Si tenga
-presente che è possibile tenere sotto osservazione uno stesso file descriptor
+presente che è possibile tenere sotto osservazione uno stesso file descriptor
 su due \textit{epoll descriptor} diversi, ed entrambi riceveranno le
-notifiche, anche se questa pratica è sconsigliata.
+notifiche, anche se questa pratica è sconsigliata.
 
-Qualora non si abbia più interesse nell'osservazione di un file descriptor lo
-si può rimuovere dalla lista associata a \param{epfd} con
+Qualora non si abbia più interesse nell'osservazione di un file descriptor lo
+si può rimuovere dalla lista associata a \param{epfd} con
 \const{EPOLL\_CTL\_DEL}; si tenga conto inoltre che i file descriptor sotto
 osservazione che vengono chiusi sono eliminati dalla lista automaticamente e
-non è necessario usare \const{EPOLL\_CTL\_DEL}.
+non è necessario usare \const{EPOLL\_CTL\_DEL}.
 
-Infine una particolare modalità di notifica è quella impostata con
+Infine una particolare modalità di notifica è quella impostata con
 \const{EPOLLONESHOT}: a causa dell'implementazione di \textit{epoll} infatti
-quando si è in modalità \textit{edge triggered} l'arrivo in rapida successione
-di dati in blocchi separati\footnote{questo è tipico con i socket di rete, in
-  quanto i dati arrivano a pacchetti.} può causare una generazione di eventi
+quando si è in modalità \textit{edge triggered} l'arrivo in rapida successione
+di dati in blocchi separati\footnote{questo è tipico con i socket di rete, in
+  quanto i dati arrivano a pacchetti.} può causare una generazione di eventi
 (ad esempio segnalazioni di dati in lettura disponibili) anche se la
-condizione è già stata rilevata.\footnote{si avrebbe cioè una rottura della
+condizione è già stata rilevata.\footnote{si avrebbe cioè una rottura della
   logica \textit{edge triggered}.} 
 
-Anche se la situazione è facile da gestire, la si può evitare utilizzando
-\const{EPOLLONESHOT} per impostare la modalità \textit{one-shot}, in cui la
+Anche se la situazione è facile da gestire, la si può evitare utilizzando
+\const{EPOLLONESHOT} per impostare la modalità \textit{one-shot}, in cui la
 notifica di un evento viene effettuata una sola volta, dopo di che il file
 descriptor osservato, pur restando nella lista di osservazione, viene
 automaticamente disattivato,\footnote{la cosa avviene contestualmente al
   ritorno di \func{epoll\_wait} a causa dell'evento in questione.} e per
-essere riutilizzato dovrà essere riabilitato esplicitamente con una successiva
+essere riutilizzato dovrà essere riabilitato esplicitamente con una successiva
 chiamata con \const{EPOLL\_CTL\_MOD}.
 
 Una volta impostato l'insieme di file descriptor che si vogliono osservare con
 i relativi eventi, la funzione che consente di attendere l'occorrenza di uno
-di tali eventi è \funcd{epoll\_wait}, il cui prototipo è:
+di tali eventi è \funcd{epoll\_wait}, il cui prototipo è:
 \begin{prototype}{sys/epoll.h}
   {int epoll\_wait(int epfd, struct epoll\_event * events, int maxevents, int
     timeout)}
@@ -1760,14 +1760,14 @@ di tali eventi 
   
   \bodydesc{La funzione restituisce il numero di file descriptor pronti in
     caso di successo o $-1$ in caso di errore, nel qual caso \var{errno}
-    assumerà uno dei valori:
+    assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EBADF}] il file descriptor \param{epfd} non è valido.
-  \item[\errcode{EFAULT}] il puntatore \param{events} non è valido.
-  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima
+  \item[\errcode{EBADF}] il file descriptor \param{epfd} non è valido.
+  \item[\errcode{EFAULT}] il puntatore \param{events} non è valido.
+  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima
     della scadenza di \param{timeout}.
-  \item[\errcode{EINVAL}] il file descriptor \param{epfd} non è stato ottenuto
-    con \func{epoll\_create}, o \param{maxevents} non è maggiore di zero.
+  \item[\errcode{EINVAL}] il file descriptor \param{epfd} non è stato ottenuto
+    con \func{epoll\_create}, o \param{maxevents} non è maggiore di zero.
   \end{errlist}
 }
 \end{prototype}
@@ -1782,52 +1782,52 @@ con l'argomento \param{maxevents}.
 
 La funzione ritorna il numero di eventi rilevati, o un valore nullo qualora
 sia scaduto il tempo massimo impostato con \param{timeout}. Per quest'ultimo,
-oltre ad un numero di millisecondi, si può utilizzare il valore nullo, che
+oltre ad un numero di millisecondi, si può utilizzare il valore nullo, che
 indica di non attendere e ritornare immediatamente,\footnote{anche in questo
-  caso il valore di ritorno sarà nullo.} o il valore $-1$, che indica
-un'attesa indefinita. L'argomento \param{maxevents} dovrà invece essere sempre
+  caso il valore di ritorno sarà nullo.} o il valore $-1$, che indica
+un'attesa indefinita. L'argomento \param{maxevents} dovrà invece essere sempre
 un intero positivo.
 
 Come accennato la funzione restituisce i suoi risultati nel vettore di
 strutture \struct{epoll\_event} puntato da \param{events}; in tal caso nel
 campo \param{events} di ciascuna di esse saranno attivi i flag relativi agli
-eventi accaduti, mentre nel campo \var{data} sarà restituito il valore che era
-stato impostato per il file descriptor per cui si è verificato l'evento quando
+eventi accaduti, mentre nel campo \var{data} sarà restituito il valore che era
+stato impostato per il file descriptor per cui si è verificato l'evento quando
 questo era stato registrato con le operazioni \const{EPOLL\_CTL\_MOD} o
 \const{EPOLL\_CTL\_ADD}, in questo modo il campo \var{data} consente di
-identificare il file descriptor.\footnote{ed è per questo che, come accennato,
-  è consuetudine usare per \var{data} il valore del file descriptor stesso.}
+identificare il file descriptor.\footnote{ed è per questo che, come accennato,
+  è consuetudine usare per \var{data} il valore del file descriptor stesso.}
 
 Si ricordi che le occasioni per cui \func{epoll\_wait} ritorna dipendono da
-come si è impostata la modalità di osservazione (se \textit{level triggered} o
+come si è impostata la modalità di osservazione (se \textit{level triggered} o
 \textit{edge triggered}) del singolo file descriptor. L'interfaccia assicura
-che se arrivano più eventi fra due chiamate successive ad \func{epoll\_wait}
+che se arrivano più eventi fra due chiamate successive ad \func{epoll\_wait}
 questi vengano combinati. Inoltre qualora su un file descriptor fossero
 presenti eventi non ancora notificati, e si effettuasse una modifica
 dell'osservazione con \const{EPOLL\_CTL\_MOD}, questi verrebbero riletti alla
 luce delle modifiche.
 
-Si tenga presente infine che con l'uso della modalità \textit{edge triggered}
-il ritorno di \func{epoll\_wait} indica che un file descriptor è pronto e
-resterà tale fintanto che non si sono completamente esaurite le operazioni su
+Si tenga presente infine che con l'uso della modalità \textit{edge triggered}
+il ritorno di \func{epoll\_wait} indica che un file descriptor è pronto e
+resterà tale fintanto che non si sono completamente esaurite le operazioni su
 di esso.  Questa condizione viene generalmente rilevata dall'occorrere di un
 errore di \errcode{EAGAIN} al ritorno di una \func{read} o una
-\func{write},\footnote{è opportuno ricordare ancora una volta che l'uso
-  dell'\textit{I/O multiplexing} richiede di operare sui file in modalità non
-  bloccante.} ma questa non è la sola modalità possibile, ad esempio la
-condizione può essere riconosciuta anche per il fatto che sono stati
+\func{write},\footnote{è opportuno ricordare ancora una volta che l'uso
+  dell'\textit{I/O multiplexing} richiede di operare sui file in modalità non
+  bloccante.} ma questa non è la sola modalità possibile, ad esempio la
+condizione può essere riconosciuta anche per il fatto che sono stati
 restituiti meno dati di quelli richiesti.
 
-Come già per \func{select} e \func{poll} anche per l'interfaccia di
+Come già per \func{select} e \func{poll} anche per l'interfaccia di
 \textit{epoll} si pone il problema di gestire l'attesa di segnali e di dati
 contemporaneamente per le osservazioni fatte in sez.~\ref{sec:file_select},
-per fare questo di nuovo è necessaria una variante della funzione di attesa
+per fare questo di nuovo è necessaria una variante della funzione di attesa
 che consenta di reimpostare all'uscita una maschera di segnali, analoga alle
 estensioni \func{pselect} e \func{ppoll} che abbiamo visto in precedenza per
 \func{select} e \func{poll}; in questo caso la funzione si chiama
-\funcd{epoll\_pwait}\footnote{la funziona è stata introdotta a partire dal
-  kernel 2.6.19, ed è come tutta l'interfaccia di \textit{epoll}, specifica di
-  Linux.} ed il suo prototipo è:
+\funcd{epoll\_pwait}\footnote{la funziona è stata introdotta a partire dal
+  kernel 2.6.19, ed è come tutta l'interfaccia di \textit{epoll}, specifica di
+  Linux.} ed il suo prototipo è:
 \begin{prototype}{sys/epoll.h} 
   {int epoll\_pwait(int epfd, struct epoll\_event * events, int maxevents, 
     int timeout, const sigset\_t *sigmask)}
@@ -1837,14 +1837,14 @@ estensioni \func{pselect} e \func{ppoll} che abbiamo visto in precedenza per
 
   \bodydesc{La funzione restituisce il numero di file descriptor pronti in
     caso di successo o $-1$ in caso di errore, nel qual caso \var{errno}
-    assumerà uno dei valori già visti con \funcd{epoll\_wait}.
+    assumerà uno dei valori già visti con \funcd{epoll\_wait}.
 }
 \end{prototype}
 
-La funzione è del tutto analoga \funcd{epoll\_wait}, soltanto che alla sua
+La funzione è del tutto analoga \funcd{epoll\_wait}, soltanto che alla sua
 uscita viene ripristinata la maschera di segnali originale, sostituita durante
 l'esecuzione da quella impostata con l'argomento \param{sigmask}; in sostanza
-la chiamata a questa funzione è equivalente al seguente codice, eseguito però
+la chiamata a questa funzione è equivalente al seguente codice, eseguito però
 in maniera atomica:
 \includecodesnip{listati/epoll_pwait_means.c} 
 
@@ -1853,7 +1853,7 @@ anche le funzioni dell'interfaccia di \textit{epoll} vengono utilizzate
 prevalentemente con i server di rete, quando si devono tenere sotto
 osservazione un gran numero di socket; per questo motivo rimandiamo anche in
 questo caso la trattazione di un esempio concreto a quando avremo esaminato in
-dettaglio le caratteristiche dei socket; in particolare si potrà trovare un
+dettaglio le caratteristiche dei socket; in particolare si potrà trovare un
 programma che utilizza questa interfaccia in sez.~\ref{sec:TCP_serv_epoll}.
 
 \itindend{epoll}
@@ -1870,86 +1870,86 @@ l'\textit{I/O multiplexing}, tanto che per evitare possibili
 estensioni dello standard POSIX e funzioni apposite come \func{pselect},
 \func{ppoll} e \funcd{epoll\_pwait}.
 
-Benché i segnali siano il meccanismo più usato per effettuare notifiche ai
+Benché i segnali siano il meccanismo più usato per effettuare notifiche ai
 processi, la loro interfaccia di programmazione, che comporta l'esecuzione di
 una funzione di gestione in maniera asincrona e totalmente scorrelata
-dall'ordinario flusso di esecuzione del processo, si è però dimostrata quasi
-subito assai problematica. Oltre ai limiti relativi ai limiti al cosa si può
+dall'ordinario flusso di esecuzione del processo, si è però dimostrata quasi
+subito assai problematica. Oltre ai limiti relativi ai limiti al cosa si può
 fare all'interno della funzione del gestore di segnali (quelli illustrati in
-sez.~\ref{sec:sig_signal_handler}), c'è il problema più generale consistente
-nel fatto che questa modalità di funzionamento cozza con altre interfacce di
+sez.~\ref{sec:sig_signal_handler}), c'è il problema più generale consistente
+nel fatto che questa modalità di funzionamento cozza con altre interfacce di
 programmazione previste dal sistema in cui si opera in maniera
 \textsl{sincrona}, come quelle dell'I/O multiplexing appena illustrate.
 
 In questo tipo di interfacce infatti ci si aspetta che il processo gestisca
 gli eventi a cui vuole rispondere in maniera sincrona generando le opportune
 risposte, mentre con l'arrivo di un segnale si possono avere interruzioni
-asincrone in qualunque momento.  Questo comporta la necessità di dover
+asincrone in qualunque momento.  Questo comporta la necessità di dover
 gestire, quando si deve tener conto di entrambi i tipi di eventi, le
 interruzioni delle funzioni di attesa sincrone, ed evitare possibili
 \itindex{race~condition} \textit{race conditions}.\footnote{in sostanza se non
   fossero per i segnali non ci sarebbe da doversi preoccupare, fintanto che si
-  effettuano operazioni all'interno di un processo, della non atomicità delle
+  effettuano operazioni all'interno di un processo, della non atomicità delle
   \index{system~call~lente} system call lente che vengono interrotte e devono
   essere riavviate.}
 
-Abbiamo visto però in sez.~\ref{sec:sig_real_time} che insieme ai segnali
+Abbiamo visto però in sez.~\ref{sec:sig_real_time} che insieme ai segnali
 \textit{real-time} sono state introdotte anche delle interfacce di gestione
 sincrona dei segnali con la funzione \func{sigwait} e le sue affini. Queste
 funzioni consentono di gestire i segnali bloccando un processo fino alla
 avvenuta ricezione e disabilitando l'esecuzione asincrona rispetto al resto
 del programma del gestore del segnale. Questo consente di risolvere i problemi
-di atomicità nella gestione degli eventi associati ai segnali, avendo tutto il
-controllo nel flusso principale del programma, ottenendo così una gestione
+di atomicità nella gestione degli eventi associati ai segnali, avendo tutto il
+controllo nel flusso principale del programma, ottenendo così una gestione
 simile a quella dell'\textit{I/O multiplexing}, ma non risolve i problemi
-delle interazioni con quest'ultimo, perché o si aspetta la ricezione di un
+delle interazioni con quest'ultimo, perché o si aspetta la ricezione di un
 segnale o si aspetta che un file descriptor sia accessibile e nessuna delle
 rispettive funzioni consente di fare contemporaneamente entrambe le cose.
 
-Per risolvere questo problema nello sviluppo del kernel si è pensato di
+Per risolvere questo problema nello sviluppo del kernel si è pensato di
 introdurre un meccanismo alternativo alla notifica dei segnali (esteso anche
 ad altri eventi generici) che, ispirandosi di nuovo alla filosofia di Unix per
-cui tutto è un file, consentisse di eseguire la notifica con l'uso di
-opportuni file descriptor.\footnote{ovviamente si tratta di una funzionalità
+cui tutto è un file, consentisse di eseguire la notifica con l'uso di
+opportuni file descriptor.\footnote{ovviamente si tratta di una funzionalità
   specifica di Linux, non presente in altri sistemi unix-like, e non prevista
-  da nessuno standard, per cui va evitata se si ha a cuore la portabilità.}
+  da nessuno standard, per cui va evitata se si ha a cuore la portabilità.}
 
-In sostanza, come per \func{sigwait}, si può disabilitare l'esecuzione di un
+In sostanza, come per \func{sigwait}, si può disabilitare l'esecuzione di un
 gestore in occasione dell'arrivo di un segnale, e rilevarne l'avvenuta
 ricezione leggendone la notifica tramite l'uso di uno speciale file
-descriptor. Trattandosi di un file descriptor questo potrà essere tenuto sotto
+descriptor. Trattandosi di un file descriptor questo potrà essere tenuto sotto
 osservazione con le ordinarie funzioni dell'\textit{I/O multiplexing} (vale a
 dire con le solite \func{select}, \func{poll} e \funcd{epoll\_wait}) allo
-stesso modo di quelli associati a file o socket, per cui alla fine si potrà
-attendere in contemporanea sia l'arrivo del segnale che la disponibilità di
+stesso modo di quelli associati a file o socket, per cui alla fine si potrà
+attendere in contemporanea sia l'arrivo del segnale che la disponibilità di
 accesso ai dati relativi a questi ultimi.
 
 La funzione che permette di abilitare la ricezione dei segnali tramite file
-descriptor è \funcd{signalfd},\footnote{in realtà quella riportata è
+descriptor è \funcd{signalfd},\footnote{in realtà quella riportata è
   l'interfaccia alla funzione fornita dalle \acr{glibc}, esistono infatti due
   versioni diverse della \textit{system call}; una prima versione,
   \func{signalfd}, introdotta nel kernel 2.6.22 e disponibile con le
   \acr{glibc} 2.8 che non supporta l'argomento \texttt{flags}, ed una seconda
-  versione, \func{signalfd4}, introdotta con il kernel 2.6.27 e che è quella
+  versione, \func{signalfd4}, introdotta con il kernel 2.6.27 e che è quella
   che viene sempre usata a partire dalle \acr{glibc} 2.9, che prende un
   argomento aggiuntivo \code{size\_t sizemask} che indica la dimensione della
   maschera dei segnali, il cui valore viene impostato automaticamente dalle
-  \acr{glibc}.}  il cui prototipo è:
+  \acr{glibc}.}  il cui prototipo è:
 \begin{prototype}{sys/signalfd.h} 
   {int signalfd(int fd, const sigset\_t *mask, int flags)}
 
   Crea o modifica un file descriptor per la ricezione dei segnali. 
 
   \bodydesc{La funzione restituisce un numero di file descriptor in caso di
-    successo o $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
+    successo o $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
     dei valori:
   \begin{errlist}
   \item[\errcode{EBADF}] il valore \param{fd} non indica un file descriptor.
-  \item[\errcode{EINVAL}] il file descriptor \param{fd} non è stato ottenuto
-    con \func{signalfd} o il valore di \param{flags} non è valido.
-  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare un nuovo file
+  \item[\errcode{EINVAL}] il file descriptor \param{fd} non è stato ottenuto
+    con \func{signalfd} o il valore di \param{flags} non è valido.
+  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare un nuovo file
     descriptor di \func{signalfd}.
-  \item[\errcode{ENODEV}] il kernel non può montare internamente il
+  \item[\errcode{ENODEV}] il kernel non può montare internamente il
     dispositivo per la gestione anonima degli inode associati al file
     descriptor.
   \end{errlist}
@@ -1959,28 +1959,28 @@ descriptor 
 
 La funzione consente di creare o modificare le caratteristiche di un file
 descriptor speciale su cui ricevere le notifiche della ricezione di
-segnali. Per creare ex-novo uno di questi file descriptor è necessario passare
-$-1$ come valore per l'argomento \param{fd}, ogni altro valore positivo verrà
+segnali. Per creare ex-novo uno di questi file descriptor è necessario passare
+$-1$ come valore per l'argomento \param{fd}, ogni altro valore positivo verrà
 invece interpretato come il numero del file descriptor (che deve esser stato
 precedentemente creato sempre con \func{signalfd}) di cui si vogliono
-modificare le caratteristiche. Nel primo caso la funzione ritornerà il valore
+modificare le caratteristiche. Nel primo caso la funzione ritornerà il valore
 del nuovo file descriptor e nel secondo caso il valore indicato
-con \param{fd}, in caso di errore invece verrà restituito $-1$.
+con \param{fd}, in caso di errore invece verrà restituito $-1$.
 
 L'elenco dei segnali che si vogliono gestire con \func{signalfd} deve essere
 specificato tramite l'argomento \param{mask}. Questo deve essere passato come
-puntatore ad una maschera di segnali creata con l'uso delle apposite macro già
+puntatore ad una maschera di segnali creata con l'uso delle apposite macro già
 illustrate in sez.~\ref{sec:sig_sigset}. La maschera deve indicare su quali
-segnali si intende operare con \func{signalfd}; l'elenco può essere modificato
+segnali si intende operare con \func{signalfd}; l'elenco può essere modificato
 con una successiva chiamata a \func{signalfd}. Dato che \const{SIGKILL} e
 \const{SIGSTOP} non possono essere intercettati (e non prevedono neanche la
-possibilità di un gestore) un loro inserimento nella maschera verrà ignorato
+possibilità di un gestore) un loro inserimento nella maschera verrà ignorato
 senza generare errori. 
 
 L'argomento \param{flags} consente di impostare direttamente in fase di
 creazione due flag per il file descriptor analoghi a quelli che si possono
 impostare con una creazione ordinaria con \func{open}, evitando una
-impostazione successiva con \func{fcntl}.\footnote{questo è un argomento
+impostazione successiva con \func{fcntl}.\footnote{questo è un argomento
   aggiuntivo, introdotto con la versione fornita a partire dal kernel 2.6.27,
   per kernel precedenti il valore deve essere nullo.} L'argomento deve essere
 specificato come maschera binaria dei valori riportati in
@@ -2008,38 +2008,38 @@ tab.~\ref{tab:signalfd_flags}.
 
 Si tenga presente che la chiamata a \func{signalfd} non disabilita la gestione
 ordinaria dei segnali indicati da \param{mask}; questa, se si vuole effettuare
-la ricezione tramite il file descriptor, dovrà essere disabilitata
+la ricezione tramite il file descriptor, dovrà essere disabilitata
 esplicitamente bloccando gli stessi segnali con \func{sigprocmask}, altrimenti
 verranno comunque eseguite le azioni di default (o un eventuale gestore
 installato in precedenza).\footnote{il blocco non ha invece nessun effetto sul
-  file descriptor restituito da \func{signalfd}, dal quale sarà possibile
+  file descriptor restituito da \func{signalfd}, dal quale sarà possibile
   pertanto ricevere qualunque segnale, anche se questo risultasse bloccato.}
 Si tenga presente inoltre che la lettura di una struttura
-\struct{signalfd\_siginfo} relativa ad un segnale pendente è equivalente alla
-esecuzione di un gestore, vale a dire che una volta letta il segnale non sarà
-più pendente e non potrà essere ricevuto, qualora si ripristino le normali
-condizioni di gestione, né da un gestore né dalla funzione \func{sigwaitinfo}.
+\struct{signalfd\_siginfo} relativa ad un segnale pendente è equivalente alla
+esecuzione di un gestore, vale a dire che una volta letta il segnale non sarà
+più pendente e non potrà essere ricevuto, qualora si ripristino le normali
+condizioni di gestione, né da un gestore né dalla funzione \func{sigwaitinfo}.
 
 Come anticipato, essendo questo lo scopo principale della nuova interfaccia,
-il file descriptor può essere tenuto sotto osservazione tramite le funzioni
+il file descriptor può essere tenuto sotto osservazione tramite le funzioni
 dell'\textit{I/O multiplexing} (vale a dire con le solite \func{select},
-\func{poll} e \funcd{epoll\_wait}), e risulterà accessibile in lettura quando
-uno o più dei segnali indicati tramite \param{mask} sarà pendente.
-
-La funzione può essere chiamata più volte dallo stesso processo, consentendo
-così di tenere sotto osservazione segnali diversi tramite file descriptor
-diversi. Inoltre è anche possibile tenere sotto osservazione lo stesso segnale
-con più file descriptor, anche se la pratica è sconsigliata; in tal caso la
-ricezione del segnale potrà essere effettuata con una lettura da uno qualunque
-dei file descriptor a cui è associato, ma questa potrà essere eseguita
+\func{poll} e \funcd{epoll\_wait}), e risulterà accessibile in lettura quando
+uno o più dei segnali indicati tramite \param{mask} sarà pendente.
+
+La funzione può essere chiamata più volte dallo stesso processo, consentendo
+così di tenere sotto osservazione segnali diversi tramite file descriptor
+diversi. Inoltre è anche possibile tenere sotto osservazione lo stesso segnale
+con più file descriptor, anche se la pratica è sconsigliata; in tal caso la
+ricezione del segnale potrà essere effettuata con una lettura da uno qualunque
+dei file descriptor a cui è associato, ma questa potrà essere eseguita
 soltanto una volta.\footnote{questo significa che tutti i file descriptor su
-  cui è presente lo stesso segnale risulteranno pronti in lettura per le
+  cui è presente lo stesso segnale risulteranno pronti in lettura per le
   funzioni di \textit{I/O multiplexing}, ma una volta eseguita la lettura su
-  uno di essi il segnale sarà considerato ricevuto ed i relativi dati non
-  saranno più disponibili sugli altri file descriptor, che (a meno di una
-  ulteriore occorrenza del segnale nel frattempo) di non saranno più pronti.}
+  uno di essi il segnale sarà considerato ricevuto ed i relativi dati non
+  saranno più disponibili sugli altri file descriptor, che (a meno di una
+  ulteriore occorrenza del segnale nel frattempo) di non saranno più pronti.}
 
-Quando il file descriptor per la ricezione dei segnali non serve più potrà
+Quando il file descriptor per la ricezione dei segnali non serve più potrà
 essere chiuso con \func{close} liberando tutte le risorse da esso allocate. In
 tal caso qualora vi fossero segnali pendenti questi resteranno tali, e
 potranno essere ricevuti normalmente una volta che si rimuova il blocco
@@ -2056,8 +2056,8 @@ anche alla ordinaria semantica relativa ai segnali bloccati, che restano
 pendenti attraverso una \func{exec}.
 
 Analogamente il file descriptor resta sempre disponibile attraverso una
-\func{fork} per il processo figlio, che ne riceve una copia; in tal caso però
-il figlio potrà leggere dallo stesso soltanto i dati relativi ai segnali
+\func{fork} per il processo figlio, che ne riceve una copia; in tal caso però
+il figlio potrà leggere dallo stesso soltanto i dati relativi ai segnali
 ricevuti da lui stesso. Nel caso di \textit{thread} viene nuovamente seguita
 la semantica ordinaria dei segnali, che prevede che un singolo \textit{thread}
 possa ricevere dal file descriptor solo le notifiche di segnali inviati
@@ -2067,8 +2067,8 @@ direttamente a lui o al processo in generale, e non quelli relativi ad altri
 L'interfaccia fornita da \func{signalfd} prevede che la ricezione dei segnali
 sia eseguita leggendo i dati relativi ai segnali pendenti dal file descriptor
 restituito dalla funzione con una normalissima \func{read}.  Qualora non vi
-siano segnali pendenti la \func{read} si bloccherà a meno di non aver
-impostato la modalità di I/O non bloccante sul file descriptor, o direttamente
+siano segnali pendenti la \func{read} si bloccherà a meno di non aver
+impostato la modalità di I/O non bloccante sul file descriptor, o direttamente
 in fase di creazione con il flag \const{SFD\_NONBLOCK}, o in un momento
 successivo con \func{fcntl}.  
 
@@ -2084,55 +2084,55 @@ successivo con \func{fcntl}.
 \end{figure}
 
 I dati letti dal file descriptor vengono scritti sul buffer indicato come
-secondo argomento di \func{read} nella forma di una sequenza di una o più
-strutture \struct{signalfd\_siginfo} (la cui definizione si è riportata in
+secondo argomento di \func{read} nella forma di una sequenza di una o più
+strutture \struct{signalfd\_siginfo} (la cui definizione si è riportata in
 fig.~\ref{fig:signalfd_siginfo}) a seconda sia della dimensione del buffer che
 del numero di segnali pendenti. Per questo motivo il buffer deve essere almeno
 di dimensione pari a quella di \struct{signalfd\_siginfo}, qualora sia di
 dimensione maggiore potranno essere letti in unica soluzione i dati relativi
-ad eventuali più segnali pendenti, fino al numero massimo di strutture
+ad eventuali più segnali pendenti, fino al numero massimo di strutture
 \struct{signalfd\_siginfo} che possono rientrare nel buffer.
 
 Il contenuto di \struct{signalfd\_siginfo} ricalca da vicino quella della
 analoga struttura \struct{siginfo\_t} (illustrata in
 fig.~\ref{fig:sig_siginfo_t}) usata dall'interfaccia ordinaria dei segnali, e
 restituisce dati simili. Come per \struct{siginfo\_t} i campi che vengono
-avvalorati dipendono dal tipo di segnale e ricalcano i valori che abbiamo già
-illustrato in sez.~\ref{sec:sig_sigaction}.\footnote{si tenga presente però
+avvalorati dipendono dal tipo di segnale e ricalcano i valori che abbiamo già
+illustrato in sez.~\ref{sec:sig_sigaction}.\footnote{si tenga presente però
   che per un bug i kernel fino al 2.6.25 non avvalorano correttamente i campi
   \var{ssi\_ptr} e \var{ssi\_int} per segnali inviati con \func{sigqueue}.}
 
-Lo stesso paradigma di notifica tramite file descriptor usato per i segnali è
+Lo stesso paradigma di notifica tramite file descriptor usato per i segnali è
 stato adottato anche per i timer; in questo caso, rispetto a quanto visto in
-sez.~\ref{sec:sig_timer_adv}, la scadenza di un timer potrà essere letta da un
+sez.~\ref{sec:sig_timer_adv}, la scadenza di un timer potrà essere letta da un
 file descriptor, senza dover ricorrere ad altri meccanismi di notifica come un
 segnale o un \textit{thread}. Di nuovo questo ha il vantaggio di poter
 utilizzare le funzioni dell'\textit{I/O multiplexing} per attendere allo
-stesso tempo la disponibilità di dati o la ricezione di un segnale
-qualunque.\footnote{in realtà per questo sarebbe già sufficiente
-  \func{signalfd} per ricevere i segnali associati ai timer, ma la nuova
-  interfaccia semplifica notevolmente la gestione.}
+stesso tempo la disponibilità di dati o la ricezione scadenza di un
+timer.\footnote{in realtà per questo sarebbe già sufficiente \func{signalfd}
+  per ricevere i segnali associati ai timer, ma la nuova interfaccia
+  semplifica notevolmente la gestione e diminuisce l'\textit{overhead}.}
 
 Le funzioni di questa interfaccia riprendono da vicino quelle introdotte da
 POSIX.1-2001 illustrate sez.~\ref{sec:sig_timer_adv}. La prima funzione, che
-consente di creare un \textit{timer} è \funcd{timerfd\_create}, il cui
-prototipo è:
+consente di creare un \textit{timer} è \funcd{timerfd\_create}, il cui
+prototipo è:
 \begin{prototype}{sys/timerfd.h} 
   {int timerfd\_create(int clockid, int flags)}
 
   Crea un timer associato ad un file descriptor per la notifica. 
 
   \bodydesc{La funzione restituisce un numero di file descriptor in caso di
-    successo o $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
+    successo o $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
     dei valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] l'argomento \param{clockid} non è
+  \item[\errcode{EINVAL}] l'argomento \param{clockid} non è
     \const{CLOCK\_MONOTONIC} o \const{CLOCK\_REALTIME}, o
-    l'argomento \param{flag} non è valido o diverso da zero per kernel
+    l'argomento \param{flag} non è valido o diverso da zero per kernel
     precedenti il 2.6.27.
-  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare un nuovo file
+  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare un nuovo file
     descriptor di \func{signalfd}.
-  \item[\errcode{ENODEV}] il kernel non può montare internamente il
+  \item[\errcode{ENODEV}] il kernel non può montare internamente il
     dispositivo per la gestione anonima degli inode associati al file
     descriptor.
   \end{errlist}
@@ -2141,12 +2141,13 @@ prototipo 
 \end{prototype}
 
 La funzione prende come primo argomento il tipo di orologio a cui il timer
-deve fare riferimento, ed i soli valori validi sono \const{CLOCK\_REALTIME},
-per indicare 
+deve fare riferimento, il cui significato è già stato illustrato in
+tab.~\ref{tab:sig_timer_clockid_types}, ma i soli valori validi sono
+\const{CLOCK\_REALTIME} e \const{CLOCK\_MONOTONIC}. 
 
 
 % TODO trattare qui eventfd, timerfd introdotte con il 2.6.22 
-% timerfd è stata tolta nel 2.6.23 e rifatta per bene nel 2.6.25
+% timerfd è stata tolta nel 2.6.23 e rifatta per bene nel 2.6.25
 % vedi: http://lwn.net/Articles/233462/
 %       http://lwn.net/Articles/245533/
 %       http://lwn.net/Articles/267331/
@@ -2180,16 +2181,16 @@ per indicare
 \section{L'accesso \textsl{asincrono} ai file}
 \label{sec:file_asyncronous_access}
 
-Benché l'\textit{I/O multiplexing} sia stata la prima, e sia tutt'ora una fra
-le più diffuse modalità di gestire l'I/O in situazioni complesse in cui si
-debba operare su più file contemporaneamente, esistono altre modalità di
+Benché l'\textit{I/O multiplexing} sia stata la prima, e sia tutt'ora una fra
+le più diffuse modalità di gestire l'I/O in situazioni complesse in cui si
+debba operare su più file contemporaneamente, esistono altre modalità di
 gestione delle stesse problematiche. In particolare sono importanti in questo
-contesto le modalità di accesso ai file eseguibili in maniera
-\textsl{asincrona}, quelle cioè in cui un processo non deve bloccarsi in
-attesa della disponibilità dell'accesso al file, ma può proseguire
+contesto le modalità di accesso ai file eseguibili in maniera
+\textsl{asincrona}, quelle cioè in cui un processo non deve bloccarsi in
+attesa della disponibilità dell'accesso al file, ma può proseguire
 nell'esecuzione utilizzando invece un meccanismo di notifica asincrono (di
 norma un segnale, ma esistono anche altre interfacce, come \itindex{inotify}
-\textit{inotify}), per essere avvisato della possibilità di eseguire le
+\textit{inotify}), per essere avvisato della possibilità di eseguire le
 operazioni di I/O volute.
 
 
@@ -2198,40 +2199,40 @@ operazioni di I/O volute.
 
 \itindbeg{signal~driven~I/O}
 
-Abbiamo accennato in sez.~\ref{sec:file_open} che è possibile, attraverso
+Abbiamo accennato in sez.~\ref{sec:file_open} che è possibile, attraverso
 l'uso del flag \const{O\_ASYNC},\footnote{l'uso del flag di \const{O\_ASYNC} e
-  dei comandi \const{F\_SETOWN} e \const{F\_GETOWN} per \func{fcntl} è
-  specifico di Linux e BSD.} aprire un file in modalità asincrona, così come è
-possibile attivare in un secondo tempo questa modalità impostando questo flag
+  dei comandi \const{F\_SETOWN} e \const{F\_GETOWN} per \func{fcntl} è
+  specifico di Linux e BSD.} aprire un file in modalità asincrona, così come è
+possibile attivare in un secondo tempo questa modalità impostando questo flag
 attraverso l'uso di \func{fcntl} con il comando \const{F\_SETFL} (vedi
-sez.~\ref{sec:file_fcntl}). In realtà parlare di apertura in modalità
+sez.~\ref{sec:file_fcntl}). In realtà parlare di apertura in modalità
 asincrona non significa che le operazioni di lettura o scrittura del file
-vengono eseguite in modo asincrono (tratteremo questo, che è ciò che più
+vengono eseguite in modo asincrono (tratteremo questo, che è ciò che più
 propriamente viene chiamato \textsl{I/O asincrono}, in
 sez.~\ref{sec:file_asyncronous_io}), quanto dell'attivazione un meccanismo di
 notifica asincrona delle variazione dello stato del file descriptor aperto in
 questo modo.  
 
-Quello che succede è che per tutti i file posti in questa modalità\footnote{si
-  tenga presente però che essa non è utilizzabile con i file ordinari ma solo
+Quello che succede è che per tutti i file posti in questa modalità\footnote{si
+  tenga presente però che essa non è utilizzabile con i file ordinari ma solo
   con socket, file di terminale o pseudo terminale, ed anche, a partire dal
   kernel 2.6, anche per fifo e pipe.} il sistema genera un apposito segnale,
 \const{SIGIO}, tutte le volte che diventa possibile leggere o scrivere dal
-file descriptor che si è posto in questa modalità. Inoltre è possibile, come
+file descriptor che si è posto in questa modalità. Inoltre è possibile, come
 illustrato in sez.~\ref{sec:file_fcntl}, selezionare con il comando
 \const{F\_SETOWN} di \func{fcntl} quale processo o quale gruppo di processi
-dovrà ricevere il segnale. In questo modo diventa possibile effettuare le
-operazioni di I/O in risposta alla ricezione del segnale, e non ci sarà più la
-necessità di restare bloccati in attesa della disponibilità di accesso ai
+dovrà ricevere il segnale. In questo modo diventa possibile effettuare le
+operazioni di I/O in risposta alla ricezione del segnale, e non ci sarà più la
+necessità di restare bloccati in attesa della disponibilità di accesso ai
 file.
 
 % TODO: per i thread l'uso di F_SETOWN ha un significato diverso
 
 Per questo motivo Stevens, ed anche le pagine di manuale di Linux, chiamano
-questa modalità ``\textit{Signal driven I/O}''.  Si tratta di un'altra
-modalità di gestione dell'I/O, alternativa all'uso di \itindex{epoll}
+questa modalità ``\textit{Signal driven I/O}''.  Si tratta di un'altra
+modalità di gestione dell'I/O, alternativa all'uso di \itindex{epoll}
 \textit{epoll},\footnote{anche se le prestazioni ottenute con questa tecnica
-  sono inferiori, il vantaggio è che questa modalità è utilizzabile anche con
+  sono inferiori, il vantaggio è che questa modalità è utilizzabile anche con
   kernel che non supportano \textit{epoll}, come quelli della serie 2.4,
   ottenendo comunque prestazioni superiori a quelle che si hanno con
   \func{poll} e \func{select}.} che consente di evitare l'uso delle funzioni
@@ -2239,46 +2240,46 @@ modalit
 quando vengono usate con un numero molto grande di file descriptor, non hanno
 buone prestazioni.
 
-Tuttavia con l'implementazione classica dei segnali questa modalità di I/O
-presenta notevoli problemi, dato che non è possibile determinare, quando i
-file descriptor sono più di uno, qual è quello responsabile dell'emissione del
+Tuttavia con l'implementazione classica dei segnali questa modalità di I/O
+presenta notevoli problemi, dato che non è possibile determinare, quando i
+file descriptor sono più di uno, qual è quello responsabile dell'emissione del
 segnale. Inoltre dato che i segnali normali non si accodano (si ricordi quanto
-illustrato in sez.~\ref{sec:sig_notification}), in presenza di più file
-descriptor attivi contemporaneamente, più segnali emessi nello stesso momento
+illustrato in sez.~\ref{sec:sig_notification}), in presenza di più file
+descriptor attivi contemporaneamente, più segnali emessi nello stesso momento
 verrebbero notificati una volta sola.
 
-Linux però supporta le estensioni POSIX.1b dei segnali real-time, che vengono
+Linux però supporta le estensioni POSIX.1b dei segnali real-time, che vengono
 accodati e che permettono di riconoscere il file descriptor che li ha emessi.
-In questo caso infatti si può fare ricorso alle informazioni aggiuntive
+In questo caso infatti si può fare ricorso alle informazioni aggiuntive
 restituite attraverso la struttura \struct{siginfo\_t}, utilizzando la forma
 estesa \var{sa\_sigaction} del gestore installata con il flag
 \const{SA\_SIGINFO} (si riveda quanto illustrato in
 sez.~\ref{sec:sig_sigaction}).
 
-Per far questo però occorre utilizzare le funzionalità dei segnali real-time
+Per far questo però occorre utilizzare le funzionalità dei segnali real-time
 (vedi sez.~\ref{sec:sig_real_time}) impostando esplicitamente con il comando
 \const{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di
-I/O asincrono (il segnale predefinito è \const{SIGIO}). In questo caso il
-gestore, tutte le volte che riceverà \const{SI\_SIGIO} come valore del campo
+I/O asincrono (il segnale predefinito è \const{SIGIO}). In questo caso il
+gestore, tutte le volte che riceverà \const{SI\_SIGIO} come valore del campo
 \var{si\_code}\footnote{il valore resta \const{SI\_SIGIO} qualunque sia il
-  segnale che si è associato all'I/O, ed indica appunto che il segnale è stato
-  generato a causa di attività di I/O.} di \struct{siginfo\_t}, troverà nel
+  segnale che si è associato all'I/O, ed indica appunto che il segnale è stato
+  generato a causa di attività di I/O.} di \struct{siginfo\_t}, troverà nel
 campo \var{si\_fd} il valore del file descriptor che ha generato il segnale.
 
-Un secondo vantaggio dell'uso dei segnali real-time è che essendo questi
-ultimi dotati di una coda di consegna ogni segnale sarà associato ad uno solo
-file descriptor; inoltre sarà possibile stabilire delle priorità nella
+Un secondo vantaggio dell'uso dei segnali real-time è che essendo questi
+ultimi dotati di una coda di consegna ogni segnale sarà associato ad uno solo
+file descriptor; inoltre sarà possibile stabilire delle priorità nella
 risposta a seconda del segnale usato, dato che i segnali real-time supportano
-anche questa funzionalità. In questo modo si può identificare immediatamente
-un file su cui l'accesso è diventato possibile evitando completamente l'uso di
+anche questa funzionalità. In questo modo si può identificare immediatamente
+un file su cui l'accesso è diventato possibile evitando completamente l'uso di
 funzioni come \func{poll} e \func{select}, almeno fintanto che non si satura
 la coda.
 
 Se infatti si eccedono le dimensioni di quest'ultima, il kernel, non potendo
-più assicurare il comportamento corretto per un segnale real-time, invierà al
+più assicurare il comportamento corretto per un segnale real-time, invierà al
 suo posto un solo \const{SIGIO}, su cui si saranno accumulati tutti i segnali
-in eccesso, e si dovrà allora determinare con un ciclo quali sono i file
-diventati attivi. L'unico modo per essere sicuri che questo non avvenga è di
+in eccesso, e si dovrà allora determinare con un ciclo quali sono i file
+diventati attivi. L'unico modo per essere sicuri che questo non avvenga è di
 impostare la lunghezza della coda dei segnali real-time ad una dimensione
 identica al valore massimo del numero di file descriptor
 utilizzabili.\footnote{vale a dire impostare il contenuto di
@@ -2294,79 +2295,79 @@ utilizzabili.\footnote{vale a dire impostare il contenuto di
 \subsection{I meccanismi di notifica asincrona.}
 \label{sec:file_asyncronous_lease}
 
-Una delle domande più frequenti nella programmazione in ambiente unix-like è
+Una delle domande più frequenti nella programmazione in ambiente unix-like è
 quella di come fare a sapere quando un file viene modificato. La
 risposta\footnote{o meglio la non risposta, tanto che questa nelle Unix FAQ
   \cite{UnixFAQ} viene anche chiamata una \textit{Frequently Unanswered
-    Question}.} è che nell'architettura classica di Unix questo non è
+    Question}.} è che nell'architettura classica di Unix questo non è
 possibile. Al contrario di altri sistemi operativi infatti un kernel unix-like
 classico non prevedeva alcun meccanismo per cui un processo possa essere
-\textsl{notificato} di eventuali modifiche avvenute su un file. Questo è il
+\textsl{notificato} di eventuali modifiche avvenute su un file. Questo è il
 motivo per cui i demoni devono essere \textsl{avvisati} in qualche
 modo\footnote{in genere questo vien fatto inviandogli un segnale di
   \const{SIGHUP} che, per una convenzione adottata dalla gran parte di detti
   programmi, causa la rilettura della configurazione.} se il loro file di
-configurazione è stato modificato, perché possano rileggerlo e riconoscere le
+configurazione è stato modificato, perché possano rileggerlo e riconoscere le
 modifiche.
 
-Questa scelta è stata fatta perché provvedere un simile meccanismo a livello
-generico per qualunque file comporterebbe un notevole aumento di complessità
+Questa scelta è stata fatta perché provvedere un simile meccanismo a livello
+generico per qualunque file comporterebbe un notevole aumento di complessità
 dell'architettura della gestione dei file, il tutto per fornire una
-funzionalità che serve soltanto in alcuni casi particolari. Dato che
+funzionalità che serve soltanto in alcuni casi particolari. Dato che
 all'origine di Unix i soli programmi che potevano avere una tale esigenza
 erano i demoni, attenendosi a uno dei criteri base della progettazione, che
 era di far fare al kernel solo le operazioni strettamente necessarie e
 lasciare tutto il resto a processi in user space, non era stata prevista
-nessuna funzionalità di notifica.
+nessuna funzionalità di notifica.
 
-Visto però il crescente interesse nei confronti di una funzionalità di questo
-tipo, che è molto richiesta specialmente nello sviluppo dei programmi ad
+Visto però il crescente interesse nei confronti di una funzionalità di questo
+tipo, che è molto richiesta specialmente nello sviluppo dei programmi ad
 interfaccia grafica, quando si deve presentare all'utente lo stato del
 filesystem, sono state successivamente introdotte delle estensioni che
-permettessero la creazione di meccanismi di notifica più efficienti dell'unica
-soluzione disponibile con l'interfaccia tradizionale, che è quella del
+permettessero la creazione di meccanismi di notifica più efficienti dell'unica
+soluzione disponibile con l'interfaccia tradizionale, che è quella del
 \itindex{polling} \textit{polling}.
 
-Queste nuove funzionalità sono delle estensioni specifiche, non
+Queste nuove funzionalità sono delle estensioni specifiche, non
 standardizzate, che sono disponibili soltanto su Linux (anche se altri kernel
 supportano meccanismi simili). Alcune di esse sono realizzate, e solo a
 partire dalla versione 2.4 del kernel, attraverso l'uso di alcuni
 \textsl{comandi} aggiuntivi per la funzione \func{fcntl} (vedi
-sez.~\ref{sec:file_fcntl}), che divengono disponibili soltanto se si è
+sez.~\ref{sec:file_fcntl}), che divengono disponibili soltanto se si è
 definita la macro \macro{\_GNU\_SOURCE} prima di includere \file{fcntl.h}.
 
 \index{file!lease|(} 
 
-La prima di queste funzionalità è quella del cosiddetto \textit{file lease};
-questo è un meccanismo che consente ad un processo, detto \textit{lease
+La prima di queste funzionalità è quella del cosiddetto \textit{file lease};
+questo è un meccanismo che consente ad un processo, detto \textit{lease
   holder}, di essere notificato quando un altro processo, chiamato a sua volta
 \textit{lease breaker}, cerca di eseguire una \func{open} o una
 \func{truncate} sul file del quale l'\textit{holder} detiene il
 \textit{lease}.
 La notifica avviene in maniera analoga a come illustrato in precedenza per
 l'uso di \const{O\_ASYNC}: di default viene inviato al \textit{lease holder}
-il segnale \const{SIGIO}, ma questo segnale può essere modificato usando il
+il segnale \const{SIGIO}, ma questo segnale può essere modificato usando il
 comando \const{F\_SETSIG} di \func{fcntl}.\footnote{anche in questo caso si
-  può rispecificare lo stesso \const{SIGIO}.} Se si è fatto questo\footnote{è
-  in genere è opportuno farlo, come in precedenza, per utilizzare segnali
-  real-time.} e si è installato il gestore del segnale con \const{SA\_SIGINFO}
-si riceverà nel campo \var{si\_fd} della struttura \struct{siginfo\_t} il
-valore del file descriptor del file sul quale è stato compiuto l'accesso; in
-questo modo un processo può mantenere anche più di un \textit{file lease}.
+  può rispecificare lo stesso \const{SIGIO}.} Se si è fatto questo\footnote{è
+  in genere è opportuno farlo, come in precedenza, per utilizzare segnali
+  real-time.} e si è installato il gestore del segnale con \const{SA\_SIGINFO}
+si riceverà nel campo \var{si\_fd} della struttura \struct{siginfo\_t} il
+valore del file descriptor del file sul quale è stato compiuto l'accesso; in
+questo modo un processo può mantenere anche più di un \textit{file lease}.
 
 Esistono due tipi di \textit{file lease}: di lettura (\textit{read lease}) e
 di scrittura (\textit{write lease}). Nel primo caso la notifica avviene quando
 un altro processo esegue l'apertura del file in scrittura o usa
 \func{truncate} per troncarlo. Nel secondo caso la notifica avviene anche se
-il file viene aperto in lettura; in quest'ultimo caso però il \textit{lease}
-può essere ottenuto solo se nessun altro processo ha aperto lo stesso file.
+il file viene aperto in lettura; in quest'ultimo caso però il \textit{lease}
+può essere ottenuto solo se nessun altro processo ha aperto lo stesso file.
 
 Come accennato in sez.~\ref{sec:file_fcntl} il comando di \func{fcntl} che
-consente di acquisire un \textit{file lease} è \const{F\_SETLEASE}, che viene
+consente di acquisire un \textit{file lease} è \const{F\_SETLEASE}, che viene
 utilizzato anche per rilasciarlo. In tal caso il file descriptor \param{fd}
-passato a \func{fcntl} servirà come riferimento per il file su cui si vuole
+passato a \func{fcntl} servirà come riferimento per il file su cui si vuole
 operare, mentre per indicare il tipo di operazione (acquisizione o rilascio)
-occorrerà specificare come valore dell'argomento \param{arg} di \func{fcntl}
+occorrerà specificare come valore dell'argomento \param{arg} di \func{fcntl}
 uno dei tre valori di tab.~\ref{tab:file_lease_fctnl}.
 
 \begin{table}[htb]
@@ -2389,29 +2390,29 @@ uno dei tre valori di tab.~\ref{tab:file_lease_fctnl}.
 \end{table}
 
 Se invece si vuole conoscere lo stato di eventuali \textit{file lease}
-occorrerà chiamare \func{fcntl} sul relativo file descriptor \param{fd} con il
-comando \const{F\_GETLEASE}, e si otterrà indietro nell'argomento \param{arg}
+occorrerà chiamare \func{fcntl} sul relativo file descriptor \param{fd} con il
+comando \const{F\_GETLEASE}, e si otterrà indietro nell'argomento \param{arg}
 uno dei valori di tab.~\ref{tab:file_lease_fctnl}, che indicheranno la
 presenza del rispettivo tipo di \textit{lease}, o, nel caso di
 \const{F\_UNLCK}, l'assenza di qualunque \textit{file lease}.
 
-Si tenga presente che un processo può mantenere solo un tipo di \textit{lease}
-su un file, e che un \textit{lease} può essere ottenuto solo su file di dati
+Si tenga presente che un processo può mantenere solo un tipo di \textit{lease}
+su un file, e che un \textit{lease} può essere ottenuto solo su file di dati
 (pipe e dispositivi sono quindi esclusi). Inoltre un processo non privilegiato
-può ottenere un \textit{lease} soltanto per un file appartenente ad un
+può ottenere un \textit{lease} soltanto per un file appartenente ad un
 \acr{uid} corrispondente a quello del processo. Soltanto un processo con
-privilegi di amministratore (cioè con la \itindex{capabilities} capability
-\const{CAP\_LEASE}, vedi sez.~\ref{sec:proc_capabilities}) può acquisire
+privilegi di amministratore (cioè con la \itindex{capabilities} capability
+\const{CAP\_LEASE}, vedi sez.~\ref{sec:proc_capabilities}) può acquisire
 \textit{lease} su qualunque file.
 
-Se su un file è presente un \textit{lease} quando il \textit{lease breaker}
+Se su un file è presente un \textit{lease} quando il \textit{lease breaker}
 esegue una \func{truncate} o una \func{open} che confligge con
-esso,\footnote{in realtà \func{truncate} confligge sempre, mentre \func{open},
+esso,\footnote{in realtà \func{truncate} confligge sempre, mentre \func{open},
   se eseguita in sola lettura, non confligge se si tratta di un \textit{read
     lease}.} la funzione si blocca\footnote{a meno di non avere aperto il file
   con \const{O\_NONBLOCK}, nel qual caso \func{open} fallirebbe con un errore
   di \errcode{EWOULDBLOCK}.} e viene eseguita la notifica al \textit{lease
-  holder}, così che questo possa completare le sue operazioni sul file e
+  holder}, così che questo possa completare le sue operazioni sul file e
 rilasciare il \textit{lease}.  In sostanza con un \textit{read lease} si
 rilevano i tentativi di accedere al file per modificarne i dati da parte di un
 altro processo, mentre con un \textit{write lease} si rilevano anche i
@@ -2424,7 +2425,7 @@ assicurare la consistenza di un file, a seconda dei due casi, prima che un
 altro processo inizi con le sue operazioni di scrittura o di lettura su di
 esso. In genere un \textit{lease holder} che riceve una notifica deve
 provvedere a completare le necessarie operazioni (ad esempio scaricare
-eventuali buffer), per poi rilasciare il \textit{lease} così che il
+eventuali buffer), per poi rilasciare il \textit{lease} così che il
 \textit{lease breaker} possa eseguire le sue operazioni. Questo si fa con il
 comando \const{F\_SETLEASE}, o rimuovendo il \textit{lease} con
 \const{F\_UNLCK}, o, nel caso di \textit{write lease} che confligge con una
@@ -2433,38 +2434,38 @@ operazione di lettura, declassando il \textit{lease} a lettura con
 
 Se il \textit{lease holder} non provvede a rilasciare il \textit{lease} entro
 il numero di secondi specificato dal parametro di sistema mantenuto in
-\procfile{/proc/sys/fs/lease-break-time} sarà il kernel stesso a rimuoverlo (o
-declassarlo) automaticamente.\footnote{questa è una misura di sicurezza per
+\procfile{/proc/sys/fs/lease-break-time} sarà il kernel stesso a rimuoverlo (o
+declassarlo) automaticamente.\footnote{questa è una misura di sicurezza per
   evitare che un processo blocchi indefinitamente l'accesso ad un file
-  acquisendo un \textit{lease}.} Una volta che un \textit{lease} è stato
+  acquisendo un \textit{lease}.} Una volta che un \textit{lease} è stato
 rilasciato o declassato (che questo sia fatto dal \textit{lease holder} o dal
-kernel è lo stesso) le chiamate a \func{open} o \func{truncate} eseguite dal
+kernel è lo stesso) le chiamate a \func{open} o \func{truncate} eseguite dal
 \textit{lease breaker} rimaste bloccate proseguono automaticamente.
 
-Benché possa risultare utile per sincronizzare l'accesso ad uno stesso file da
-parte di più processi, l'uso dei \textit{file lease} non consente comunque di
+Benché possa risultare utile per sincronizzare l'accesso ad uno stesso file da
+parte di più processi, l'uso dei \textit{file lease} non consente comunque di
 risolvere il problema di rilevare automaticamente quando un file o una
-directory vengono modificati,\footnote{questa funzionalità venne aggiunta
+directory vengono modificati,\footnote{questa funzionalità venne aggiunta
   principalmente ad uso di Samba per poter facilitare l'emulazione del
   comportamento di Windows sui file, ma ad oggi viene considerata una
-  interfaccia mal progettata ed il suo uso è fortemente sconsigliato a favore
-  di \textit{inotify}.} che è quanto necessario ad esempio ai programma di
+  interfaccia mal progettata ed il suo uso è fortemente sconsigliato a favore
+  di \textit{inotify}.} che è quanto necessario ad esempio ai programma di
 gestione dei file dei vari desktop grafici.
 
 \itindbeg{dnotify}
 
-Per risolvere questo problema a partire dal kernel 2.4 è stata allora creata
-un'altra interfaccia,\footnote{si ricordi che anche questa è una interfaccia
+Per risolvere questo problema a partire dal kernel 2.4 è stata allora creata
+un'altra interfaccia,\footnote{si ricordi che anche questa è una interfaccia
   specifica di Linux che deve essere evitata se si vogliono scrivere programmi
-  portabili, e che le funzionalità illustrate sono disponibili soltanto se è
+  portabili, e che le funzionalità illustrate sono disponibili soltanto se è
   stata definita la macro \macro{\_GNU\_SOURCE}.} chiamata \textit{dnotify},
 che consente di richiedere una notifica quando una directory, o uno qualunque
 dei file in essa contenuti, viene modificato.  Come per i \textit{file lease}
 la notifica avviene di default attraverso il segnale \const{SIGIO}, ma se ne
-può utilizzare un altro.\footnote{e di nuovo, per le ragioni già esposte in
-  precedenza, è opportuno che si utilizzino dei segnali real-time.} Inoltre,
-come in precedenza, si potrà ottenere nel gestore del segnale il file
-descriptor che è stato modificato tramite il contenuto della struttura
+può utilizzare un altro.\footnote{e di nuovo, per le ragioni già esposte in
+  precedenza, è opportuno che si utilizzino dei segnali real-time.} Inoltre,
+come in precedenza, si potrà ottenere nel gestore del segnale il file
+descriptor che è stato modificato tramite il contenuto della struttura
 \struct{siginfo\_t}.
 
 \index{file!lease|)}
@@ -2477,22 +2478,22 @@ descriptor che 
     \textbf{Valore}  & \textbf{Significato} \\
     \hline
     \hline
-    \const{DN\_ACCESS} & Un file è stato acceduto, con l'esecuzione di una fra
+    \const{DN\_ACCESS} & Un file è stato acceduto, con l'esecuzione di una fra
                          \func{read}, \func{pread}, \func{readv}.\\ 
-    \const{DN\_MODIFY} & Un file è stato modificato, con l'esecuzione di una
+    \const{DN\_MODIFY} & Un file è stato modificato, con l'esecuzione di una
                          fra \func{write}, \func{pwrite}, \func{writev}, 
                          \func{truncate}, \func{ftruncate}.\\ 
-    \const{DN\_CREATE} & È stato creato un file nella directory, con
+    \const{DN\_CREATE} & È stato creato un file nella directory, con
                          l'esecuzione di una fra \func{open}, \func{creat},
                          \func{mknod}, \func{mkdir}, \func{link},
                          \func{symlink}, \func{rename} (da un'altra
                          directory).\\
-    \const{DN\_DELETE} & È stato cancellato un file dalla directory con
+    \const{DN\_DELETE} & È stato cancellato un file dalla directory con
                          l'esecuzione di una fra \func{unlink}, \func{rename}
                          (su un'altra directory), \func{rmdir}.\\
-    \const{DN\_RENAME} & È stato rinominato un file all'interno della
+    \const{DN\_RENAME} & È stato rinominato un file all'interno della
                          directory (con \func{rename}).\\
-    \const{DN\_ATTRIB} & È stato modificato un attributo di un file con
+    \const{DN\_ATTRIB} & È stato modificato un attributo di un file con
                          l'esecuzione di una fra \func{chown}, \func{chmod},
                          \func{utime}.\\ 
     \const{DN\_MULTISHOT}& Richiede una notifica permanente di tutti gli
@@ -2504,70 +2505,70 @@ descriptor che 
   \label{tab:file_notify}
 \end{table}
 
-Ci si può registrare per le notifiche dei cambiamenti al contenuto di una
+Ci si può registrare per le notifiche dei cambiamenti al contenuto di una
 certa directory eseguendo la funzione \func{fcntl} su un file descriptor
 associato alla stessa con il comando \const{F\_NOTIFY}. In questo caso
 l'argomento \param{arg} di \func{fcntl} serve ad indicare per quali classi
 eventi si vuole ricevere la notifica, e prende come valore una maschera
-binaria composta dall'OR aritmetico di una o più delle costanti riportate in
+binaria composta dall'OR aritmetico di una o più delle costanti riportate in
 tab.~\ref{tab:file_notify}.
 
 A meno di non impostare in maniera esplicita una notifica permanente usando il
-valore \const{DN\_MULTISHOT}, la notifica è singola: viene cioè inviata una
-sola volta quando si verifica uno qualunque fra gli eventi per i quali la si è
+valore \const{DN\_MULTISHOT}, la notifica è singola: viene cioè inviata una
+sola volta quando si verifica uno qualunque fra gli eventi per i quali la si è
 richiesta. Questo significa che un programma deve registrarsi un'altra volta
 se desidera essere notificato di ulteriori cambiamenti. Se si eseguono diverse
 chiamate con \const{F\_NOTIFY} e con valori diversi per \param{arg} questi
-ultimi si \textsl{accumulano}; cioè eventuali nuovi classi di eventi
-specificate in chiamate successive vengono aggiunte a quelle già impostate
+ultimi si \textsl{accumulano}; cioè eventuali nuovi classi di eventi
+specificate in chiamate successive vengono aggiunte a quelle già impostate
 nelle precedenti.  Se si vuole rimuovere la notifica si deve invece
 specificare un valore nullo.
 
 \itindbeg{inotify}
 
-Il maggiore problema di \textit{dnotify} è quello della scalabilità: si deve
+Il maggiore problema di \textit{dnotify} è quello della scalabilità: si deve
 usare un file descriptor per ciascuna directory che si vuole tenere sotto
 controllo, il che porta facilmente ad avere un eccesso di file aperti. Inoltre
-quando la directory che si controlla è all'interno di un dispositivo
+quando la directory che si controlla è all'interno di un dispositivo
 rimovibile, mantenere il relativo file descriptor aperto comporta
-l'impossibilità di smontare il dispositivo e di rimuoverlo, il che in genere
+l'impossibilità di smontare il dispositivo e di rimuoverlo, il che in genere
 complica notevolmente la gestione dell'uso di questi dispositivi.
 
-Un altro problema è che l'interfaccia di \textit{dnotify} consente solo di
+Un altro problema è che l'interfaccia di \textit{dnotify} consente solo di
 tenere sotto controllo il contenuto di una directory; la modifica di un file
-viene segnalata, ma poi è necessario verificare di quale file si tratta
-(operazione che può essere molto onerosa quando una directory contiene un gran
+viene segnalata, ma poi è necessario verificare di quale file si tratta
+(operazione che può essere molto onerosa quando una directory contiene un gran
 numero di file).  Infine l'uso dei segnali come interfaccia di notifica
 comporta tutti i problemi di gestione visti in sez.~\ref{sec:sig_management} e
 sez.~\ref{sec:sig_adv_control}.  Per tutta questa serie di motivi in generale
-quella di \textit{dnotify} viene considerata una interfaccia di usabilità
-problematica ed il suo uso oggi è fortemente sconsigliato.
+quella di \textit{dnotify} viene considerata una interfaccia di usabilità
+problematica ed il suo uso oggi è fortemente sconsigliato.
 
 \itindend{dnotify}
 
-Per risolvere i problemi appena illustrati è stata introdotta una nuova
+Per risolvere i problemi appena illustrati è stata introdotta una nuova
 interfaccia per l'osservazione delle modifiche a file o directory, chiamata
-\textit{inotify}.\footnote{l'interfaccia è disponibile a partire dal kernel
+\textit{inotify}.\footnote{l'interfaccia è disponibile a partire dal kernel
   2.6.13, le relative funzioni sono state introdotte nelle glibc 2.4.}  Anche
-questa è una interfaccia specifica di Linux (pertanto non deve essere usata se
-si devono scrivere programmi portabili), ed è basata sull'uso di una coda di
+questa è una interfaccia specifica di Linux (pertanto non deve essere usata se
+si devono scrivere programmi portabili), ed è basata sull'uso di una coda di
 notifica degli eventi associata ad un singolo file descriptor, il che permette
 di risolvere il principale problema di \itindex{dnotify} \textit{dnotify}.  La
 coda viene creata attraverso la funzione \funcd{inotify\_init}, il cui
-prototipo è:
+prototipo è:
 \begin{prototype}{sys/inotify.h}
   {int inotify\_init(void)}
   
   Inizializza una istanza di \textit{inotify}.
   
   \bodydesc{La funzione restituisce un file descriptor in caso di successo, o
-    $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+    $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EMFILE}] si è raggiunto il numero massimo di istanze di
+  \item[\errcode{EMFILE}] si è raggiunto il numero massimo di istanze di
     \textit{inotify} consentite all'utente.
-  \item[\errcode{ENFILE}] si è raggiunto il massimo di file descriptor aperti
+  \item[\errcode{ENFILE}] si è raggiunto il massimo di file descriptor aperti
     nel sistema.
-  \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel per creare
+  \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel per creare
     l'istanza.
   \end{errlist}
 }
@@ -2576,53 +2577,53 @@ prototipo 
 La funzione non prende alcun argomento; inizializza una istanza di
 \textit{inotify} e restituisce un file descriptor attraverso il quale verranno
 effettuate le operazioni di notifica;\footnote{per evitare abusi delle risorse
-  di sistema è previsto che un utente possa utilizzare un numero limitato di
-  istanze di \textit{inotify}; il valore di default del limite è di 128, ma
-  questo valore può essere cambiato con \func{sysctl} o usando il file
+  di sistema è previsto che un utente possa utilizzare un numero limitato di
+  istanze di \textit{inotify}; il valore di default del limite è di 128, ma
+  questo valore può essere cambiato con \func{sysctl} o usando il file
   \procfile{/proc/sys/fs/inotify/max\_user\_instances}.} si tratta di un file
-descriptor speciale che non è associato a nessun file su disco, e che viene
+descriptor speciale che non è associato a nessun file su disco, e che viene
 utilizzato solo per notificare gli eventi che sono stati posti in
-osservazione. Dato che questo file descriptor non è associato a nessun file o
+osservazione. Dato che questo file descriptor non è associato a nessun file o
 directory reale, l'inconveniente di non poter smontare un filesystem i cui
 file sono tenuti sotto osservazione viene completamente
-eliminato.\footnote{anzi, una delle capacità dell'interfaccia di
-  \textit{inotify} è proprio quella di notificare il fatto che il filesystem
-  su cui si trova il file o la directory osservata è stato smontato.}
+eliminato.\footnote{anzi, una delle capacità dell'interfaccia di
+  \textit{inotify} è proprio quella di notificare il fatto che il filesystem
+  su cui si trova il file o la directory osservata è stato smontato.}
 
-Inoltre trattandosi di un file descriptor a tutti gli effetti, esso potrà
+Inoltre trattandosi di un file descriptor a tutti gli effetti, esso potrà
 essere utilizzato come argomento per le funzioni \func{select} e \func{poll} e
-con l'interfaccia di \textit{epoll};\footnote{ed a partire dal kernel 2.6.25 è
+con l'interfaccia di \textit{epoll};\footnote{ed a partire dal kernel 2.6.25 è
   stato introdotto anche il supporto per il \itindex{signal~driven~I/O}
   \texttt{signal-driven I/O} trattato in
   sez.~\ref{sec:file_asyncronous_operation}.} siccome gli eventi vengono
 notificati come dati disponibili in lettura, dette funzioni ritorneranno tutte
-le volte che si avrà un evento di notifica. Così, invece di dover utilizzare i
+le volte che si avrà un evento di notifica. Così, invece di dover utilizzare i
 segnali,\footnote{considerati una pessima scelta dal punto di vista
-  dell'interfaccia utente.} si potrà gestire l'osservazione degli eventi con
-una qualunque delle modalità di \textit{I/O multiplexing} illustrate in
+  dell'interfaccia utente.} si potrà gestire l'osservazione degli eventi con
+una qualunque delle modalità di \textit{I/O multiplexing} illustrate in
 sez.~\ref{sec:file_multiplexing}. Qualora si voglia cessare l'osservazione,
-sarà sufficiente chiudere il file descriptor e tutte le risorse allocate
+sarà sufficiente chiudere il file descriptor e tutte le risorse allocate
 saranno automaticamente rilasciate.
 
 Infine l'interfaccia di \textit{inotify} consente di mettere sotto
 osservazione, oltre che una directory, anche singoli file.  Una volta creata
 la coda di notifica si devono definire gli eventi da tenere sotto
 osservazione; questo viene fatto attraverso una \textsl{lista di osservazione}
-(o \textit{watch list}) che è associata alla coda. Per gestire la lista di
-osservazione l'interfaccia fornisce due funzioni, la prima di queste è
-\funcd{inotify\_add\_watch}, il cui prototipo è:
+(o \textit{watch list}) che è associata alla coda. Per gestire la lista di
+osservazione l'interfaccia fornisce due funzioni, la prima di queste è
+\funcd{inotify\_add\_watch}, il cui prototipo è:
 \begin{prototype}{sys/inotify.h}
   {int inotify\_add\_watch(int fd, const char *pathname, uint32\_t mask)}
 
   Aggiunge un evento di osservazione alla lista di osservazione di \param{fd}.
 
   \bodydesc{La funzione restituisce un valore positivo in caso di successo, o
-    $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+    $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
   \item[\errcode{EACCESS}] non si ha accesso in lettura al file indicato.
   \item[\errcode{EINVAL}] \param{mask} non contiene eventi legali o \param{fd}
-    non è un file descriptor di \textit{inotify}.
-  \item[\errcode{ENOSPC}] si è raggiunto il numero massimo di voci di
+    non è un file descriptor di \textit{inotify}.
+  \item[\errcode{ENOSPC}] si è raggiunto il numero massimo di voci di
     osservazione o il kernel non ha potuto allocare una risorsa necessaria.
   \end{errlist}
   ed inoltre \errval{EFAULT}, \errval{ENOMEM} e \errval{EBADF}.}
@@ -2631,16 +2632,16 @@ osservazione l'interfaccia fornisce due funzioni, la prima di queste 
 La funzione consente di creare un ``\textsl{osservatore}'' (il cosiddetto
 ``\textit{watch}'') nella lista di osservazione di una coda di notifica, che
 deve essere indicata specificando il file descriptor ad essa associato
-nell'argomento \param{fd}.\footnote{questo ovviamente dovrà essere un file
+nell'argomento \param{fd}.\footnote{questo ovviamente dovrà essere un file
   descriptor creato con \func{inotify\_init}.}  Il file o la directory da
 porre sotto osservazione vengono invece indicati per nome, da passare
 nell'argomento \param{pathname}.  Infine il terzo argomento, \param{mask},
 indica che tipo di eventi devono essere tenuti sotto osservazione e le
-modalità della stessa.  L'operazione può essere ripetuta per tutti i file e le
+modalità della stessa.  L'operazione può essere ripetuta per tutti i file e le
 directory che si vogliono tenere sotto osservazione,\footnote{anche in questo
-  caso c'è un limite massimo che di default è pari a 8192, ed anche questo
-  valore può essere cambiato con \func{sysctl} o usando il file
-  \procfile{/proc/sys/fs/inotify/max\_user\_watches}.} e si utilizzerà sempre
+  caso c'è un limite massimo che di default è pari a 8192, ed anche questo
+  valore può essere cambiato con \func{sysctl} o usando il file
+  \procfile{/proc/sys/fs/inotify/max\_user\_watches}.} e si utilizzerà sempre
 un solo file descriptor.
 
 Il tipo di evento che si vuole osservare deve essere specificato
@@ -2660,32 +2661,32 @@ flag della prima parte.
     \textbf{Valore}  & & \textbf{Significato} \\
     \hline
     \hline
-    \const{IN\_ACCESS}        &$\bullet$& C'è stato accesso al file in
+    \const{IN\_ACCESS}        &$\bullet$& C'è stato accesso al file in
                                           lettura.\\  
     \const{IN\_ATTRIB}        &$\bullet$& Ci sono stati cambiamenti sui dati
                                           dell'inode (o sugli attributi
                                           estesi, vedi
                                           sez.~\ref{sec:file_xattr}).\\ 
-    \const{IN\_CLOSE\_WRITE}  &$\bullet$& È stato chiuso un file aperto in
+    \const{IN\_CLOSE\_WRITE}  &$\bullet$& È stato chiuso un file aperto in
                                           scrittura.\\  
-    \const{IN\_CLOSE\_NOWRITE}&$\bullet$& È stato chiuso un file aperto in
+    \const{IN\_CLOSE\_NOWRITE}&$\bullet$& È stato chiuso un file aperto in
                                           sola lettura.\\
-    \const{IN\_CREATE}        &$\bullet$& È stato creato un file o una
+    \const{IN\_CREATE}        &$\bullet$& È stato creato un file o una
                                           directory in una directory sotto
                                           osservazione.\\  
-    \const{IN\_DELETE}        &$\bullet$& È stato cancellato un file o una
+    \const{IN\_DELETE}        &$\bullet$& È stato cancellato un file o una
                                           directory in una directory sotto
                                           osservazione.\\ 
-    \const{IN\_DELETE\_SELF}  & --      & È stato cancellato il file (o la
+    \const{IN\_DELETE\_SELF}  & --      & È stato cancellato il file (o la
                                           directory) sotto osservazione.\\ 
-    \const{IN\_MODIFY}        &$\bullet$& È stato modificato il file.\\ 
-    \const{IN\_MOVE\_SELF}    &         & È stato rinominato il file (o la
+    \const{IN\_MODIFY}        &$\bullet$& È stato modificato il file.\\ 
+    \const{IN\_MOVE\_SELF}    &         & È stato rinominato il file (o la
                                           directory) sotto osservazione.\\ 
-    \const{IN\_MOVED\_FROM}   &$\bullet$& Un file è stato spostato fuori dalla
+    \const{IN\_MOVED\_FROM}   &$\bullet$& Un file è stato spostato fuori dalla
                                           directory sotto osservazione.\\ 
-    \const{IN\_MOVED\_TO}     &$\bullet$& Un file è stato spostato nella
+    \const{IN\_MOVED\_TO}     &$\bullet$& Un file è stato spostato nella
                                           directory sotto osservazione.\\ 
-    \const{IN\_OPEN}          &$\bullet$& Un file è stato aperto.\\ 
+    \const{IN\_OPEN}          &$\bullet$& Un file è stato aperto.\\ 
     \hline    
     \const{IN\_CLOSE}         &         & Combinazione di
                                           \const{IN\_CLOSE\_WRITE} e
@@ -2708,8 +2709,8 @@ evento da osservare e che vengono utilizzati anche in uscita per indicare il
 tipo di evento avvenuto, \func{inotify\_add\_watch} supporta ulteriori
 flag,\footnote{i flag \const{IN\_DONT\_FOLLOW}, \const{IN\_MASK\_ADD} e
   \const{IN\_ONLYDIR} sono stati introdotti a partire dalle glibc 2.5, se si
-  usa la versione 2.4 è necessario definirli a mano.}  riportati in
-tab.~\ref{tab:inotify_add_watch_flag}, che indicano le modalità di
+  usa la versione 2.4 è necessario definirli a mano.}  riportati in
+tab.~\ref{tab:inotify_add_watch_flag}, che indicano le modalità di
 osservazione (da passare sempre nell'argomento \param{mask}) e che al
 contrario dei precedenti non vengono mai impostati nei risultati in uscita.
 
@@ -2721,47 +2722,47 @@ contrario dei precedenti non vengono mai impostati nei risultati in uscita.
     \textbf{Valore}  & \textbf{Significato} \\
     \hline
     \hline
-    \const{IN\_DONT\_FOLLOW}& Non dereferenzia \param{pathname} se questo è un
+    \const{IN\_DONT\_FOLLOW}& Non dereferenzia \param{pathname} se questo è un
                               link simbolico.\\
-    \const{IN\_MASK\_ADD}   & Aggiunge a quelli già impostati i flag indicati
+    \const{IN\_MASK\_ADD}   & Aggiunge a quelli già impostati i flag indicati
                               nell'argomento \param{mask}, invece di
                               sovrascriverli.\\
     \const{IN\_ONESHOT}     & Esegue l'osservazione su \param{pathname} per una
                               sola volta, rimuovendolo poi dalla \textit{watch
                                 list}.\\ 
-    \const{IN\_ONLYDIR}     & Se \param{pathname} è una directory riporta
+    \const{IN\_ONLYDIR}     & Se \param{pathname} è una directory riporta
                               soltanto gli eventi ad essa relativi e non
                               quelli per i file che contiene.\\ 
     \hline    
   \end{tabular}
   \caption{Le costanti che identificano i bit della maschera binaria
     dell'argomento \param{mask} di \func{inotify\_add\_watch} che indicano le
-    modalità di osservazione.} 
+    modalità di osservazione.} 
   \label{tab:inotify_add_watch_flag}
 \end{table}
 
 Se non esiste nessun \textit{watch} per il file o la directory specificata
-questo verrà creato per gli eventi specificati dall'argomento \param{mask},
-altrimenti la funzione sovrascriverà le impostazioni precedenti, a meno che
+questo verrà creato per gli eventi specificati dall'argomento \param{mask},
+altrimenti la funzione sovrascriverà le impostazioni precedenti, a meno che
 non si sia usato il flag \const{IN\_MASK\_ADD}, nel qual caso gli eventi
-specificati saranno aggiunti a quelli già presenti.
+specificati saranno aggiunti a quelli già presenti.
 
 Come accennato quando si tiene sotto osservazione una directory vengono
 restituite le informazioni sia riguardo alla directory stessa che ai file che
-essa contiene; questo comportamento può essere disabilitato utilizzando il
+essa contiene; questo comportamento può essere disabilitato utilizzando il
 flag \const{IN\_ONLYDIR}, che richiede di riportare soltanto gli eventi
 relativi alla directory stessa. Si tenga presente inoltre che quando si
 osserva una directory vengono riportati solo gli eventi sui file che essa
 contiene direttamente, non quelli relativi a file contenuti in eventuali
-sottodirectory; se si vogliono osservare anche questi sarà necessario creare
+sottodirectory; se si vogliono osservare anche questi sarà necessario creare
 ulteriori \textit{watch} per ciascuna sottodirectory.
 
-Infine usando il flag \const{IN\_ONESHOT} è possibile richiedere una notifica
-singola;\footnote{questa funzionalità però è disponibile soltanto a partire dal
+Infine usando il flag \const{IN\_ONESHOT} è possibile richiedere una notifica
+singola;\footnote{questa funzionalità però è disponibile soltanto a partire dal
   kernel 2.6.16.} una volta verificatosi uno qualunque fra gli eventi
-richiesti con \func{inotify\_add\_watch} l'\textsl{osservatore} verrà
+richiesti con \func{inotify\_add\_watch} l'\textsl{osservatore} verrà
 automaticamente rimosso dalla lista di osservazione e nessun ulteriore evento
-sarà più notificato.
+sarà più notificato.
 
 In caso di successo \func{inotify\_add\_watch} ritorna un intero positivo,
 detto \textit{watch descriptor}, che identifica univocamente un
@@ -2770,20 +2771,20 @@ riferimento sia riguardo i risultati restituiti da \textit{inotify}, che per
 la eventuale rimozione dello stesso. 
 
 La seconda funzione per la gestione delle code di notifica, che permette di
-rimuovere un \textsl{osservatore}, è \funcd{inotify\_rm\_watch}, ed il suo
-prototipo è:
+rimuovere un \textsl{osservatore}, è \funcd{inotify\_rm\_watch}, ed il suo
+prototipo è:
 \begin{prototype}{sys/inotify.h}
   {int inotify\_rm\_watch(int fd, uint32\_t wd)}
 
   Rimuove un \textsl{osservatore} da una coda di notifica.
   
   \bodydesc{La funzione restituisce 0 in caso di successo, o $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EBADF}] non si è specificato in \param{fd} un file descriptor
+  \item[\errcode{EBADF}] non si è specificato in \param{fd} un file descriptor
     valido.
-  \item[\errcode{EINVAL}] il valore di \param{wd} non è corretto, o \param{fd}
-    non è associato ad una coda di notifica.
+  \item[\errcode{EINVAL}] il valore di \param{wd} non è corretto, o \param{fd}
+    non è associato ad una coda di notifica.
   \end{errlist}
 }
 \end{prototype}
@@ -2791,23 +2792,23 @@ prototipo 
 La funzione rimuove dalla coda di notifica identificata dall'argomento
 \param{fd} l'osservatore identificato dal \textit{watch descriptor}
 \param{wd};\footnote{ovviamente deve essere usato per questo argomento un
-  valore ritornato da \func{inotify\_add\_watch}, altrimenti si avrà un errore
+  valore ritornato da \func{inotify\_add\_watch}, altrimenti si avrà un errore
   di \errval{EINVAL}.} in caso di successo della rimozione, contemporaneamente
-alla cancellazione dell'osservatore, sulla coda di notifica verrà generato un
+alla cancellazione dell'osservatore, sulla coda di notifica verrà generato un
 evento di tipo \const{IN\_IGNORED} (vedi
 tab.~\ref{tab:inotify_read_event_flag}). Si tenga presente che se un file
 viene cancellato o un filesystem viene smontato i relativi osservatori vengono
-rimossi automaticamente e non è necessario utilizzare
+rimossi automaticamente e non è necessario utilizzare
 \func{inotify\_rm\_watch}.
 
 Come accennato l'interfaccia di \textit{inotify} prevede che gli eventi siano
 notificati come dati presenti in lettura sul file descriptor associato alla
-coda di notifica. Una applicazione pertanto dovrà leggere i dati da detto file
-con una \func{read}, che ritornerà sul buffer i dati presenti nella forma di
-una o più strutture di tipo \struct{inotify\_event} (la cui definizione è
+coda di notifica. Una applicazione pertanto dovrà leggere i dati da detto file
+con una \func{read}, che ritornerà sul buffer i dati presenti nella forma di
+una o più strutture di tipo \struct{inotify\_event} (la cui definizione è
 riportata in fig.~\ref{fig:inotify_event}). Qualora non siano presenti dati la
-\func{read} si bloccherà (a meno di non aver impostato il file descriptor in
-modalità non bloccante) fino all'arrivo di almeno un evento.
+\func{read} si bloccherà (a meno di non aver impostato il file descriptor in
+modalità non bloccante) fino all'arrivo di almeno un evento.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -2820,22 +2821,22 @@ modalit
   \label{fig:inotify_event}
 \end{figure}
 
-Una ulteriore caratteristica dell'interfaccia di \textit{inotify} è che essa
+Una ulteriore caratteristica dell'interfaccia di \textit{inotify} è che essa
 permette di ottenere con \func{ioctl}, come per i file descriptor associati ai
 socket (si veda sez.~\ref{sec:sock_ioctl_IP}) il numero di byte disponibili in
 lettura sul file descriptor, utilizzando su di esso l'operazione
-\const{FIONREAD}.\footnote{questa è una delle operazioni speciali per i file
-  (vedi sez.~\ref{sec:file_ioctl}), che è disponibile solo per i socket e per
-  i file descriptor creati con \func{inotify\_init}.} Si può così utilizzare
+\const{FIONREAD}.\footnote{questa è una delle operazioni speciali per i file
+  (vedi sez.~\ref{sec:file_ioctl}), che è disponibile solo per i socket e per
+  i file descriptor creati con \func{inotify\_init}.} Si può così utilizzare
 questa operazione, oltre che per predisporre una operazione di lettura con un
 buffer di dimensioni adeguate, anche per ottenere rapidamente il numero di
 file che sono cambiati.
 
-Una volta effettuata la lettura con \func{read} a ciascun evento sarà
+Una volta effettuata la lettura con \func{read} a ciascun evento sarà
 associata una struttura \struct{inotify\_event} contenente i rispettivi dati.
 Per identificare a quale file o directory l'evento corrisponde viene
 restituito nel campo \var{wd} il \textit{watch descriptor} con cui il relativo
-osservatore è stato registrato. Il campo \var{mask} contiene invece una
+osservatore è stato registrato. Il campo \var{mask} contiene invece una
 maschera di bit che identifica il tipo di evento verificatosi; in essa
 compariranno sia i bit elencati nella prima parte di
 tab.~\ref{tab:inotify_event_watch}, che gli eventuali valori
@@ -2851,21 +2852,21 @@ aggiuntivi\footnote{questi compaiono solo nel campo \var{mask} di
     \textbf{Valore}  & \textbf{Significato} \\
     \hline
     \hline
-    \const{IN\_IGNORED}    & L'osservatore è stato rimosso, sia in maniera 
+    \const{IN\_IGNORED}    & L'osservatore è stato rimosso, sia in maniera 
                              esplicita con l'uso di \func{inotify\_rm\_watch}, 
                              che in maniera implicita per la rimozione 
                              dell'oggetto osservato o per lo smontaggio del
                              filesystem su cui questo si trova.\\
     \const{IN\_ISDIR}      & L'evento avvenuto fa riferimento ad una directory
-                             (consente così di distinguere, quando si pone
+                             (consente così di distinguere, quando si pone
                              sotto osservazione una directory, fra gli eventi
                              relativi ad essa e quelli relativi ai file che
                              essa contiene).\\
     \const{IN\_Q\_OVERFLOW}& Si sono eccedute le dimensioni della coda degli
                              eventi (\textit{overflow} della coda); in questo
-                             caso il valore di \var{wd} è $-1$.\footnotemark\\
+                             caso il valore di \var{wd} è $-1$.\footnotemark\\
     \const{IN\_UNMOUNT}    & Il filesystem contenente l'oggetto posto sotto
-                             osservazione è stato smontato.\\
+                             osservazione è stato smontato.\\
     \hline    
   \end{tabular}
   \caption{Le costanti che identificano i bit aggiuntivi usati nella maschera
@@ -2881,17 +2882,17 @@ aggiuntivi\footnote{questi compaiono solo nel campo \var{mask} di
   \const{IN\_Q\_OVERFLOW}.}
 
 Il campo \var{cookie} contiene invece un intero univoco che permette di
-identificare eventi correlati (per i quali avrà lo stesso valore), al momento
+identificare eventi correlati (per i quali avrà lo stesso valore), al momento
 viene utilizzato soltanto per rilevare lo spostamento di un file, consentendo
-così all'applicazione di collegare la corrispondente coppia di eventi
+così all'applicazione di collegare la corrispondente coppia di eventi
 \const{IN\_MOVED\_TO} e \const{IN\_MOVED\_FROM}.
 
 Infine due campi \var{name} e \var{len} sono utilizzati soltanto quando
-l'evento è relativo ad un file presente in una directory posta sotto
+l'evento è relativo ad un file presente in una directory posta sotto
 osservazione, in tal caso essi contengono rispettivamente il nome del file
 (come pathname relativo alla directory osservata) e la relativa dimensione in
 byte. Il campo \var{name} viene sempre restituito come stringa terminata da
-NUL, con uno o più zeri di terminazione, a seconda di eventuali necessità di
+NUL, con uno o più zeri di terminazione, a seconda di eventuali necessità di
 allineamento del risultato, ed il valore di \var{len} corrisponde al totale
 della dimensione di \var{name}, zeri aggiuntivi compresi. La stringa con il
 nome del file viene restituita nella lettura subito dopo la struttura
@@ -2900,11 +2901,11 @@ di \textit{inotify} saranno pari a \code{sizeof(\struct{inotify\_event}) +
   len}.
 
 Vediamo allora un esempio dell'uso dell'interfaccia di \textit{inotify} con un
-semplice programma che permette di mettere sotto osservazione uno o più file e
+semplice programma che permette di mettere sotto osservazione uno o più file e
 directory. Il programma si chiama \texttt{inotify\_monitor.c} ed il codice
-completo è disponibile coi sorgenti allegati alla guida, il corpo principale
+completo è disponibile coi sorgenti allegati alla guida, il corpo principale
 del programma, che non contiene la sezione di gestione delle opzioni e le
-funzioni di ausilio è riportato in fig.~\ref{fig:inotify_monitor_example}.
+funzioni di ausilio è riportato in fig.~\ref{fig:inotify_monitor_example}.
 
 \begin{figure}[!htbp]
   \footnotesize \centering
@@ -2924,11 +2925,11 @@ passa (\texttt{\small 16--20}) all'inizializzazione di \textit{inotify}
 ottenendo con \func{inotify\_init} il relativo file descriptor (oppure usce in
 caso di errore).
 
-Il passo successivo è aggiungere (\texttt{\small 21--30}) alla coda di
+Il passo successivo è aggiungere (\texttt{\small 21--30}) alla coda di
 notifica gli opportuni osservatori per ciascuno dei file o directory indicati
 all'invocazione del comando; questo viene fatto eseguendo un ciclo
 (\texttt{\small 22--29}) fintanto che la variabile \var{i}, inizializzata a
-zero (\texttt{\small 21}) all'inizio del ciclo, è minore del numero totale di
+zero (\texttt{\small 21}) all'inizio del ciclo, è minore del numero totale di
 argomenti rimasti. All'interno del ciclo si invoca (\texttt{\small 23})
 \func{inotify\_add\_watch} per ciascuno degli argomenti, usando la maschera
 degli eventi data dalla variabile \var{mask} (il cui valore viene impostato
@@ -2938,21 +2939,21 @@ altrimenti si incrementa l'indice (\texttt{\small 29}).
 Completa l'inizializzazione di \textit{inotify} inizia il ciclo principale
 (\texttt{\small 32--56}) del programma, nel quale si resta in attesa degli
 eventi che si intendono osservare. Questo viene fatto eseguendo all'inizio del
-ciclo (\texttt{\small 33}) una \func{read} che si bloccherà fintanto che non
+ciclo (\texttt{\small 33}) una \func{read} che si bloccherà fintanto che non
 si saranno verificati eventi. 
 
-Dato che l'interfaccia di \textit{inotify} può riportare anche più eventi in
-una sola lettura, si è avuto cura di passare alla \func{read} un buffer di
+Dato che l'interfaccia di \textit{inotify} può riportare anche più eventi in
+una sola lettura, si è avuto cura di passare alla \func{read} un buffer di
 dimensioni adeguate, inizializzato in (\texttt{\small 7}) ad un valore di
-approssimativamente 512 eventi.\footnote{si ricordi che la quantità di dati
-  restituita da \textit{inotify} è variabile a causa della diversa lunghezza
+approssimativamente 512 eventi.\footnote{si ricordi che la quantità di dati
+  restituita da \textit{inotify} è variabile a causa della diversa lunghezza
   del nome del file restituito insieme a \struct{inotify\_event}.} In caso di
 errore di lettura (\texttt{\small 35--40}) il programma esce con un messaggio
 di errore (\texttt{\small 37--39}), a meno che non si tratti di una
 interruzione della system call, nel qual caso (\texttt{\small 36}) si ripete la
 lettura.
 
-Se la lettura è andata a buon fine invece si esegue un ciclo (\texttt{\small
+Se la lettura è andata a buon fine invece si esegue un ciclo (\texttt{\small
   43--52}) per leggere tutti gli eventi restituiti, al solito si inizializza
 l'indice \var{i} a zero (\texttt{\small 42}) e si ripetono le operazioni
 (\texttt{\small 43}) fintanto che esso non supera il numero di byte restituiti
@@ -2970,8 +2971,8 @@ si stampa (\texttt{\small 47--49}); si noti come in questo caso si sia
 utilizzato il valore del campo \var{event->len} e non al fatto che
 \var{event->name} riporti o meno un puntatore nullo.\footnote{l'interfaccia
   infatti, qualora il nome non sia presente, non avvalora il campo
-  \var{event->name}, che si troverà a contenere quello che era precedentemente
-  presente nella rispettiva locazione di memoria, nel caso più comune il
+  \var{event->name}, che si troverà a contenere quello che era precedentemente
+  presente nella rispettiva locazione di memoria, nel caso più comune il
   puntatore al nome di un file osservato in precedenza.} Si utilizza poi
 (\texttt{\small 50}) la funzione \code{printevent}, che interpreta il valore
 del campo \var{event->mask} per stampare il tipo di eventi
@@ -2993,35 +2994,35 @@ Observed event on /home/piccardi/gapil/
 IN_CLOSE_NOWRITE, 
 \end{verbatim}
 
-I lettori più accorti si saranno resi conto che nel ciclo di lettura degli
+I lettori più accorti si saranno resi conto che nel ciclo di lettura degli
 eventi appena illustrato non viene trattato il caso particolare in cui la
-funzione \func{read} restituisce in \var{nread} un valore nullo. Lo si è fatto
-perché con \textit{inotify} il ritorno di una \func{read} con un valore nullo
+funzione \func{read} restituisce in \var{nread} un valore nullo. Lo si è fatto
+perché con \textit{inotify} il ritorno di una \func{read} con un valore nullo
 avviene soltanto, come forma di avviso, quando si sia eseguita la funzione
 specificando un buffer di dimensione insufficiente a contenere anche un solo
 evento. Nel nostro caso le dimensioni erano senz'altro sufficienti, per cui
-tale evenienza non si verificherà mai.
+tale evenienza non si verificherà mai.
 
-Ci si potrà però chiedere cosa succede se il buffer è sufficiente per un
-evento, ma non per tutti gli eventi verificatisi. Come si potrà notare nel
-codice illustrato in precedenza non si è presa nessuna precauzione per
+Ci si potrà però chiedere cosa succede se il buffer è sufficiente per un
+evento, ma non per tutti gli eventi verificatisi. Come si potrà notare nel
+codice illustrato in precedenza non si è presa nessuna precauzione per
 verificare che non ci fossero stati troncamenti dei dati. Anche in questo caso
-il comportamento scelto è corretto, perché l'interfaccia di \textit{inotify}
+il comportamento scelto è corretto, perché l'interfaccia di \textit{inotify}
 garantisce automaticamente, anche quando ne sono presenti in numero maggiore,
 di restituire soltanto il numero di eventi che possono rientrare completamente
-nelle dimensioni del buffer specificato.\footnote{si avrà cioè, facendo
+nelle dimensioni del buffer specificato.\footnote{si avrà cioè, facendo
   riferimento sempre al codice di fig.~\ref{fig:inotify_monitor_example}, che
-  \var{read} sarà in genere minore delle dimensioni di \var{buffer} ed uguale
+  \var{read} sarà in genere minore delle dimensioni di \var{buffer} ed uguale
   soltanto qualora gli eventi corrispondano esattamente alle dimensioni di
-  quest'ultimo.} Se gli eventi sono di più saranno restituiti solo quelli che
+  quest'ultimo.} Se gli eventi sono di più saranno restituiti solo quelli che
 entrano interamente nel buffer e gli altri saranno restituiti alla successiva
 chiamata di \func{read}.
 
-Infine un'ultima caratteristica dell'interfaccia di \textit{inotify} è che gli
-eventi restituiti nella lettura formano una sequenza ordinata, è cioè
+Infine un'ultima caratteristica dell'interfaccia di \textit{inotify} è che gli
+eventi restituiti nella lettura formano una sequenza ordinata, è cioè
 garantito che se si esegue uno spostamento di un file gli eventi vengano
 generati nella sequenza corretta. L'interfaccia garantisce anche che se si
-verificano più eventi consecutivi identici (vale a dire con gli stessi valori
+verificano più eventi consecutivi identici (vale a dire con gli stessi valori
 dei campi \var{wd}, \var{mask}, \var{cookie}, e \var{name}) questi vengono
 raggruppati in un solo evento.
 
@@ -3034,40 +3035,40 @@ raggruppati in un solo evento.
 \subsection{L'interfaccia POSIX per l'I/O asincrono}
 \label{sec:file_asyncronous_io}
 
-Una modalità alternativa all'uso dell'\textit{I/O multiplexing} per gestione
-dell'I/O simultaneo su molti file è costituita dal cosiddetto \textsl{I/O
-  asincrono}. Il concetto base dell'\textsl{I/O asincrono} è che le funzioni
+Una modalità alternativa all'uso dell'\textit{I/O multiplexing} per gestione
+dell'I/O simultaneo su molti file è costituita dal cosiddetto \textsl{I/O
+  asincrono}. Il concetto base dell'\textsl{I/O asincrono} è che le funzioni
 di I/O non attendono il completamento delle operazioni prima di ritornare,
-così che il processo non viene bloccato.  In questo modo diventa ad esempio
+così che il processo non viene bloccato.  In questo modo diventa ad esempio
 possibile effettuare una richiesta preventiva di dati, in modo da poter
 effettuare in contemporanea le operazioni di calcolo e quelle di I/O.
 
-Benché la modalità di apertura asincrona di un file possa risultare utile in
+Benché la modalità di apertura asincrona di un file possa risultare utile in
 varie occasioni (in particolar modo con i socket e gli altri file per i quali
-le funzioni di I/O sono \index{system~call~lente} system call lente), essa è
-comunque limitata alla notifica della disponibilità del file descriptor per le
+le funzioni di I/O sono \index{system~call~lente} system call lente), essa è
+comunque limitata alla notifica della disponibilità del file descriptor per le
 operazioni di I/O, e non ad uno svolgimento asincrono delle medesime.  Lo
 standard POSIX.1b definisce una interfaccia apposita per l'I/O asincrono vero
 e proprio, che prevede un insieme di funzioni dedicate per la lettura e la
 scrittura dei file, completamente separate rispetto a quelle usate
 normalmente.
 
-In generale questa interfaccia è completamente astratta e può essere
+In generale questa interfaccia è completamente astratta e può essere
 implementata sia direttamente nel kernel, che in user space attraverso l'uso
 di \itindex{thread} \textit{thread}. Per le versioni del kernel meno recenti
 esiste una implementazione di questa interfaccia fornita delle \acr{glibc},
-che è realizzata completamente in user space, ed è accessibile linkando i
-programmi con la libreria \file{librt}. Nelle versioni più recenti (a partire
-dalla 2.5.32) è stato introdotto direttamente nel kernel un nuovo layer per
+che è realizzata completamente in user space, ed è accessibile linkando i
+programmi con la libreria \file{librt}. Nelle versioni più recenti (a partire
+dalla 2.5.32) è stato introdotto direttamente nel kernel un nuovo layer per
 l'I/O asincrono.
 
 Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate
 attraverso l'uso di una apposita struttura \struct{aiocb} (il cui nome sta per
 \textit{asyncronous I/O control block}), che viene passata come argomento a
 tutte le funzioni dell'interfaccia. La sua definizione, come effettuata in
-\file{aio.h}, è riportata in fig.~\ref{fig:file_aiocb}. Nello steso file è
+\file{aio.h}, è riportata in fig.~\ref{fig:file_aiocb}. Nello steso file è
 definita la macro \macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la
-disponibilità dell'interfaccia per l'I/O asincrono.
+disponibilità dell'interfaccia per l'I/O asincrono.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -3080,36 +3081,36 @@ disponibilit
   \label{fig:file_aiocb}
 \end{figure}
 
-Le operazioni di I/O asincrono possono essere effettuate solo su un file già
+Le operazioni di I/O asincrono possono essere effettuate solo su un file già
 aperto; il file deve inoltre supportare la funzione \func{lseek}, pertanto
-terminali e pipe sono esclusi. Non c'è limite al numero di operazioni
+terminali e pipe sono esclusi. Non c'è limite al numero di operazioni
 contemporanee effettuabili su un singolo file.  Ogni operazione deve
 inizializzare opportunamente un \textit{control block}.  Il file descriptor su
 cui operare deve essere specificato tramite il campo \var{aio\_fildes}; dato
-che più operazioni possono essere eseguita in maniera asincrona, il concetto
+che più operazioni possono essere eseguita in maniera asincrona, il concetto
 di posizione corrente sul file viene a mancare; pertanto si deve sempre
 specificare nel campo \var{aio\_offset} la posizione sul file da cui i dati
 saranno letti o scritti.  Nel campo \var{aio\_buf} deve essere specificato
 l'indirizzo del buffer usato per l'I/O, ed in \var{aio\_nbytes} la lunghezza
 del blocco di dati da trasferire.
 
-Il campo \var{aio\_reqprio} permette di impostare la priorità delle operazioni
-di I/O.\footnote{in generale perché ciò sia possibile occorre che la
+Il campo \var{aio\_reqprio} permette di impostare la priorità delle operazioni
+di I/O.\footnote{in generale perché ciò sia possibile occorre che la
   piattaforma supporti questa caratteristica, questo viene indicato definendo
   le macro \macro{\_POSIX\_PRIORITIZED\_IO}, e
-  \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene impostata a
+  \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene impostata a
 partire da quella del processo chiamante (vedi sez.~\ref{sec:proc_priority}),
 cui viene sottratto il valore di questo campo.  Il campo
-\var{aio\_lio\_opcode} è usato solo dalla funzione \func{lio\_listio}, che,
+\var{aio\_lio\_opcode} è usato solo dalla funzione \func{lio\_listio}, che,
 come vedremo, permette di eseguire con una sola chiamata una serie di
 operazioni, usando un vettore di \textit{control block}. Tramite questo campo
-si specifica quale è la natura di ciascuna di esse.
+si specifica quale è la natura di ciascuna di esse.
 
-Infine il campo \var{aio\_sigevent} è una struttura di tipo \struct{sigevent}
+Infine il campo \var{aio\_sigevent} è una struttura di tipo \struct{sigevent}
 (illustrata in in fig.~\ref{fig:struct_sigevent}) che serve a specificare il
 modo in cui si vuole che venga effettuata la notifica del completamento delle
-operazioni richieste; per la trattazione delle modalità di utilizzo della
-stessa si veda quanto già visto in proposito in sez.~\ref{sec:sig_timer_adv}.
+operazioni richieste; per la trattazione delle modalità di utilizzo della
+stessa si veda quanto già visto in proposito in sez.~\ref{sec:sig_timer_adv}.
 
 Le due funzioni base dell'interfaccia per l'I/O asincrono sono
 \funcd{aio\_read} ed \funcd{aio\_write}.  Esse permettono di richiedere una
@@ -3126,19 +3127,19 @@ appena descritta; i rispettivi prototipi sono:
   \param{aiocbp}.
   
   \bodydesc{Le funzioni restituiscono 0 in caso di successo, e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato.
-  \item[\errcode{ENOSYS}] la funzione non è implementata.
-  \item[\errcode{EINVAL}] si è specificato un valore non valido per i campi
+  \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato.
+  \item[\errcode{ENOSYS}] la funzione non è implementata.
+  \item[\errcode{EINVAL}] si è specificato un valore non valido per i campi
     \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}.
-  \item[\errcode{EAGAIN}] la coda delle richieste è momentaneamente piena.
+  \item[\errcode{EAGAIN}] la coda delle richieste è momentaneamente piena.
   \end{errlist}
 }
 \end{functions}
 
 Entrambe le funzioni ritornano immediatamente dopo aver messo in coda la
-richiesta, o in caso di errore. Non è detto che gli errori \errcode{EBADF} ed
+richiesta, o in caso di errore. Non è detto che gli errori \errcode{EBADF} ed
 \errcode{EINVAL} siano rilevati immediatamente al momento della chiamata,
 potrebbero anche emergere nelle fasi successive delle operazioni. Lettura e
 scrittura avvengono alla posizione indicata da \var{aio\_offset}, a meno che
@@ -3148,20 +3149,20 @@ comunque alla fine de file, nell'ordine delle chiamate a \func{aio\_write}.
 
 Si tenga inoltre presente che deallocare la memoria indirizzata da
 \param{aiocbp} o modificarne i valori prima della conclusione di una
-operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
-campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
+operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
+campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
 richiesta.  Questo comporta che non si devono usare per \param{aiocbp}
 variabili automatiche e che non si deve riutilizzare la stessa struttura per
 un'altra operazione fintanto che la precedente non sia stata ultimata. In
 generale per ogni operazione si deve utilizzare una diversa struttura
 \struct{aiocb}.
 
-Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
+Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
 \func{aio\_write} non implica che le operazioni siano state effettivamente
 eseguite in maniera corretta; per verificarne l'esito l'interfaccia prevede
 altre due funzioni, che permettono di controllare lo stato di esecuzione. La
-prima è \funcd{aio\_error}, che serve a determinare un eventuale stato di
-errore; il suo prototipo è:
+prima è \funcd{aio\_error}, che serve a determinare un eventuale stato di
+errore; il suo prototipo è:
 \begin{prototype}{aio.h}
   {int aio\_error(const struct aiocb *aiocbp)}  
 
@@ -3173,21 +3174,21 @@ errore; il suo prototipo 
     fallimento.}
 \end{prototype}
 
-Se l'operazione non si è ancora completata viene restituito l'errore di
-\errcode{EINPROGRESS}. La funzione ritorna zero quando l'operazione si è
+Se l'operazione non si è ancora completata viene restituito l'errore di
+\errcode{EINPROGRESS}. La funzione ritorna zero quando l'operazione si è
 conclusa con successo, altrimenti restituisce il codice dell'errore
 verificatosi, ed esegue la corrispondente impostazione di \var{errno}. Il
-codice può essere sia \errcode{EINVAL} ed \errcode{EBADF}, dovuti ad un valore
+codice può essere sia \errcode{EINVAL} ed \errcode{EBADF}, dovuti ad un valore
 errato per \param{aiocbp}, che uno degli errori possibili durante l'esecuzione
 dell'operazione di I/O richiesta, nel qual caso saranno restituiti, a seconda
 del caso, i codici di errore delle system call \func{read}, \func{write} e
 \func{fsync}.
 
-Una volta che si sia certi che le operazioni siano state concluse (cioè dopo
+Una volta che si sia certi che le operazioni siano state concluse (cioè dopo
 che una chiamata ad \func{aio\_error} non ha restituito
-\errcode{EINPROGRESS}), si potrà usare la funzione \funcd{aio\_return}, che
+\errcode{EINPROGRESS}), si potrà usare la funzione \funcd{aio\_return}, che
 permette di verificare il completamento delle operazioni di I/O asincrono; il
-suo prototipo è:
+suo prototipo è:
 \begin{prototype}{aio.h}
 {ssize\_t aio\_return(const struct aiocb *aiocbp)} 
 
@@ -3199,14 +3200,14 @@ Recupera il valore dello stato di ritorno delle operazioni di I/O associate a
 \end{prototype}
 
 La funzione deve essere chiamata una sola volte per ciascuna operazione
-asincrona, essa infatti fa sì che il sistema rilasci le risorse ad essa
-associate. É per questo motivo che occorre chiamare la funzione solo dopo che
-l'operazione cui \param{aiocbp} fa riferimento si è completata. Una chiamata
+asincrona, essa infatti fa sì che il sistema rilasci le risorse ad essa
+associate. É per questo motivo che occorre chiamare la funzione solo dopo che
+l'operazione cui \param{aiocbp} fa riferimento si è completata. Una chiamata
 precedente il completamento delle operazioni darebbe risultati indeterminati.
 
 La funzione restituisce il valore di ritorno relativo all'operazione eseguita,
-così come ricavato dalla sottostante system call (il numero di byte letti,
-scritti o il valore di ritorno di \func{fsync}).  É importante chiamare sempre
+così come ricavato dalla sottostante system call (il numero di byte letti,
+scritti o il valore di ritorno di \func{fsync}).  É importante chiamare sempre
 questa funzione, altrimenti le risorse disponibili per le operazioni di I/O
 asincrono non verrebbero liberate, rischiando di arrivare ad un loro
 esaurimento.
@@ -3215,37 +3216,37 @@ Oltre alle operazioni di lettura e scrittura l'interfaccia POSIX.1b mette a
 disposizione un'altra operazione, quella di sincronizzazione dell'I/O,
 compiuta dalla funzione \funcd{aio\_fsync}, che ha lo stesso effetto della
 analoga \func{fsync}, ma viene eseguita in maniera asincrona; il suo prototipo
-è:
+è:
 \begin{prototype}{aio.h}
 {int aio\_fsync(int op, struct aiocb *aiocbp)} 
 
 Richiede la sincronizzazione dei dati per il file indicato da \param{aiocbp}.
   
 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-  errore, che può essere, con le stesse modalità di \func{aio\_read},
+  errore, che può essere, con le stesse modalità di \func{aio\_read},
   \errval{EAGAIN}, \errval{EBADF} o \errval{EINVAL}.}
 \end{prototype}
 
 La funzione richiede la sincronizzazione delle operazioni di I/O, ritornando
-immediatamente. L'esecuzione effettiva della sincronizzazione dovrà essere
+immediatamente. L'esecuzione effettiva della sincronizzazione dovrà essere
 verificata con \func{aio\_error} e \func{aio\_return} come per le operazioni
 di lettura e scrittura. L'argomento \param{op} permette di indicare la
-modalità di esecuzione, se si specifica il valore \const{O\_DSYNC} le
+modalità di esecuzione, se si specifica il valore \const{O\_DSYNC} le
 operazioni saranno completate con una chiamata a \func{fdatasync}, se si
 specifica \const{O\_SYNC} con una chiamata a \func{fsync} (per i dettagli vedi
 sez.~\ref{sec:file_sync}).
 
 Il successo della chiamata assicura la sincronizzazione delle operazioni fino
-allora richieste, niente è garantito riguardo la sincronizzazione dei dati
-relativi ad eventuali operazioni richieste successivamente. Se si è
-specificato un meccanismo di notifica questo sarà innescato una volta che le
+allora richieste, niente è garantito riguardo la sincronizzazione dei dati
+relativi ad eventuali operazioni richieste successivamente. Se si è
+specificato un meccanismo di notifica questo sarà innescato una volta che le
 operazioni di sincronizzazione dei dati saranno completate.
 
-In alcuni casi può essere necessario interrompere le operazioni (in genere
+In alcuni casi può essere necessario interrompere le operazioni (in genere
 quando viene richiesta un'uscita immediata dal programma), per questo lo
 standard POSIX.1b prevede una funzione apposita, \funcd{aio\_cancel}, che
 permette di cancellare una operazione richiesta in precedenza; il suo
-prototipo è:
+prototipo è:
 \begin{prototype}{aio.h}
 {int aio\_cancel(int fildes, struct aiocb *aiocbp)} 
 
@@ -3261,15 +3262,15 @@ da \param{aiocbp}.
 La funzione permette di cancellare una operazione specifica sul file
 \param{fildes}, o tutte le operazioni pendenti, specificando \val{NULL} come
 valore di \param{aiocbp}.  Quando una operazione viene cancellata una
-successiva chiamata ad \func{aio\_error} riporterà \errcode{ECANCELED} come
-codice di errore, ed il suo codice di ritorno sarà -1, inoltre il meccanismo
-di notifica non verrà invocato. Se si specifica una operazione relativa ad un
-altro file descriptor il risultato è indeterminato.  In caso di successo, i
+successiva chiamata ad \func{aio\_error} riporterà \errcode{ECANCELED} come
+codice di errore, ed il suo codice di ritorno sarà -1, inoltre il meccanismo
+di notifica non verrà invocato. Se si specifica una operazione relativa ad un
+altro file descriptor il risultato è indeterminato.  In caso di successo, i
 possibili valori di ritorno per \func{aio\_cancel} (anch'essi definiti in
 \file{aio.h}) sono tre:
 \begin{basedescript}{\desclabelwidth{3.0cm}}
-\item[\const{AIO\_ALLDONE}] indica che le operazioni di cui si è richiesta la
-  cancellazione sono state già completate,
+\item[\const{AIO\_ALLDONE}] indica che le operazioni di cui si è richiesta la
+  cancellazione sono state già completate,
   
 \item[\const{AIO\_CANCELED}] indica che tutte le operazioni richieste sono
   state cancellate,  
@@ -3278,16 +3279,16 @@ possibili valori di ritorno per \func{aio\_cancel} (anch'essi definiti in
   corso e non sono state cancellate.
 \end{basedescript}
 
-Nel caso si abbia \const{AIO\_NOTCANCELED} occorrerà chiamare
+Nel caso si abbia \const{AIO\_NOTCANCELED} occorrerà chiamare
 \func{aio\_error} per determinare quali sono le operazioni effettivamente
 cancellate. Le operazioni che non sono state cancellate proseguiranno il loro
 corso normale, compreso quanto richiesto riguardo al meccanismo di notifica
 del loro avvenuto completamento.
 
-Benché l'I/O asincrono preveda un meccanismo di notifica, l'interfaccia
+Benché l'I/O asincrono preveda un meccanismo di notifica, l'interfaccia
 fornisce anche una apposita funzione, \funcd{aio\_suspend}, che permette di
 sospendere l'esecuzione del processo chiamante fino al completamento di una
-specifica operazione; il suo prototipo è:
+specifica operazione; il suo prototipo è:
 \begin{prototype}{aio.h}
 {int aio\_suspend(const struct aiocb * const list[], int nent, const struct
     timespec *timeout)}
@@ -3295,57 +3296,57 @@ specifica operazione; il suo prototipo 
   Attende, per un massimo di \param{timeout}, il completamento di una delle
   operazioni specificate da \param{list}.
   
-  \bodydesc{La funzione restituisce 0 se una (o più) operazioni sono state
-    completate, e -1 in caso di errore nel qual caso \var{errno} assumerà uno
+  \bodydesc{La funzione restituisce 0 se una (o più) operazioni sono state
+    completate, e -1 in caso di errore nel qual caso \var{errno} assumerà uno
     dei valori:
     \begin{errlist}
-    \item[\errcode{EAGAIN}] nessuna operazione è stata completata entro
+    \item[\errcode{EAGAIN}] nessuna operazione è stata completata entro
       \param{timeout}.
-    \item[\errcode{ENOSYS}] la funzione non è implementata.
-    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+    \item[\errcode{ENOSYS}] la funzione non è implementata.
+    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
     \end{errlist}
   }
 \end{prototype}
 
 La funzione permette di bloccare il processo fintanto che almeno una delle
-\param{nent} operazioni specificate nella lista \param{list} è completata, per
+\param{nent} operazioni specificate nella lista \param{list} è completata, per
 un tempo massimo specificato da \param{timout}, o fintanto che non arrivi un
-segnale.\footnote{si tenga conto che questo segnale può anche essere quello
+segnale.\footnote{si tenga conto che questo segnale può anche essere quello
   utilizzato come meccanismo di notifica.} La lista deve essere inizializzata
 con delle strutture \struct{aiocb} relative ad operazioni effettivamente
-richieste, ma può contenere puntatori nulli, che saranno ignorati. In caso si
-siano specificati valori non validi l'effetto è indefinito.  Un valore
+richieste, ma può contenere puntatori nulli, che saranno ignorati. In caso si
+siano specificati valori non validi l'effetto è indefinito.  Un valore
 \val{NULL} per \param{timout} comporta l'assenza di timeout.
 
 Lo standard POSIX.1b infine ha previsto pure una funzione, \funcd{lio\_listio},
 che permette di effettuare la richiesta di una intera lista di operazioni di
-lettura o scrittura; il suo prototipo è:
+lettura o scrittura; il suo prototipo è:
 \begin{prototype}{aio.h}
   {int lio\_listio(int mode, struct aiocb * const list[], int nent, struct
     sigevent *sig)}
   
   Richiede l'esecuzione delle operazioni di I/O elencata da \param{list},
-  secondo la modalità \param{mode}.
+  secondo la modalità \param{mode}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
-    \item[\errcode{EAGAIN}] nessuna operazione è stata completata entro
+    \item[\errcode{EAGAIN}] nessuna operazione è stata completata entro
       \param{timeout}.
-    \item[\errcode{EINVAL}] si è passato un valore di \param{mode} non valido
+    \item[\errcode{EINVAL}] si è passato un valore di \param{mode} non valido
       o un numero di operazioni \param{nent} maggiore di
       \const{AIO\_LISTIO\_MAX}.
-    \item[\errcode{ENOSYS}] la funzione non è implementata.
-    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+    \item[\errcode{ENOSYS}] la funzione non è implementata.
+    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
     \end{errlist}
   }
 \end{prototype}
 
 La funzione esegue la richiesta delle \param{nent} operazioni indicate nella
 lista \param{list} che deve contenere gli indirizzi di altrettanti
-\textit{control block} opportunamente inizializzati; in particolare dovrà
+\textit{control block} opportunamente inizializzati; in particolare dovrà
 essere specificato il tipo di operazione con il campo \var{aio\_lio\_opcode},
-che può prendere i valori:
+che può prendere i valori:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\const{LIO\_READ}]  si richiede una operazione di lettura.
 \item[\const{LIO\_WRITE}] si richiede una operazione di scrittura.
@@ -3360,17 +3361,17 @@ L'argomento \param{mode} controlla il comportamento della funzione, se viene
 usato il valore \const{LIO\_WAIT} la funzione si blocca fino al completamento
 di tutte le operazioni richieste; se si usa \const{LIO\_NOWAIT} la funzione
 ritorna immediatamente dopo aver messo in coda tutte le richieste. In tal caso
-il chiamante può richiedere la notifica del completamento di tutte le
+il chiamante può richiedere la notifica del completamento di tutte le
 richieste, impostando l'argomento \param{sig} in maniera analoga a come si fa
 per il campo \var{aio\_sigevent} di \struct{aiocb}.
 
 
-\section{Altre modalità di I/O avanzato}
+\section{Altre modalità di I/O avanzato}
 \label{sec:file_advanced_io}
 
-Oltre alle precedenti modalità di \textit{I/O multiplexing} e \textsl{I/O
-  asincrono}, esistono altre funzioni che implementano delle modalità di
-accesso ai file più evolute rispetto alle normali funzioni di lettura e
+Oltre alle precedenti modalità di \textit{I/O multiplexing} e \textsl{I/O
+  asincrono}, esistono altre funzioni che implementano delle modalità di
+accesso ai file più evolute rispetto alle normali funzioni di lettura e
 scrittura che abbiamo esaminato in sez.~\ref{sec:file_base_func}. In questa
 sezione allora prenderemo in esame le interfacce per l'\textsl{I/O mappato in
   memoria}, per l'\textsl{I/O vettorizzato} e altre funzioni di I/O avanzato.
@@ -3380,8 +3381,8 @@ sezione allora prenderemo in esame le interfacce per l'\textsl{I/O mappato in
 \label{sec:file_memory_map}
 
 \itindbeg{memory~mapping}
-Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
-rispetto a quella classica vista in cap.~\ref{cha:file_unix_interface}, è il
+Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
+rispetto a quella classica vista in cap.~\ref{cha:file_unix_interface}, è il
 cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della
 \textsl{paginazione} \index{paginazione} usato dalla memoria virtuale (vedi
 sez.~\ref{sec:proc_mem_gen}), permette di \textsl{mappare} il contenuto di un
@@ -3395,43 +3396,43 @@ file in una sezione dello spazio di indirizzi del processo che lo ha allocato.
   \label{fig:file_mmap_layout}
 \end{figure}
 
-Il meccanismo è illustrato in fig.~\ref{fig:file_mmap_layout}, una sezione del
+Il meccanismo è illustrato in fig.~\ref{fig:file_mmap_layout}, una sezione del
 file viene \textsl{mappata} direttamente nello spazio degli indirizzi del
 programma.  Tutte le operazioni di lettura e scrittura su variabili contenute
 in questa zona di memoria verranno eseguite leggendo e scrivendo dal contenuto
 del file attraverso il sistema della memoria virtuale \index{memoria~virtuale}
 che in maniera analoga a quanto avviene per le pagine che vengono salvate e
-rilette nella swap, si incaricherà di sincronizzare il contenuto di quel
+rilette nella swap, si incaricherà di sincronizzare il contenuto di quel
 segmento di memoria con quello del file mappato su di esso.  Per questo motivo
-si può parlare tanto di \textsl{file mappato in memoria}, quanto di
+si può parlare tanto di \textsl{file mappato in memoria}, quanto di
 \textsl{memoria mappata su file}.
 
 L'uso del \textit{memory-mapping} comporta una notevole semplificazione delle
-operazioni di I/O, in quanto non sarà più necessario utilizzare dei buffer
-intermedi su cui appoggiare i dati da traferire, poiché questi potranno essere
+operazioni di I/O, in quanto non sarà più necessario utilizzare dei buffer
+intermedi su cui appoggiare i dati da traferire, poiché questi potranno essere
 acceduti direttamente nella sezione di memoria mappata; inoltre questa
-interfaccia è più efficiente delle usuali funzioni di I/O, in quanto permette
+interfaccia è più efficiente delle usuali funzioni di I/O, in quanto permette
 di caricare in memoria solo le parti del file che sono effettivamente usate ad
 un dato istante.
 
-Infatti, dato che l'accesso è fatto direttamente attraverso la
+Infatti, dato che l'accesso è fatto direttamente attraverso la
 \index{memoria~virtuale} memoria virtuale, la sezione di memoria mappata su
-cui si opera sarà a sua volta letta o scritta sul file una pagina alla volta e
+cui si opera sarà a sua volta letta o scritta sul file una pagina alla volta e
 solo per le parti effettivamente usate, il tutto in maniera completamente
-trasparente al processo; l'accesso alle pagine non ancora caricate avverrà
+trasparente al processo; l'accesso alle pagine non ancora caricate avverrà
 allo stesso modo con cui vengono caricate in memoria le pagine che sono state
 salvate sullo swap.
 
-Infine in situazioni in cui la memoria è scarsa, le pagine che mappano un file
-vengono salvate automaticamente, così come le pagine dei programmi vengono
+Infine in situazioni in cui la memoria è scarsa, le pagine che mappano un file
+vengono salvate automaticamente, così come le pagine dei programmi vengono
 scritte sulla swap; questo consente di accedere ai file su dimensioni il cui
-solo limite è quello dello spazio di indirizzi disponibile, e non della
+solo limite è quello dello spazio di indirizzi disponibile, e non della
 memoria su cui possono esserne lette delle porzioni.
 
 L'interfaccia POSIX implementata da Linux prevede varie funzioni per la
 gestione del \textit{memory mapped I/O}, la prima di queste, che serve ad
-eseguire la mappatura in memoria di un file, è \funcd{mmap}; il suo prototipo
-è:
+eseguire la mappatura in memoria di un file, è \funcd{mmap}; il suo prototipo
+è:
 \begin{functions}
   
   \headdecl{unistd.h}
@@ -3444,31 +3445,31 @@ eseguire la mappatura in memoria di un file, 
   
   \bodydesc{La funzione restituisce il puntatore alla zona di memoria mappata
     in caso di successo, e \const{MAP\_FAILED} (-1) in caso di errore, nel
-    qual caso \var{errno} assumerà uno dei valori:
+    qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
-    \item[\errcode{EBADF}] il file descriptor non è valido, e non si è usato
+    \item[\errcode{EBADF}] il file descriptor non è valido, e non si è usato
       \const{MAP\_ANONYMOUS}.
     \item[\errcode{EACCES}] o \param{fd} non si riferisce ad un file regolare,
-      o si è usato \const{MAP\_PRIVATE} ma \param{fd} non è aperto in lettura,
-      o si è usato \const{MAP\_SHARED} e impostato \const{PROT\_WRITE} ed
-      \param{fd} non è aperto in lettura/scrittura, o si è impostato
-      \const{PROT\_WRITE} ed \param{fd} è in \textit{append-only}.
+      o si è usato \const{MAP\_PRIVATE} ma \param{fd} non è aperto in lettura,
+      o si è usato \const{MAP\_SHARED} e impostato \const{PROT\_WRITE} ed
+      \param{fd} non è aperto in lettura/scrittura, o si è impostato
+      \const{PROT\_WRITE} ed \param{fd} è in \textit{append-only}.
     \item[\errcode{EINVAL}] i valori di \param{start}, \param{length} o
       \param{offset} non sono validi (o troppo grandi o non allineati sulla
       dimensione delle pagine).
-    \item[\errcode{ETXTBSY}] si è impostato \const{MAP\_DENYWRITE} ma
-      \param{fd} è aperto in scrittura.
-    \item[\errcode{EAGAIN}] il file è bloccato, o si è bloccata troppa memoria
+    \item[\errcode{ETXTBSY}] si è impostato \const{MAP\_DENYWRITE} ma
+      \param{fd} è aperto in scrittura.
+    \item[\errcode{EAGAIN}] il file è bloccato, o si è bloccata troppa memoria
       rispetto a quanto consentito dai limiti di sistema (vedi
       sez.~\ref{sec:sys_resource_limit}).
-    \item[\errcode{ENOMEM}] non c'è memoria o si è superato il limite sul
+    \item[\errcode{ENOMEM}] non c'è memoria o si è superato il limite sul
       numero di mappature possibili.
     \item[\errcode{ENODEV}] il filesystem di \param{fd} non supporta il memory
       mapping.
     \item[\errcode{EPERM}] l'argomento \param{prot} ha richiesto
-      \const{PROT\_EXEC}, ma il filesystem di \param{fd} è montato con
+      \const{PROT\_EXEC}, ma il filesystem di \param{fd} è montato con
       l'opzione \texttt{noexec}.
-    \item[\errcode{ENFILE}] si è superato il limite del sistema sul numero di
+    \item[\errcode{ENFILE}] si è superato il limite del sistema sul numero di
       file aperti (vedi sez.~\ref{sec:sys_resource_limit}).
     \end{errlist}
   }
@@ -3490,7 +3491,7 @@ multiplo della dimensione di una pagina di memoria.
     \const{PROT\_EXEC}  & Le pagine possono essere eseguite.\\
     \const{PROT\_READ}  & Le pagine possono essere lette.\\
     \const{PROT\_WRITE} & Le pagine possono essere scritte.\\
-    \const{PROT\_NONE}  & L'accesso alle pagine è vietato.\\
+    \const{PROT\_NONE}  & L'accesso alle pagine è vietato.\\
     \hline    
   \end{tabular}
   \caption{Valori dell'argomento \param{prot} di \func{mmap}, relativi alla
@@ -3499,23 +3500,23 @@ multiplo della dimensione di una pagina di memoria.
 \end{table}
 
 Il valore dell'argomento \param{prot} indica la protezione\footnote{come
-  accennato in sez.~\ref{sec:proc_memory} in Linux la memoria reale è divisa
-  in pagine: ogni processo vede la sua memoria attraverso uno o più segmenti
+  accennato in sez.~\ref{sec:proc_memory} in Linux la memoria reale è divisa
+  in pagine: ogni processo vede la sua memoria attraverso uno o più segmenti
   lineari di memoria virtuale.  Per ciascuno di questi segmenti il kernel
   mantiene nella \itindex{page~table} \textit{page table} la mappatura sulle
-  pagine di memoria reale, ed le modalità di accesso (lettura, esecuzione,
+  pagine di memoria reale, ed le modalità di accesso (lettura, esecuzione,
   scrittura); una loro violazione causa quella una \itindex{segment~violation}
   \textit{segment violation}, e la relativa emissione del segnale
   \const{SIGSEGV}.} da applicare al segmento di memoria e deve essere
-specificato come maschera binaria ottenuta dall'OR di uno o più dei valori
+specificato come maschera binaria ottenuta dall'OR di uno o più dei valori
 riportati in tab.~\ref{tab:file_mmap_prot}; il valore specificato deve essere
-compatibile con la modalità di accesso con cui si è aperto il file.
+compatibile con la modalità di accesso con cui si è aperto il file.
 
-L'argomento \param{flags} specifica infine qual è il tipo di oggetto mappato,
-le opzioni relative alle modalità con cui è effettuata la mappatura e alle
-modalità con cui le modifiche alla memoria mappata vengono condivise o
+L'argomento \param{flags} specifica infine qual è il tipo di oggetto mappato,
+le opzioni relative alle modalità con cui è effettuata la mappatura e alle
+modalità con cui le modifiche alla memoria mappata vengono condivise o
 mantenute private al processo che le ha effettuate. Deve essere specificato
-come maschera binaria ottenuta dall'OR di uno o più dei valori riportati in
+come maschera binaria ottenuta dall'OR di uno o più dei valori riportati in
 tab.~\ref{tab:file_mmap_flag}.
 
 \begin{table}[htb]
@@ -3527,14 +3528,14 @@ tab.~\ref{tab:file_mmap_flag}.
     \hline
     \hline
     \const{MAP\_FIXED}     & Non permette di restituire un indirizzo diverso
-                             da \param{start}, se questo non può essere usato
+                             da \param{start}, se questo non può essere usato
                              \func{mmap} fallisce. Se si imposta questo flag il
                              valore di \param{start} deve essere allineato
                              alle dimensioni di una pagina.\\
     \const{MAP\_SHARED}    & I cambiamenti sulla memoria mappata vengono
                              riportati sul file e saranno immediatamente
                              visibili agli altri processi che mappano lo stesso
-                             file.\footnotemark Il file su disco però non sarà
+                             file.\footnotemark Il file su disco però non sarà
                              aggiornato fino alla chiamata di \func{msync} o
                              \func{munmap}), e solo allora le modifiche saranno
                              visibili per l'I/O convenzionale. Incompatibile
@@ -3545,7 +3546,7 @@ tab.~\ref{tab:file_mmap_flag}.
                              accesso.  Le modifiche sono mantenute attraverso
                              il meccanismo del \textit{copy on
                                write} \itindex{copy~on~write} e 
-                             salvate su swap in caso di necessità. Non è
+                             salvate su swap in caso di necessità. Non è
                              specificato se i cambiamenti sul file originale
                              vengano riportati sulla regione
                              mappata. Incompatibile con \const{MAP\_SHARED}.\\
@@ -3560,7 +3561,7 @@ tab.~\ref{tab:file_mmap_flag}.
                              \textit{copy on write} \itindex{copy~on~write}
                              per mantenere le
                              modifiche fatte alla regione mappata, in
-                             questo caso dopo una scrittura, se non c'è più
+                             questo caso dopo una scrittura, se non c'è più
                              memoria disponibile, si ha l'emissione di
                              un \const{SIGSEGV}.\\
     \const{MAP\_LOCKED}    & Se impostato impedisce lo swapping delle pagine
@@ -3568,20 +3569,20 @@ tab.~\ref{tab:file_mmap_flag}.
     \const{MAP\_GROWSDOWN} & Usato per gli \itindex{stack} \textit{stack}. 
                              Indica che la mappatura deve essere effettuata 
                              con gli indirizzi crescenti verso il basso.\\
-    \const{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
+    \const{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
                              argomenti \param{fd} e \param{offset} sono
                              ignorati.\footnotemark\\
     \const{MAP\_ANON}      & Sinonimo di \const{MAP\_ANONYMOUS}, deprecato.\\
-    \const{MAP\_FILE}      & Valore di compatibilità, ignorato.\\
+    \const{MAP\_FILE}      & Valore di compatibilità, ignorato.\\
     \const{MAP\_32BIT}     & Esegue la mappatura sui primi 2Gb dello spazio
                              degli indirizzi, viene supportato solo sulle
-                             piattaforme \texttt{x86-64} per compatibilità con
-                             le applicazioni a 32 bit. Viene ignorato se si è
+                             piattaforme \texttt{x86-64} per compatibilità con
+                             le applicazioni a 32 bit. Viene ignorato se si è
                              richiesto \const{MAP\_FIXED}.\\
     \const{MAP\_POPULATE}  & Esegue il \itindex{prefaulting}
                              \textit{prefaulting} delle pagine di memoria
                              necessarie alla mappatura.\\
-    \const{MAP\_NONBLOCK}  & Esegue un \textit{prefaulting} più limitato che
+    \const{MAP\_NONBLOCK}  & Esegue un \textit{prefaulting} più limitato che
                              non causa I/O.\footnotemark\\
 %     \const{MAP\_DONTEXPAND}& Non consente una successiva espansione dell'area
 %                              mappata con \func{mremap}, proposto ma pare non
@@ -3595,29 +3596,29 @@ tab.~\ref{tab:file_mmap_flag}.
 \footnotetext[68]{dato che tutti faranno riferimento alle stesse pagine di
   memoria.}  
 
-\footnotetext[69]{l'uso di questo flag con \const{MAP\_SHARED} è stato
+\footnotetext[69]{l'uso di questo flag con \const{MAP\_SHARED} è stato
   implementato in Linux a partire dai kernel della serie 2.4.x; esso consente
   di creare segmenti di memoria condivisa e torneremo sul suo utilizzo in
   sez.~\ref{sec:ipc_mmap_anonymous}.}
 
 \footnotetext{questo flag ed il precedente \const{MAP\_POPULATE} sono stati
   introdotti nel kernel 2.5.46 insieme alla mappatura non lineare di cui
-  parleremo più avanti.}
+  parleremo più avanti.}
 
 Gli effetti dell'accesso ad una zona di memoria mappata su file possono essere
 piuttosto complessi, essi si possono comprendere solo tenendo presente che
-tutto quanto è comunque basato sul meccanismo della \index{memoria~virtuale}
-memoria virtuale. Questo comporta allora una serie di conseguenze. La più
-ovvia è che se si cerca di scrivere su una zona mappata in sola lettura si
-avrà l'emissione di un segnale di violazione di accesso (\const{SIGSEGV}),
+tutto quanto è comunque basato sul meccanismo della \index{memoria~virtuale}
+memoria virtuale. Questo comporta allora una serie di conseguenze. La più
+ovvia è che se si cerca di scrivere su una zona mappata in sola lettura si
+avrà l'emissione di un segnale di violazione di accesso (\const{SIGSEGV}),
 dato che i permessi sul segmento di memoria relativo non consentono questo
 tipo di accesso.
 
-È invece assai diversa la questione relativa agli accessi al di fuori della
-regione di cui si è richiesta la mappatura. A prima vista infatti si potrebbe
+È invece assai diversa la questione relativa agli accessi al di fuori della
+regione di cui si è richiesta la mappatura. A prima vista infatti si potrebbe
 ritenere che anch'essi debbano generare un segnale di violazione di accesso;
-questo però non tiene conto del fatto che, essendo basata sul meccanismo della
-\index{paginazione} paginazione, la mappatura in memoria non può che essere
+questo però non tiene conto del fatto che, essendo basata sul meccanismo della
+\index{paginazione} paginazione, la mappatura in memoria non può che essere
 eseguita su un segmento di dimensioni rigorosamente multiple di quelle di una
 pagina, ed in generale queste potranno non corrispondere alle dimensioni
 effettive del file o della sezione che si vuole mappare.
@@ -3630,38 +3631,38 @@ effettive del file o della sezione che si vuole mappare.
   \label{fig:file_mmap_boundary}
 \end{figure}
 
-Il caso più comune è quello illustrato in fig.~\ref{fig:file_mmap_boundary},
+Il caso più comune è quello illustrato in fig.~\ref{fig:file_mmap_boundary},
 in cui la sezione di file non rientra nei confini di una pagina: in tal caso
-verrà il file sarà mappato su un segmento di memoria che si estende fino al
+verrà il file sarà mappato su un segmento di memoria che si estende fino al
 bordo della pagina successiva.
 
-In questo caso è possibile accedere a quella zona di memoria che eccede le
+In questo caso è possibile accedere a quella zona di memoria che eccede le
 dimensioni specificate da \param{length}, senza ottenere un \const{SIGSEGV}
-poiché essa è presente nello spazio di indirizzi del processo, anche se non è
-mappata sul file. Il comportamento del sistema è quello di restituire un
+poiché essa è presente nello spazio di indirizzi del processo, anche se non è
+mappata sul file. Il comportamento del sistema è quello di restituire un
 valore nullo per quanto viene letto, e di non riportare su file quanto viene
 scritto.
 
-Un caso più complesso è quello che si viene a creare quando le dimensioni del
-file mappato sono più corte delle dimensioni della mappatura, oppure quando il
-file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a
+Un caso più complesso è quello che si viene a creare quando le dimensioni del
+file mappato sono più corte delle dimensioni della mappatura, oppure quando il
+file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a
 quella della mappatura in memoria.
 
 In questa situazione, per la sezione di pagina parzialmente coperta dal
 contenuto del file, vale esattamente quanto visto in precedenza; invece per la
 parte che eccede, fino alle dimensioni date da \param{length}, l'accesso non
-sarà più possibile, ma il segnale emesso non sarà \const{SIGSEGV}, ma
+sarà più possibile, ma il segnale emesso non sarà \const{SIGSEGV}, ma
 \const{SIGBUS}, come illustrato in fig.~\ref{fig:file_mmap_exceed}.
 
 Non tutti i file possono venire mappati in memoria, dato che, come illustrato
 in fig.~\ref{fig:file_mmap_layout}, la mappatura introduce una corrispondenza
 biunivoca fra una sezione di un file ed una sezione di memoria. Questo
-comporta che ad esempio non è possibile mappare in memoria file descriptor
+comporta che ad esempio non è possibile mappare in memoria file descriptor
 relativi a pipe, socket e fifo, per i quali non ha senso parlare di
 \textsl{sezione}. Lo stesso vale anche per alcuni file di dispositivo, che non
 dispongono della relativa operazione \func{mmap} (si ricordi quanto esposto in
-sez.~\ref{sec:file_vfs_work}). Si tenga presente però che esistono anche casi
-di dispositivi (un esempio è l'interfaccia al ponte PCI-VME del chip Universe)
+sez.~\ref{sec:file_vfs_work}). Si tenga presente però che esistono anche casi
+di dispositivi (un esempio è l'interfaccia al ponte PCI-VME del chip Universe)
 che sono utilizzabili solo con questa interfaccia.
 
 \begin{figure}[htb]
@@ -3675,20 +3676,20 @@ che sono utilizzabili solo con questa interfaccia.
 Dato che passando attraverso una \func{fork} lo spazio di indirizzi viene
 copiato integralmente, i file mappati in memoria verranno ereditati in maniera
 trasparente dal processo figlio, mantenendo gli stessi attributi avuti nel
-padre; così se si è usato \const{MAP\_SHARED} padre e figlio accederanno allo
-stesso file in maniera condivisa, mentre se si è usato \const{MAP\_PRIVATE}
-ciascuno di essi manterrà una sua versione privata indipendente. Non c'è
+padre; così se si è usato \const{MAP\_SHARED} padre e figlio accederanno allo
+stesso file in maniera condivisa, mentre se si è usato \const{MAP\_PRIVATE}
+ciascuno di essi manterrà una sua versione privata indipendente. Non c'è
 invece nessun passaggio attraverso una \func{exec}, dato che quest'ultima
 sostituisce tutto lo spazio degli indirizzi di un processo con quello di un
 nuovo programma.
 
 Quando si effettua la mappatura di un file vengono pure modificati i tempi ad
-esso associati (di cui si è trattato in sez.~\ref{sec:file_file_times}). Il
-valore di \var{st\_atime} può venir cambiato in qualunque istante a partire
-dal momento in cui la mappatura è stata effettuata: il primo riferimento ad
+esso associati (di cui si è trattato in sez.~\ref{sec:file_file_times}). Il
+valore di \var{st\_atime} può venir cambiato in qualunque istante a partire
+dal momento in cui la mappatura è stata effettuata: il primo riferimento ad
 una pagina mappata su un file aggiorna questo tempo.  I valori di
-\var{st\_ctime} e \var{st\_mtime} possono venir cambiati solo quando si è
-consentita la scrittura sul file (cioè per un file mappato con
+\var{st\_ctime} e \var{st\_mtime} possono venir cambiati solo quando si è
+consentita la scrittura sul file (cioè per un file mappato con
 \const{PROT\_WRITE} e \const{MAP\_SHARED}) e sono aggiornati dopo la scrittura
 o in corrispondenza di una eventuale \func{msync}.
 
@@ -3696,22 +3697,22 @@ Dato per i file mappati in memoria le operazioni di I/O sono gestite
 direttamente dalla \index{memoria~virtuale}memoria virtuale, occorre essere
 consapevoli delle interazioni che possono esserci con operazioni effettuate
 con l'interfaccia standard dei file di cap.~\ref{cha:file_unix_interface}. Il
-problema è che una volta che si è mappato un file, le operazioni di lettura e
+problema è che una volta che si è mappato un file, le operazioni di lettura e
 scrittura saranno eseguite sulla memoria, e riportate su disco in maniera
 autonoma dal sistema della memoria virtuale.
 
 Pertanto se si modifica un file con l'interfaccia standard queste modifiche
 potranno essere visibili o meno a seconda del momento in cui la memoria
-virtuale trasporterà dal disco in memoria quella sezione del file, perciò è
+virtuale trasporterà dal disco in memoria quella sezione del file, perciò è
 del tutto imprevedibile il risultato della modifica di un file nei confronti
-del contenuto della memoria su cui è mappato.
+del contenuto della memoria su cui è mappato.
 
-Per questo, è sempre sconsigliabile eseguire scritture su file attraverso
-l'interfaccia standard quando lo si è mappato in memoria, è invece possibile
-usare l'interfaccia standard per leggere un file mappato in memoria, purché si
+Per questo, è sempre sconsigliabile eseguire scritture su file attraverso
+l'interfaccia standard quando lo si è mappato in memoria, è invece possibile
+usare l'interfaccia standard per leggere un file mappato in memoria, purché si
 abbia una certa cura; infatti l'interfaccia dell'I/O mappato in memoria mette
 a disposizione la funzione \funcd{msync} per sincronizzare il contenuto della
-memoria mappata con il file su disco; il suo prototipo è:
+memoria mappata con il file su disco; il suo prototipo è:
 \begin{functions}  
   \headdecl{unistd.h}
   \headdecl{sys/mman.h} 
@@ -3721,10 +3722,10 @@ memoria mappata con il file su disco; il suo prototipo 
   Sincronizza i contenuti di una sezione di un file mappato in memoria.
   
   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
-    errore nel qual caso \var{errno} assumerà uno dei valori:
+    errore nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
-    \item[\errcode{EINVAL}] o \param{start} non è multiplo di
-      \const{PAGE\_SIZE}, o si è specificato un valore non valido per
+    \item[\errcode{EINVAL}] o \param{start} non è multiplo di
+      \const{PAGE\_SIZE}, o si è specificato un valore non valido per
       \param{flags}.
     \item[\errcode{EFAULT}] l'intervallo specificato non ricade in una zona
       precedentemente mappata.
@@ -3734,8 +3735,8 @@ memoria mappata con il file su disco; il suo prototipo 
 
 La funzione esegue la sincronizzazione di quanto scritto nella sezione di
 memoria indicata da \param{start} e \param{offset}, scrivendo le modifiche sul
-file (qualora questo non sia già stato fatto).  Provvede anche ad aggiornare i
-relativi tempi di modifica. In questo modo si è sicuri che dopo l'esecuzione
+file (qualora questo non sia già stato fatto).  Provvede anche ad aggiornare i
+relativi tempi di modifica. In questo modo si è sicuri che dopo l'esecuzione
 di \func{msync} le funzioni dell'interfaccia standard troveranno un contenuto
 del file aggiornato.
 
@@ -3749,11 +3750,11 @@ del file aggiornato.
     \hline
     \hline
     \const{MS\_SYNC}       & richiede una sincronizzazione e ritorna soltanto
-                             quando questa è stata completata.\\
+                             quando questa è stata completata.\\
     \const{MS\_ASYNC}      & richiede una sincronizzazione, ma ritorna subito 
                              non attendendo che questa sia finita.\\
     \const{MS\_INVALIDATE} & invalida le pagine per tutte le mappature
-                             in memoria così da rendere necessaria una
+                             in memoria così da rendere necessaria una
                              rilettura immediata delle stesse.\\
     \hline
   \end{tabular}
@@ -3761,18 +3762,18 @@ del file aggiornato.
   \label{tab:file_mmap_msync}
 \end{table}
 
-L'argomento \param{flag} è specificato come maschera binaria composta da un OR
-dei valori riportati in tab.~\ref{tab:file_mmap_msync}, di questi però
+L'argomento \param{flag} è specificato come maschera binaria composta da un OR
+dei valori riportati in tab.~\ref{tab:file_mmap_msync}, di questi però
 \const{MS\_ASYNC} e \const{MS\_SYNC} sono incompatibili; con il primo valore
 infatti la funzione si limita ad inoltrare la richiesta di sincronizzazione al
 meccanismo della memoria virtuale, ritornando subito, mentre con il secondo
 attende che la sincronizzazione sia stata effettivamente eseguita. Il terzo
-flag fa sì che vengano invalidate, per tutte le mappature dello stesso file,
-le pagine di cui si è richiesta la sincronizzazione, così che esse possano
+flag fa sì che vengano invalidate, per tutte le mappature dello stesso file,
+le pagine di cui si è richiesta la sincronizzazione, così che esse possano
 essere immediatamente aggiornate con i nuovi valori.
 
-Una volta che si sono completate le operazioni di I/O si può eliminare la
-mappatura della memoria usando la funzione \funcd{munmap}, il suo prototipo è:
+Una volta che si sono completate le operazioni di I/O si può eliminare la
+mappatura della memoria usando la funzione \funcd{munmap}, il suo prototipo è:
 \begin{functions}  
   \headdecl{unistd.h}
   \headdecl{sys/mman.h} 
@@ -3782,7 +3783,7 @@ mappatura della memoria usando la funzione \funcd{munmap}, il suo prototipo 
   Rilascia la mappatura sulla sezione di memoria specificata.
 
   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
-    errore nel qual caso \var{errno} assumerà uno dei valori:
+    errore nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] l'intervallo specificato non ricade in una zona
       precedentemente mappata.
@@ -3791,20 +3792,20 @@ mappatura della memoria usando la funzione \funcd{munmap}, il suo prototipo 
 \end{functions}
 
 La funzione cancella la mappatura per l'intervallo specificato con
-\param{start} e \param{length}; ogni successivo accesso a tale regione causerà
+\param{start} e \param{length}; ogni successivo accesso a tale regione causerà
 un errore di accesso in memoria. L'argomento \param{start} deve essere
 allineato alle dimensioni di una pagina, e la mappatura di tutte le pagine
-contenute anche parzialmente nell'intervallo indicato, verrà rimossa.
-Indicare un intervallo che non contiene mappature non è un errore.  Si tenga
-presente inoltre che alla conclusione di un processo ogni pagina mappata verrà
+contenute anche parzialmente nell'intervallo indicato, verrà rimossa.
+Indicare un intervallo che non contiene mappature non è un errore.  Si tenga
+presente inoltre che alla conclusione di un processo ogni pagina mappata verrà
 automaticamente rilasciata, mentre la chiusura del file descriptor usato per
 il \textit{memory mapping} non ha alcun effetto su di esso.
 
 Lo standard POSIX prevede anche una funzione che permetta di cambiare le
 protezioni delle pagine di memoria; lo standard prevede che essa si applichi
 solo ai \textit{memory mapping} creati con \func{mmap}, ma nel caso di Linux
-la funzione può essere usata con qualunque pagina valida nella memoria
-virtuale. Questa funzione è \funcd{mprotect} ed il suo prototipo è:
+la funzione può essere usata con qualunque pagina valida nella memoria
+virtuale. Questa funzione è \funcd{mprotect} ed il suo prototipo è:
 \begin{functions}  
 %  \headdecl{unistd.h}
   \headdecl{sys/mman.h} 
@@ -3815,16 +3816,16 @@ virtuale. Questa funzione 
   specificato.
 
   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
-    errore nel qual caso \var{errno} assumerà uno dei valori:
+    errore nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
-    \item[\errcode{EINVAL}] il valore di \param{addr} non è valido o non è un
+    \item[\errcode{EINVAL}] il valore di \param{addr} non è valido o non è un
       multiplo di \const{PAGE\_SIZE}.
-    \item[\errcode{EACCESS}] l'operazione non è consentita, ad esempio si è
+    \item[\errcode{EACCESS}] l'operazione non è consentita, ad esempio si è
       cercato di marcare con \const{PROT\_WRITE} un segmento di memoria cui si
       ha solo accesso in lettura.
-%     \item[\errcode{ENOMEM}] non è stato possibile allocare le risorse
+%     \item[\errcode{ENOMEM}] non è stato possibile allocare le risorse
 %       necessarie all'interno del kernel.
-%     \item[\errcode{EFAULT}] si è specificato un indirizzo di memoria non
+%     \item[\errcode{EFAULT}] si è specificato un indirizzo di memoria non
 %       accessibile.
     \end{errlist}
     ed inoltre \errval{ENOMEM} ed \errval{EFAULT}.
@@ -3836,13 +3837,13 @@ La funzione prende come argomenti un indirizzo di partenza in \param{addr},
 allineato alle dimensioni delle pagine di memoria, ed una dimensione
 \param{size}. La nuova protezione deve essere specificata in \param{prot} con
 una combinazione dei valori di tab.~\ref{tab:file_mmap_prot}.  La nuova
-protezione verrà applicata a tutte le pagine contenute, anche parzialmente,
+protezione verrà applicata a tutte le pagine contenute, anche parzialmente,
 dall'intervallo fra \param{addr} e \param{addr}+\param{size}-1.
 
 Infine Linux supporta alcune operazioni specifiche non disponibili su altri
-kernel unix-like. La prima di queste è la possibilità di modificare un
+kernel unix-like. La prima di queste è la possibilità di modificare un
 precedente \textit{memory mapping}, ad esempio per espanderlo o restringerlo.
-Questo è realizzato dalla funzione \funcd{mremap}, il cui prototipo è:
+Questo è realizzato dalla funzione \funcd{mremap}, il cui prototipo è:
 \begin{functions}  
   \headdecl{unistd.h}
   \headdecl{sys/mman.h} 
@@ -3854,18 +3855,18 @@ Questo 
 
   \bodydesc{La funzione restituisce l'indirizzo alla nuova area di memoria in
     caso di successo od il valore \const{MAP\_FAILED} (pari a \texttt{(void *)
-      -1}) in caso di errore, nel qual caso \var{errno} assumerà uno dei
+      -1}) in caso di errore, nel qual caso \var{errno} assumerà uno dei
     valori:
     \begin{errlist}
-    \item[\errcode{EINVAL}] il valore di \param{old\_address} non è un
+    \item[\errcode{EINVAL}] il valore di \param{old\_address} non è un
       puntatore valido.
     \item[\errcode{EFAULT}] ci sono indirizzi non validi nell'intervallo
       specificato da \param{old\_address} e \param{old\_size}, o ci sono altre
       mappature di tipo non corrispondente a quella richiesta.
-    \item[\errcode{ENOMEM}] non c'è memoria sufficiente oppure l'area di
-      memoria non può essere espansa all'indirizzo virtuale corrente, e non si
-      è specificato \const{MREMAP\_MAYMOVE} nei flag.
-    \item[\errcode{EAGAIN}] il segmento di memoria scelto è bloccato e non può
+    \item[\errcode{ENOMEM}] non c'è memoria sufficiente oppure l'area di
+      memoria non può essere espansa all'indirizzo virtuale corrente, e non si
+      è specificato \const{MREMAP\_MAYMOVE} nei flag.
+    \item[\errcode{EAGAIN}] il segmento di memoria scelto è bloccato e non può
       essere rimappato.
     \end{errlist}
   }
@@ -3875,33 +3876,33 @@ La funzione richiede come argomenti \param{old\_address} (che deve essere
 allineato alle dimensioni di una pagina di memoria) che specifica il
 precedente indirizzo del \textit{memory mapping} e \param{old\_size}, che ne
 indica la dimensione. Con \param{new\_size} si specifica invece la nuova
-dimensione che si vuole ottenere. Infine l'argomento \param{flags} è una
+dimensione che si vuole ottenere. Infine l'argomento \param{flags} è una
 maschera binaria per i flag che controllano il comportamento della funzione.
-Il solo valore utilizzato è \const{MREMAP\_MAYMOVE}\footnote{per poter
+Il solo valore utilizzato è \const{MREMAP\_MAYMOVE}\footnote{per poter
   utilizzare questa costante occorre aver definito \macro{\_GNU\_SOURCE} prima
   di includere \file{sys/mman.h}.}  che consente di eseguire l'espansione
-anche quando non è possibile utilizzare il precedente indirizzo. Per questo
-motivo, se si è usato questo flag, la funzione può restituire un indirizzo
-della nuova zona di memoria che non è detto coincida con \param{old\_address}.
+anche quando non è possibile utilizzare il precedente indirizzo. Per questo
+motivo, se si è usato questo flag, la funzione può restituire un indirizzo
+della nuova zona di memoria che non è detto coincida con \param{old\_address}.
 
 La funzione si appoggia al sistema della \index{memoria~virtuale} memoria
 virtuale per modificare l'associazione fra gli indirizzi virtuali del processo
 e le pagine di memoria, modificando i dati direttamente nella
 \itindex{page~table} \textit{page table} del processo. Come per
-\func{mprotect} la funzione può essere usata in generale, anche per pagine di
-memoria non corrispondenti ad un \textit{memory mapping}, e consente così di
+\func{mprotect} la funzione può essere usata in generale, anche per pagine di
+memoria non corrispondenti ad un \textit{memory mapping}, e consente così di
 implementare la funzione \func{realloc} in maniera molto efficiente.
 
-Una caratteristica comune a tutti i sistemi unix-like è che la mappatura in
-memoria di un file viene eseguita in maniera lineare, cioè parti successive di
+Una caratteristica comune a tutti i sistemi unix-like è che la mappatura in
+memoria di un file viene eseguita in maniera lineare, cioè parti successive di
 un file vengono mappate linearmente su indirizzi successivi in memoria.
-Esistono però delle applicazioni\footnote{in particolare la tecnica è usata
-  dai database o dai programmi che realizzano macchine virtuali.} in cui è
+Esistono però delle applicazioni\footnote{in particolare la tecnica è usata
+  dai database o dai programmi che realizzano macchine virtuali.} in cui è
 utile poter mappare sezioni diverse di un file su diverse zone di memoria.
 
-Questo è ovviamente sempre possibile eseguendo ripetutamente la funzione
+Questo è ovviamente sempre possibile eseguendo ripetutamente la funzione
 \func{mmap} per ciascuna delle diverse aree del file che si vogliono mappare
-in sequenza non lineare,\footnote{ed in effetti è quello che veniva fatto
+in sequenza non lineare,\footnote{ed in effetti è quello che veniva fatto
   anche con Linux prima che fossero introdotte queste estensioni.} ma questo
 approccio ha delle conseguenze molto pesanti in termini di prestazioni.
 Infatti per ciascuna mappatura in memoria deve essere definita nella
@@ -3911,25 +3912,25 @@ memoria virtuale\footnote{quella che nel gergo del kernel viene chiamata VMA
 questa diventi visibile nello spazio degli indirizzi come illustrato in
 fig.~\ref{fig:file_mmap_layout}.
 
-Quando un processo esegue un gran numero di mappature diverse\footnote{si può
+Quando un processo esegue un gran numero di mappature diverse\footnote{si può
   arrivare anche a centinaia di migliaia.} per realizzare a mano una mappatura
-non-lineare si avrà un accrescimento eccessivo della sua \itindex{page~table}
-\textit{page table}, e lo stesso accadrà per tutti gli altri processi che
+non-lineare si avrà un accrescimento eccessivo della sua \itindex{page~table}
+\textit{page table}, e lo stesso accadrà per tutti gli altri processi che
 utilizzano questa tecnica. In situazioni in cui le applicazioni hanno queste
-esigenze si avranno delle prestazioni ridotte, dato che il kernel dovrà
+esigenze si avranno delle prestazioni ridotte, dato che il kernel dovrà
 impiegare molte risorse\footnote{sia in termini di memoria interna per i dati
   delle \itindex{page~table} \textit{page table}, che di CPU per il loro
-  aggiornamento.} solo per mantenere i dati di una gran quantità di
+  aggiornamento.} solo per mantenere i dati di una gran quantità di
 \textit{memory mapping}.
 
-Per questo motivo con il kernel 2.5.46 è stato introdotto, ad opera di Ingo
-Molnar, un meccanismo che consente la mappatura non-lineare. Anche questa è
+Per questo motivo con il kernel 2.5.46 è stato introdotto, ad opera di Ingo
+Molnar, un meccanismo che consente la mappatura non-lineare. Anche questa è
 una caratteristica specifica di Linux, non presente in altri sistemi
-unix-like.  Diventa così possibile utilizzare una sola mappatura
+unix-like.  Diventa così possibile utilizzare una sola mappatura
 iniziale\footnote{e quindi una sola \textit{virtual memory area} nella
   \itindex{page~table} \textit{page table} del processo.} e poi rimappare a
-piacere all'interno di questa i dati del file. Ciò è possibile grazie ad una
-nuova system call, \funcd{remap\_file\_pages}, il cui prototipo è:
+piacere all'interno di questa i dati del file. Ciò è possibile grazie ad una
+nuova system call, \funcd{remap\_file\_pages}, il cui prototipo è:
 \begin{functions}  
   \headdecl{sys/mman.h} 
 
@@ -3939,9 +3940,9 @@ nuova system call, \funcd{remap\_file\_pages}, il cui prototipo 
   Permette di rimappare non linearmente un precedente \textit{memory mapping}.
 
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
-    \item[\errcode{EINVAL}] si è usato un valore non valido per uno degli
+    \item[\errcode{EINVAL}] si è usato un valore non valido per uno degli
       argomenti o \param{start} non fa riferimento ad un \textit{memory
         mapping} valido creato con \const{MAP\_SHARED}.
     \end{errlist}
@@ -3950,17 +3951,17 @@ nuova system call, \funcd{remap\_file\_pages}, il cui prototipo 
 
 Per poter utilizzare questa funzione occorre anzitutto effettuare
 preliminarmente una chiamata a \func{mmap} con \const{MAP\_SHARED} per
-definire l'area di memoria che poi sarà rimappata non linearmente. Poi di
-chiamerà questa funzione per modificare le corrispondenze fra pagine di
+definire l'area di memoria che poi sarà rimappata non linearmente. Poi di
+chiamerà questa funzione per modificare le corrispondenze fra pagine di
 memoria e pagine del file; si tenga presente che \func{remap\_file\_pages}
-permette anche di mappare la stessa pagina di un file in più pagine della
+permette anche di mappare la stessa pagina di un file in più pagine della
 regione mappata.
 
 La funzione richiede che si identifichi la sezione del file che si vuole
 riposizionare all'interno del \textit{memory mapping} con gli argomenti
 \param{pgoff} e \param{size}; l'argomento \param{start} invece deve indicare
 un indirizzo all'interno dell'area definita dall'\func{mmap} iniziale, a
-partire dal quale la sezione di file indicata verrà rimappata. L'argomento
+partire dal quale la sezione di file indicata verrà rimappata. L'argomento
 \param{prot} deve essere sempre nullo, mentre \param{flags} prende gli stessi
 valori di \func{mmap} (quelli di tab.~\ref{tab:file_mmap_prot}) ma di tutti i
 flag solo \const{MAP\_NONBLOCK} non viene ignorato.
@@ -3974,43 +3975,43 @@ per migliorare le prestazioni in certe condizioni di utilizzo del
 
 Il problema si pone tutte le volte che si vuole mappare in memoria un file di
 grosse dimensioni. Il comportamento normale del sistema della
-\index{memoria~virtuale} memoria virtuale è quello per cui la regione mappata
+\index{memoria~virtuale} memoria virtuale è quello per cui la regione mappata
 viene aggiunta alla \itindex{page~table} \textit{page table} del processo, ma
-i dati verranno effettivamente utilizzati (si avrà cioè un
+i dati verranno effettivamente utilizzati (si avrà cioè un
 \itindex{page~fault} \textit{page fault} che li trasferisce dal disco alla
 memoria) soltanto in corrispondenza dell'accesso a ciascuna delle pagine
 interessate dal \textit{memory mapping}. 
 
-Questo vuol dire che il passaggio dei dati dal disco alla memoria avverrà una
+Questo vuol dire che il passaggio dei dati dal disco alla memoria avverrà una
 pagina alla volta con un gran numero di \itindex{page~fault} \textit{page
-  fault}, chiaramente se si sa in anticipo che il file verrà utilizzato
-immediatamente, è molto più efficiente eseguire un \itindex{prefaulting}
+  fault}, chiaramente se si sa in anticipo che il file verrà utilizzato
+immediatamente, è molto più efficiente eseguire un \itindex{prefaulting}
 \textit{prefaulting} in cui tutte le pagine di memoria interessate alla
 mappatura vengono ``\textsl{popolate}'' in una sola volta, questo
 comportamento viene abilitato quando si usa con \func{mmap} il flag
 \const{MAP\_POPULATE}.
 
-Dato che l'uso di \const{MAP\_POPULATE} comporta dell'I/O su disco che può
-rallentare l'esecuzione di \func{mmap} è stato introdotto anche un secondo
+Dato che l'uso di \const{MAP\_POPULATE} comporta dell'I/O su disco che può
+rallentare l'esecuzione di \func{mmap} è stato introdotto anche un secondo
 flag, \const{MAP\_NONBLOCK}, che esegue un \itindex{prefaulting}
-\textit{prefaulting} più limitato in cui vengono popolate solo le pagine della
-mappatura che già si trovano nella cache del kernel.\footnote{questo può
+\textit{prefaulting} più limitato in cui vengono popolate solo le pagine della
+mappatura che già si trovano nella cache del kernel.\footnote{questo può
   essere utile per il linker dinamico, in particolare quando viene effettuato
   il \textit{prelink} delle applicazioni.}
 
 Per i vantaggi illustrati all'inizio del paragrafo l'interfaccia del
-\textit{memory mapped I/O} viene usata da una grande varietà di programmi,
-spesso con esigenze molto diverse fra di loro riguardo le modalità con cui
-verranno eseguiti gli accessi ad un file; è ad esempio molto comune per i
-database effettuare accessi ai dati in maniera pressoché casuale, mentre un
-riproduttore audio o video eseguirà per lo più letture sequenziali.
+\textit{memory mapped I/O} viene usata da una grande varietà di programmi,
+spesso con esigenze molto diverse fra di loro riguardo le modalità con cui
+verranno eseguiti gli accessi ad un file; è ad esempio molto comune per i
+database effettuare accessi ai dati in maniera pressoché casuale, mentre un
+riproduttore audio o video eseguirà per lo più letture sequenziali.
 
-Per migliorare le prestazioni a seconda di queste modalità di accesso è
+Per migliorare le prestazioni a seconda di queste modalità di accesso è
 disponibile una apposita funzione, \funcd{madvise},\footnote{tratteremo in
   sez.~\ref{sec:file_fadvise} le funzioni che consentono di ottimizzare
   l'accesso ai file con l'interfaccia classica.} che consente di fornire al
-kernel delle indicazioni su dette modalità, così che possano essere adottate
-le opportune strategie di ottimizzazione. Il suo prototipo è:
+kernel delle indicazioni su dette modalità, così che possano essere adottate
+le opportune strategie di ottimizzazione. Il suo prototipo è:
 \begin{functions}  
   \headdecl{sys/mman.h} 
 
@@ -4019,18 +4020,18 @@ le opportune strategie di ottimizzazione. Il suo prototipo 
   Fornisce indicazioni sull'uso previsto di un \textit{memory mapping}.
 
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
     \item[\errcode{EBADF}] la mappatura esiste ma non corrisponde ad un file.
-    \item[\errcode{EINVAL}] \param{start} non è allineato alla dimensione di
-      una pagina, \param{length} ha un valore negativo, o \param{advice} non è
-      un valore valido, o si è richiesto il rilascio (con
+    \item[\errcode{EINVAL}] \param{start} non è allineato alla dimensione di
+      una pagina, \param{length} ha un valore negativo, o \param{advice} non è
+      un valore valido, o si è richiesto il rilascio (con
       \const{MADV\_DONTNEED}) di pagine bloccate o condivise.
     \item[\errcode{EIO}] la paginazione richiesta eccederebbe i limiti (vedi
       sez.~\ref{sec:sys_resource_limit}) sulle pagine residenti in memoria del
       processo (solo in caso di \const{MADV\_WILLNEED}).
     \item[\errcode{ENOMEM}] gli indirizzi specificati non sono mappati, o, in
-      caso \const{MADV\_WILLNEED}, non c'è sufficiente memoria per soddisfare
+      caso \const{MADV\_WILLNEED}, non c'è sufficiente memoria per soddisfare
       la richiesta.
     \end{errlist}
     ed inoltre \errval{EAGAIN} e \errval{ENOSYS}.
@@ -4042,7 +4043,7 @@ essere indicata con l'indirizzo iniziale \param{start} e l'estensione
 \param{length}, il valore di \param{start} deve essere allineato,
 mentre \param{length} deve essere un numero positivo.\footnote{la versione di
   Linux consente anche un valore nullo per \param{length}, inoltre se una
-  parte dell'intervallo non è mappato in memoria l'indicazione viene comunque
+  parte dell'intervallo non è mappato in memoria l'indicazione viene comunque
   applicata alle restanti parti, anche se la funzione ritorna un errore di
   \errval{ENOMEM}.} L'indicazione viene espressa dall'argomento \param{advice}
 che deve essere specificato con uno dei valori\footnote{si tenga presente che
@@ -4058,17 +4059,17 @@ tab.~\ref{tab:madvise_advice_values}.
     \textbf{Valore} & \textbf{Significato} \\
     \hline
     \hline
-    \const{MADV\_NORMAL}  & nessuna indicazione specifica, questo è il valore
-                            di default usato quando non si è chiamato
+    \const{MADV\_NORMAL}  & nessuna indicazione specifica, questo è il valore
+                            di default usato quando non si è chiamato
                             \func{madvise}.\\
     \const{MADV\_RANDOM}  & ci si aspetta un accesso casuale all'area
                             indicata, pertanto l'applicazione di una lettura
                             anticipata con il meccanismo del
                             \itindex{read-ahead} \textit{read-ahead} (vedi
-                            sez.~\ref{sec:file_fadvise}) è di
-                            scarsa utilità e verrà disabilitata.\\
+                            sez.~\ref{sec:file_fadvise}) è di
+                            scarsa utilità e verrà disabilitata.\\
     \const{MADV\_SEQUENTIAL}& ci si aspetta un accesso sequenziale al file,
-                            quindi da una parte sarà opportuno eseguire una
+                            quindi da una parte sarà opportuno eseguire una
                             lettura anticipata, e dall'altra si potranno
                             scartare immediatamente le pagine una volta che
                             queste siano state lette.\\
@@ -4078,12 +4079,12 @@ tab.~\ref{tab:madvise_advice_values}.
     \const{MADV\_DONTNEED}& non ci si aspetta nessun accesso nell'immediato
                             futuro, pertanto le pagine possono essere
                             liberate dal kernel non appena necessario; l'area
-                            di memoria resterà accessibile, ma un accesso
-                            richiederà che i dati vengano ricaricati dal file
+                            di memoria resterà accessibile, ma un accesso
+                            richiederà che i dati vengano ricaricati dal file
                             a cui la mappatura fa riferimento.\\
     \hline
     \const{MADV\_REMOVE}  & libera un intervallo di pagine di memoria ed il
-                            relativo supporto sottostante; è supportato
+                            relativo supporto sottostante; è supportato
                             soltanto sui filesystem in RAM \textit{tmpfs} e
                             \textit{shmfs}.\footnotemark\\ 
     \const{MADV\_DONTFORK}& impedisce che l'intervallo specificato venga
@@ -4092,7 +4093,7 @@ tab.~\ref{tab:madvise_advice_values}.
                             meccanismo del \itindex{copy~on~write}
                             \textit{copy on write} effettui la rilocazione
                             delle pagine quando il padre scrive sull'area
-                            di memoria dopo la \func{fork}, cosa che può
+                            di memoria dopo la \func{fork}, cosa che può
                             causare problemi per l'hardware che esegue
                             operazioni in DMA su quelle pagine.\\
     \const{MADV\_DOFORK}  & rimuove l'effetto della precedente
@@ -4109,23 +4110,23 @@ tab.~\ref{tab:madvise_advice_values}.
 \footnotetext{se usato su altri tipi di filesystem causa un errore di
   \errcode{ENOSYS}.}
 
-\footnotetext{a partire dal kernel 2.6.32 è stato introdotto un meccanismo che
+\footnotetext{a partire dal kernel 2.6.32 è stato introdotto un meccanismo che
   identifica pagine di memoria identiche e le accorpa in una unica pagina
   (soggetta al \textit{copy-on-write} per successive modifiche); per evitare
   di controllare tutte le pagine solo quelle marcate con questo flag vengono
   prese in considerazione per l'accorpamento; in questo modo si possono
   migliorare le prestazioni nella gestione delle macchine virtuali diminuendo
-  la loro occupazione di memoria, ma il meccanismo può essere usato anche in
+  la loro occupazione di memoria, ma il meccanismo può essere usato anche in
   altre applicazioni in cui sian presenti numerosi processi che usano gli
   stessi dati; per maggiori dettagli si veda
   \href{http://kernelnewbies.org/Linux_2_6_32\#head-d3f32e41df508090810388a57efce73f52660ccb}{\texttt{http://kernelnewbies.org/Linux\_2\_6\_32}}.}
 
 La funzione non ha, tranne il caso di \const{MADV\_DONTFORK}, nessun effetto
-sul comportamento di un programma, ma può influenzarne le prestazioni fornendo
-al kernel indicazioni sulle esigenze dello stesso, così che sia possibile
+sul comportamento di un programma, ma può influenzarne le prestazioni fornendo
+al kernel indicazioni sulle esigenze dello stesso, così che sia possibile
 scegliere le opportune strategie per la gestione del \itindex{read-ahead}
 \textit{read-ahead} e del caching dei dati. A differenza da quanto specificato
-nello standard POSIX.1b, per il quale l'uso di \func{madvise} è a scopo
+nello standard POSIX.1b, per il quale l'uso di \func{madvise} è a scopo
 puramente indicativo, Linux considera queste richieste come imperative, per
 cui ritorna un errore qualora non possa soddisfarle.\footnote{questo
   comportamento differisce da quanto specificato nello standard.}
@@ -4136,13 +4137,13 @@ cui ritorna un errore qualora non possa soddisfarle.\footnote{questo
 \subsection{I/O vettorizzato: \func{readv} e \func{writev}}
 \label{sec:file_multiple_io}
 
-Un caso abbastanza comune è quello in cui ci si trova a dover eseguire una
+Un caso abbastanza comune è quello in cui ci si trova a dover eseguire una
 serie multipla di operazioni di I/O, come una serie di letture o scritture di
-vari buffer. Un esempio tipico è quando i dati sono strutturati nei campi di
-una struttura ed essi devono essere caricati o salvati su un file.  Benché
+vari buffer. Un esempio tipico è quando i dati sono strutturati nei campi di
+una struttura ed essi devono essere caricati o salvati su un file.  Benché
 l'operazione sia facilmente eseguibile attraverso una serie multipla di
 chiamate a \func{read} e \func{write}, ci sono casi in cui si vuole poter
-contare sulla atomicità delle operazioni.
+contare sulla atomicità delle operazioni.
 
 Per questo motivo fino da BSD 4.2 vennero introdotte delle nuove system call
 che permettessero di effettuare con una sola chiamata una serie di letture o
@@ -4161,25 +4162,25 @@ sono:
   
   \bodydesc{Le funzioni restituiscono il numero di byte letti o scritti in
     caso di successo, e -1 in caso di errore, nel qual caso \var{errno}
-    assumerà uno dei valori:
+    assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] si è specificato un valore non valido per uno degli
-    argomenti (ad esempio \param{count} è maggiore di \const{IOV\_MAX}).
-  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
+  \item[\errcode{EINVAL}] si è specificato un valore non valido per uno degli
+    argomenti (ad esempio \param{count} è maggiore di \const{IOV\_MAX}).
+  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
     di avere eseguito una qualunque lettura o scrittura.
-  \item[\errcode{EAGAIN}] \param{fd} è stato aperto in modalità non bloccante e
+  \item[\errcode{EAGAIN}] \param{fd} è stato aperto in modalità non bloccante e
     non ci sono dati in lettura.
-  \item[\errcode{EOPNOTSUPP}] la coda delle richieste è momentaneamente piena.
+  \item[\errcode{EOPNOTSUPP}] la coda delle richieste è momentaneamente piena.
   \end{errlist}
   ed anche \errval{EISDIR}, \errval{EBADF}, \errval{ENOMEM}, \errval{EFAULT}
   (se non sono stati allocati correttamente i buffer specificati nei campi
-  \var{iov\_base}), più gli eventuali errori delle funzioni di lettura e
+  \var{iov\_base}), più gli eventuali errori delle funzioni di lettura e
   scrittura eseguite su \param{fd}.}
 \end{functions}
 
-Entrambe le funzioni usano una struttura \struct{iovec}, la cui definizione è
+Entrambe le funzioni usano una struttura \struct{iovec}, la cui definizione è
 riportata in fig.~\ref{fig:file_iovec}, che definisce dove i dati devono
-essere letti o scritti ed in che quantità. Il primo campo della struttura,
+essere letti o scritti ed in che quantità. Il primo campo della struttura,
 \var{iov\_base}, contiene l'indirizzo del buffer ed il secondo,
 \var{iov\_len}, la dimensione dello stesso.
 
@@ -4195,12 +4196,12 @@ essere letti o scritti ed in che quantit
 \end{figure}
 
 La lista dei buffer da utilizzare viene indicata attraverso l'argomento
-\param{vector} che è un vettore di strutture \struct{iovec}, la cui lunghezza
-è specificata dall'argomento \param{count}.\footnote{fino alle libc5, Linux
+\param{vector} che è un vettore di strutture \struct{iovec}, la cui lunghezza
+è specificata dall'argomento \param{count}.\footnote{fino alle libc5, Linux
   usava \type{size\_t} come tipo dell'argomento \param{count}, una scelta
-  logica, che però è stata dismessa per restare aderenti allo standard
-  POSIX.1-2001.}  Ciascuna struttura dovrà essere inizializzata opportunamente
-per indicare i vari buffer da e verso i quali verrà eseguito il trasferimento
+  logica, che però è stata dismessa per restare aderenti allo standard
+  POSIX.1-2001.}  Ciascuna struttura dovrà essere inizializzata opportunamente
+per indicare i vari buffer da e verso i quali verrà eseguito il trasferimento
 dei dati. Essi verranno letti (o scritti) nell'ordine in cui li si sono
 specificati nel vettore \param{vector}.
 
@@ -4213,16 +4214,16 @@ stesso valore deve essere ottenibile in esecuzione tramite la funzione
 \func{sysconf} richiedendo l'argomento \const{\_SC\_IOV\_MAX} (vedi
 sez.~\ref{sec:sys_sysconf}).
 
-Nel caso di Linux il limite di sistema è di 1024, però se si usano le
+Nel caso di Linux il limite di sistema è di 1024, però se si usano le
 \acr{glibc} queste forniscono un \textit{wrapper} per le system call che si
-accorge se una operazione supererà il precedente limite, in tal caso i dati
+accorge se una operazione supererà il precedente limite, in tal caso i dati
 verranno letti o scritti con le usuali \func{read} e \func{write} usando un
 buffer di dimensioni sufficienti appositamente allocato e sufficiente a
-contenere tutti i dati indicati da \param{vector}. L'operazione avrà successo
-ma si perderà l'atomicità del trasferimento da e verso la destinazione finale.
+contenere tutti i dati indicati da \param{vector}. L'operazione avrà successo
+ma si perderà l'atomicità del trasferimento da e verso la destinazione finale.
 
 Si tenga presente infine che queste funzioni operano sui file con
-l'interfaccia dei file descriptor, e non è consigliabile mescolarle con
+l'interfaccia dei file descriptor, e non è consigliabile mescolarle con
 l'interfaccia classica dei \textit{file stream} di
 cap.~\ref{cha:files_std_interface}; a causa delle bufferizzazioni interne di
 quest'ultima infatti si potrebbero avere risultati indefiniti e non
@@ -4254,12 +4255,12 @@ sez.~\ref{sec:file_read} e \ref{sec:file_write}); le due funzioni sono
   
   \bodydesc{Le funzioni hanno gli stessi valori di ritorno delle
     corrispondenti \func{readv} e \func{writev}; anche gli eventuali errori
-    sono gli stessi già visti in precedenza, ma ad essi si possono aggiungere
+    sono gli stessi già visti in precedenza, ma ad essi si possono aggiungere
     per \var{errno} anche i valori:
   \begin{errlist}
-  \item[\errcode{EOVERFLOW}] \param{offset} ha un valore che non può essere
+  \item[\errcode{EOVERFLOW}] \param{offset} ha un valore che non può essere
     usato come \ctyp{off\_t}.
-  \item[\errcode{ESPIPE}] \param{fd} è associato ad un socket o una pipe.
+  \item[\errcode{ESPIPE}] \param{fd} è associato ad un socket o una pipe.
   \end{errlist}
 }
 \end{functions}
@@ -4268,7 +4269,7 @@ Le due funzioni eseguono rispettivamente una lettura o una scrittura
 vettorizzata a partire dalla posizione \param{offset} sul file indicato
 da \param{fd}, la posizione corrente sul file, come vista da eventuali altri
 processi che vi facciano riferimento, non viene alterata. A parte la presenza
-dell'ulteriore argomento il comportamento delle funzioni è identico alle
+dell'ulteriore argomento il comportamento delle funzioni è identico alle
 precedenti \func{readv} e \func{writev}. 
 
 Con l'uso di queste funzioni si possono evitare eventuali
@@ -4284,28 +4285,28 @@ sez.~\ref{sec:file_adv_func}) con delle chiamate a \func{lseek}.
   \func{splice}} 
 \label{sec:file_sendfile_splice}
 
-Uno dei problemi che si presentano nella gestione dell'I/O è quello in cui si
-devono trasferire grandi quantità di dati da un file descriptor ed un altro;
+Uno dei problemi che si presentano nella gestione dell'I/O è quello in cui si
+devono trasferire grandi quantità di dati da un file descriptor ed un altro;
 questo usualmente comporta la lettura dei dati dal primo file descriptor in un
 buffer in memoria, da cui essi vengono poi scritti sul secondo.
 
-Benché il kernel ottimizzi la gestione di questo processo quando si ha a che
+Benché il kernel ottimizzi la gestione di questo processo quando si ha a che
 fare con file normali, in generale quando i dati da trasferire sono molti si
-pone il problema di effettuare trasferimenti di grandi quantità di dati da
-kernel space a user space e all'indietro, quando in realtà potrebbe essere più
+pone il problema di effettuare trasferimenti di grandi quantità di dati da
+kernel space a user space e all'indietro, quando in realtà potrebbe essere più
 efficiente mantenere tutto in kernel space. Tratteremo in questa sezione
 alcune funzioni specialistiche che permettono di ottimizzare le prestazioni in
 questo tipo di situazioni.
 
-La prima funzione che è stata ideata per ottimizzare il trasferimento dei dati
-fra due file descriptor è \func{sendfile};\footnote{la funzione è stata
+La prima funzione che è stata ideata per ottimizzare il trasferimento dei dati
+fra due file descriptor è \func{sendfile};\footnote{la funzione è stata
   introdotta con i kernel della serie 2.2, e disponibile dalle \acr{glibc}
-  2.1.} la funzione è presente in diverse versioni di Unix,\footnote{la si
-  ritrova ad esempio in FreeBSD, HPUX ed altri Unix.} ma non è presente né in
-POSIX.1-2001 né in altri standard,\footnote{pertanto si eviti di utilizzarla
+  2.1.} la funzione è presente in diverse versioni di Unix,\footnote{la si
+  ritrova ad esempio in FreeBSD, HPUX ed altri Unix.} ma non è presente né in
+POSIX.1-2001 né in altri standard,\footnote{pertanto si eviti di utilizzarla
   se si devono scrivere programmi portabili.} per cui per essa vengono
 utilizzati prototipi e semantiche differenti; nel caso di Linux il prototipo
-di \funcd{sendfile} è:
+di \funcd{sendfile} è:
 \begin{functions}  
   \headdecl{sys/sendfile.h} 
 
@@ -4315,16 +4316,16 @@ di \funcd{sendfile} 
   Copia dei dati da un file descriptor ad un altro.
 
   \bodydesc{La funzione restituisce il numero di byte trasferiti in caso di
-    successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
+    successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
     dei valori:
     \begin{errlist}
-    \item[\errcode{EAGAIN}] si è impostata la modalità non bloccante su
+    \item[\errcode{EAGAIN}] si è impostata la modalità non bloccante su
       \param{out\_fd} e la scrittura si bloccherebbe.
     \item[\errcode{EINVAL}] i file descriptor non sono validi, o sono bloccati
-      (vedi sez.~\ref{sec:file_locking}), o \func{mmap} non è disponibile per
+      (vedi sez.~\ref{sec:file_locking}), o \func{mmap} non è disponibile per
       \param{in\_fd}.
-    \item[\errcode{EIO}] si è avuto un errore di lettura da \param{in\_fd}.
-    \item[\errcode{ENOMEM}] non c'è memoria sufficiente per la lettura da
+    \item[\errcode{EIO}] si è avuto un errore di lettura da \param{in\_fd}.
+    \item[\errcode{ENOMEM}] non c'è memoria sufficiente per la lettura da
       \param{in\_fd}.
     \end{errlist}
     ed inoltre \errcode{EBADF} e \errcode{EFAULT}.
@@ -4335,35 +4336,35 @@ La funzione copia direttamente \param{count} byte dal file descriptor
 \param{in\_fd} al file descriptor \param{out\_fd}; in caso di successo
 funzione ritorna il numero di byte effettivamente copiati da \param{in\_fd} a
 \param{out\_fd} o $-1$ in caso di errore; come le ordinarie \func{read} e
-\func{write} questo valore può essere inferiore a quanto richiesto con
+\func{write} questo valore può essere inferiore a quanto richiesto con
 \param{count}.
 
-Se il puntatore \param{offset} è nullo la funzione legge i dati a partire
-dalla posizione corrente su \param{in\_fd}, altrimenti verrà usata la
+Se il puntatore \param{offset} è nullo la funzione legge i dati a partire
+dalla posizione corrente su \param{in\_fd}, altrimenti verrà usata la
 posizione indicata dal valore puntato da \param{offset}; in questo caso detto
-valore sarà aggiornato, come \textit{value result argument}, per indicare la
-posizione del byte successivo all'ultimo che è stato letto, mentre la
-posizione corrente sul file non sarà modificata. Se invece \param{offset} è
-nullo la posizione corrente sul file sarà aggiornata tenendo conto dei byte
+valore sarà aggiornato, come \textit{value result argument}, per indicare la
+posizione del byte successivo all'ultimo che è stato letto, mentre la
+posizione corrente sul file non sarà modificata. Se invece \param{offset} è
+nullo la posizione corrente sul file sarà aggiornata tenendo conto dei byte
 letti da \param{in\_fd}.
 
-Fino ai kernel della serie 2.4 la funzione è utilizzabile su un qualunque file
+Fino ai kernel della serie 2.4 la funzione è utilizzabile su un qualunque file
 descriptor, e permette di sostituire la invocazione successiva di una
 \func{read} e una \func{write} (e l'allocazione del relativo buffer) con una
-sola chiamata a \funcd{sendfile}. In questo modo si può diminuire il numero di
+sola chiamata a \funcd{sendfile}. In questo modo si può diminuire il numero di
 chiamate al sistema e risparmiare in trasferimenti di dati da kernel space a
-user space e viceversa.  La massima utilità della funzione si ha comunque per
+user space e viceversa.  La massima utilità della funzione si ha comunque per
 il trasferimento di dati da un file su disco ad un socket di
-rete,\footnote{questo è il caso classico del lavoro eseguito da un server web,
+rete,\footnote{questo è il caso classico del lavoro eseguito da un server web,
   ed infatti Apache ha una opzione per il supporto esplicito di questa
   funzione.} dato che in questo caso diventa possibile effettuare il
 trasferimento diretto via DMA dal controller del disco alla scheda di rete,
-senza neanche allocare un buffer nel kernel,\footnote{il meccanismo è detto
+senza neanche allocare un buffer nel kernel,\footnote{il meccanismo è detto
   \textit{zerocopy} in quanto i dati non vengono mai copiati dal kernel, che
   si limita a programmare solo le operazioni di lettura e scrittura via DMA.}
 ottenendo la massima efficienza possibile senza pesare neanche sul processore.
 
-In seguito però ci si è accorti che, fatta eccezione per il trasferimento
+In seguito però ci si è accorti che, fatta eccezione per il trasferimento
 diretto da file a socket, non sempre \func{sendfile} comportava miglioramenti
 significativi delle prestazioni rispetto all'uso in sequenza di \func{read} e
 \func{write},\footnote{nel caso generico infatti il kernel deve comunque
@@ -4373,61 +4374,61 @@ significativi delle prestazioni rispetto all'uso in sequenza di \func{read} e
   user space che ha una conoscenza diretta su come questi sono strutturati.} e
 che anzi in certi casi si potevano avere anche dei peggioramenti.  Questo ha
 portato, per i kernel della serie 2.6,\footnote{per alcune motivazioni di
-  questa scelta si può fare riferimento a quanto illustrato da Linus Torvalds
+  questa scelta si può fare riferimento a quanto illustrato da Linus Torvalds
   in \href{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}
   {\textsf{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}}.}
 alla decisione di consentire l'uso della funzione soltanto quando il file da
 cui si legge supporta le operazioni di \textit{memory mapping} (vale a dire
-non è un socket) e quello su cui si scrive è un socket; in tutti gli altri
-casi l'uso di \func{sendfile} darà luogo ad un errore di \errcode{EINVAL}.
+non è un socket) e quello su cui si scrive è un socket; in tutti gli altri
+casi l'uso di \func{sendfile} darà luogo ad un errore di \errcode{EINVAL}.
 
 Nonostante ci possano essere casi in cui \func{sendfile} non migliora le
 prestazioni, resta il dubbio se la scelta di disabilitarla sempre per il
 trasferimento fra file di dati sia davvero corretta. Se ci sono peggioramenti
-di prestazioni infatti si può sempre fare ricorso al metodo ordinario, ma
+di prestazioni infatti si può sempre fare ricorso al metodo ordinario, ma
 lasciare a disposizione la funzione consentirebbe se non altro di semplificare
 la gestione della copia dei dati fra file, evitando di dover gestire
 l'allocazione di un buffer temporaneo per il loro trasferimento.
 
-Questo dubbio si può comunque ritenere superato con l'introduzione, avvenuta a
+Questo dubbio si può comunque ritenere superato con l'introduzione, avvenuta a
 partire dal kernel 2.6.17, della nuova \textit{system call} \func{splice}. Lo
-scopo di questa funzione è quello di fornire un meccanismo generico per il
+scopo di questa funzione è quello di fornire un meccanismo generico per il
 trasferimento di dati da o verso un file utilizzando un buffer gestito
 internamente dal kernel. Descritta in questi termini \func{splice} sembra
 semplicemente un ``\textsl{dimezzamento}'' di \func{sendfile}.\footnote{nel
   senso che un trasferimento di dati fra due file con \func{sendfile} non
   sarebbe altro che la lettura degli stessi su un buffer seguita dalla
   relativa scrittura, cosa che in questo caso si dovrebbe eseguire con due
-  chiamate a \func{splice}.} In realtà le due system call sono profondamente
+  chiamate a \func{splice}.} In realtà le due system call sono profondamente
 diverse nel loro meccanismo di funzionamento;\footnote{questo fino al kernel
-  2.6.23, dove \func{sendfile} è stata reimplementata in termini di
+  2.6.23, dove \func{sendfile} è stata reimplementata in termini di
   \func{splice}, pur mantenendo disponibile la stessa interfaccia verso l'user
   space.} \func{sendfile} infatti, come accennato, non necessita di avere a
-disposizione un buffer interno, perché esegue un trasferimento diretto di
-dati; questo la rende in generale più efficiente, ma anche limitata nelle sue
-applicazioni, dato che questo tipo di trasferimento è possibile solo in casi
+disposizione un buffer interno, perché esegue un trasferimento diretto di
+dati; questo la rende in generale più efficiente, ma anche limitata nelle sue
+applicazioni, dato che questo tipo di trasferimento è possibile solo in casi
 specifici.\footnote{e nel caso di Linux questi sono anche solo quelli in cui
-  essa può essere effettivamente utilizzata.}
+  essa può essere effettivamente utilizzata.}
 
-Il concetto che sta dietro a \func{splice} invece è diverso,\footnote{in
-  realtà la proposta originale di Larry Mc Voy non differisce poi tanto negli
-  scopi da \func{sendfile}, quello che rende \func{splice} davvero diversa è
-  stata la reinterpretazione che ne è stata fatta nell'implementazione su
+Il concetto che sta dietro a \func{splice} invece è diverso,\footnote{in
+  realtà la proposta originale di Larry Mc Voy non differisce poi tanto negli
+  scopi da \func{sendfile}, quello che rende \func{splice} davvero diversa è
+  stata la reinterpretazione che ne è stata fatta nell'implementazione su
   Linux realizzata da Jens Anxboe, concetti che sono esposti sinteticamente
   dallo stesso Linus Torvalds in \href{http://kerneltrap.org/node/6505}
   {\textsf{http://kerneltrap.org/node/6505}}.} si tratta semplicemente di una
 funzione che consente di fare in maniera del tutto generica delle operazioni
 di trasferimento di dati fra un file e un buffer gestito interamente in kernel
 space. In questo caso il cuore della funzione (e delle affini \func{vmsplice}
-e \func{tee}, che tratteremo più avanti) è appunto l'uso di un buffer in
-kernel space, e questo è anche quello che ne ha semplificato l'adozione,
-perché l'infrastruttura per la gestione di un tale buffer è presente fin dagli
+e \func{tee}, che tratteremo più avanti) è appunto l'uso di un buffer in
+kernel space, e questo è anche quello che ne ha semplificato l'adozione,
+perché l'infrastruttura per la gestione di un tale buffer è presente fin dagli
 albori di Unix per la realizzazione delle \textit{pipe} (vedi
 sez.~\ref{sec:ipc_unix}). Dal punto di vista concettuale allora \func{splice}
-non è altro che una diversa interfaccia (rispetto alle \textit{pipe}) con cui
+non è altro che una diversa interfaccia (rispetto alle \textit{pipe}) con cui
 utilizzare in user space l'oggetto ``\textsl{buffer in kernel space}''.
 
-Così se per una \textit{pipe} o una \textit{fifo} il buffer viene utilizzato
+Così se per una \textit{pipe} o una \textit{fifo} il buffer viene utilizzato
 come area di memoria (vedi fig.~\ref{fig:ipc_pipe_singular}) dove appoggiare i
 dati che vengono trasferiti da un capo all'altro della stessa per creare un
 meccanismo di comunicazione fra processi, nel caso di \func{splice} il buffer
@@ -4436,9 +4437,9 @@ destinazione dei dati che vengono letti da un file. La funzione \funcd{splice}
 fornisce quindi una interfaccia generica che consente di trasferire dati da un
 buffer ad un file o viceversa; il suo prototipo, accessibile solo dopo aver
 definito la macro \macro{\_GNU\_SOURCE},\footnote{si ricordi che questa
-  funzione non è contemplata da nessuno standard, è presente solo su Linux, e
+  funzione non è contemplata da nessuno standard, è presente solo su Linux, e
   pertanto deve essere evitata se si vogliono scrivere programmi portabili.}
-è il seguente:
+è il seguente:
 \begin{functions}  
   \headdecl{fcntl.h} 
 
@@ -4448,58 +4449,58 @@ definito la macro \macro{\_GNU\_SOURCE},\footnote{si ricordi che questa
   Trasferisce dati da un file verso una pipe o viceversa.
 
   \bodydesc{La funzione restituisce il numero di byte trasferiti in caso di
-    successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
+    successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
     dei valori:
     \begin{errlist}
     \item[\errcode{EBADF}] uno o entrambi fra \param{fd\_in} e \param{fd\_out}
       non sono file descriptor validi o, rispettivamente, non sono stati
       aperti in lettura o scrittura.
     \item[\errcode{EINVAL}] il filesystem su cui si opera non supporta
-      \func{splice}, oppure nessuno dei file descriptor è una pipe, oppure si
-      è dato un valore a \param{off\_in} o \param{off\_out} ma il
-      corrispondente file è un dispositivo che non supporta la funzione
+      \func{splice}, oppure nessuno dei file descriptor è una pipe, oppure si
+      è dato un valore a \param{off\_in} o \param{off\_out} ma il
+      corrispondente file è un dispositivo che non supporta la funzione
       \func{seek}.
-    \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
+    \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
       richiesta.
     \item[\errcode{ESPIPE}] o \param{off\_in} o \param{off\_out} non sono
-      \const{NULL} ma il corrispondente file descriptor è una \textit{pipe}.
+      \const{NULL} ma il corrispondente file descriptor è una \textit{pipe}.
     \end{errlist}
   }
 \end{functions}
 
 La funzione esegue un trasferimento di \param{len} byte dal file descriptor
 \param{fd\_in} al file descriptor \param{fd\_out}, uno dei quali deve essere
-una \textit{pipe}; l'altro file descriptor può essere
-qualunque.\footnote{questo significa che può essere, oltre che un file di
+una \textit{pipe}; l'altro file descriptor può essere
+qualunque.\footnote{questo significa che può essere, oltre che un file di
   dati, anche un altra \textit{pipe}, o un socket.}  Come accennato una
-\textit{pipe} non è altro che un buffer in kernel space, per cui a seconda che
-essa sia usata per \param{fd\_in} o \param{fd\_out} si avrà rispettivamente la
+\textit{pipe} non è altro che un buffer in kernel space, per cui a seconda che
+essa sia usata per \param{fd\_in} o \param{fd\_out} si avrà rispettivamente la
 copia dei dati dal buffer al file o viceversa. 
 
-In caso di successo la funzione ritorna il numero di byte trasferiti, che può
+In caso di successo la funzione ritorna il numero di byte trasferiti, che può
 essere, come per le normali funzioni di lettura e scrittura su file, inferiore
-a quelli richiesti; un valore negativo indicherà un errore mentre un valore
-nullo indicherà che non ci sono dati da trasferire (ad esempio si è giunti
+a quelli richiesti; un valore negativo indicherà un errore mentre un valore
+nullo indicherà che non ci sono dati da trasferire (ad esempio si è giunti
 alla fine del file in lettura). Si tenga presente che, a seconda del verso del
 trasferimento dei dati, la funzione si comporta nei confronti del file
 descriptor che fa riferimento al file ordinario, come \func{read} o
-\func{write}, e pertanto potrà anche bloccarsi (a meno che non si sia aperto
-il suddetto file in modalità non bloccante).
+\func{write}, e pertanto potrà anche bloccarsi (a meno che non si sia aperto
+il suddetto file in modalità non bloccante).
 
 I due argomenti \param{off\_in} e \param{off\_out} consentono di specificare,
 come per l'analogo \param{offset} di \func{sendfile}, la posizione all'interno
 del file da cui partire per il trasferimento dei dati. Come per
 \func{sendfile} un valore nullo indica di usare la posizione corrente sul
-file, ed essa sarà aggiornata automaticamente secondo il numero di byte
+file, ed essa sarà aggiornata automaticamente secondo il numero di byte
 trasferiti. Un valore non nullo invece deve essere un puntatore ad una
-variabile intera che indica la posizione da usare; questa verrà aggiornata, al
+variabile intera che indica la posizione da usare; questa verrà aggiornata, al
 ritorno della funzione, al byte successivo all'ultimo byte trasferito.
-Ovviamente soltanto uno di questi due argomenti, e più precisamente quello che
-fa riferimento al file descriptor non associato alla \textit{pipe}, può essere
+Ovviamente soltanto uno di questi due argomenti, e più precisamente quello che
+fa riferimento al file descriptor non associato alla \textit{pipe}, può essere
 specificato come valore non nullo.
 
 Infine l'argomento \param{flags} consente di controllare alcune
-caratteristiche del funzionamento della funzione; il contenuto è una maschera
+caratteristiche del funzionamento della funzione; il contenuto è una maschera
 binaria e deve essere specificato come OR aritmetico dei valori riportati in
 tab.~\ref{tab:splice_flag}. Alcuni di questi valori vengono utilizzati anche
 dalle funzioni \func{vmsplice} e \func{tee} per cui la tabella riporta le
@@ -4518,27 +4519,27 @@ descrizioni complete di tutti i valori possibili anche quando, come per
                                  di memoria contenenti i dati invece di
                                  copiarle;\footnotemark viene usato soltanto
                                  da \func{splice}.\\ 
-    \const{SPLICE\_F\_NONBLOCK}& Richiede di operare in modalità non
+    \const{SPLICE\_F\_NONBLOCK}& Richiede di operare in modalità non
                                  bloccante; questo flag influisce solo sulle
                                  operazioni che riguardano l'I/O da e verso la
                                  \textit{pipe}. Nel caso di \func{splice}
-                                 questo significa che la funzione potrà
+                                 questo significa che la funzione potrà
                                  comunque bloccarsi nell'accesso agli altri
                                  file descriptor (a meno che anch'essi non
-                                 siano stati aperti in modalità non
+                                 siano stati aperti in modalità non
                                  bloccante).\\
-    \const{SPLICE\_F\_MORE}    & Indica al kernel che ci sarà l'invio di
+    \const{SPLICE\_F\_MORE}    & Indica al kernel che ci sarà l'invio di
                                  ulteriori dati in una \func{splice}
-                                 successiva, questo è un suggerimento utile
-                                 che viene usato quando \param{fd\_out} è un
+                                 successiva, questo è un suggerimento utile
+                                 che viene usato quando \param{fd\_out} è un
                                  socket.\footnotemark Attualmente viene usato
-                                 solo da \func{splice}, potrà essere
+                                 solo da \func{splice}, potrà essere
                                  implementato in futuro anche per
                                  \func{vmsplice} e \func{tee}.\\
     \const{SPLICE\_F\_GIFT}    & Le pagine di memoria utente sono
                                  ``\textsl{donate}'' al kernel;\footnotemark
                                  se impostato una seguente \func{splice} che
-                                 usa \const{SPLICE\_F\_MOVE} potrà spostare le 
+                                 usa \const{SPLICE\_F\_MOVE} potrà spostare le 
                                  pagine con successo, altrimenti esse dovranno
                                  essere copiate; per usare questa opzione i
                                  dati dovranno essere opportunamente allineati
@@ -4566,21 +4567,21 @@ descrizioni complete di tutti i valori possibili anche quando, come per
   sez.~\ref{sec:net_sendmsg}.}
 
 \footnotetext{questo significa che la cache delle pagine e i dati su disco
-  potranno differire, e che l'applicazione non potrà modificare quest'area di
+  potranno differire, e che l'applicazione non potrà modificare quest'area di
   memoria.}
 
 Per capire meglio il funzionamento di \func{splice} vediamo un esempio con un
 semplice programma che usa questa funzione per effettuare la copia di un file
 su un altro senza utilizzare buffer in user space. Il programma si chiama
-\texttt{splicecp.c} ed il codice completo è disponibile coi sorgenti allegati
+\texttt{splicecp.c} ed il codice completo è disponibile coi sorgenti allegati
 alla guida, il corpo principale del programma, che non contiene la sezione di
-gestione delle opzioni e le funzioni di ausilio è riportato in
+gestione delle opzioni e le funzioni di ausilio è riportato in
 fig.~\ref{fig:splice_example}.
 
-Lo scopo del programma è quello di eseguire la copia dei con \func{splice},
-questo significa che si dovrà usare la funzione due volte, prima per leggere i
+Lo scopo del programma è quello di eseguire la copia dei con \func{splice},
+questo significa che si dovrà usare la funzione due volte, prima per leggere i
 dati e poi per scriverli, appoggiandosi ad un buffer in kernel space (vale a
-dire ad una \textit{pipe}); lo schema del flusso dei dati è illustrato in
+dire ad una \textit{pipe}); lo schema del flusso dei dati è illustrato in
 fig.~\ref{fig:splicecp_data_flux}. 
 
 \begin{figure}[htb]
@@ -4592,9 +4593,9 @@ fig.~\ref{fig:splicecp_data_flux}.
 
 Una volta trattate le opzioni il programma verifica che restino
 (\texttt{\small 13--16}) i due argomenti che indicano il file sorgente ed il
-file destinazione. Il passo successivo è aprire il file sorgente
+file destinazione. Il passo successivo è aprire il file sorgente
 (\texttt{\small 18--22}), quello di destinazione (\texttt{\small 23--27}) ed
-infine (\texttt{\small 28--31}) la \textit{pipe} che verrà usata come buffer.
+infine (\texttt{\small 28--31}) la \textit{pipe} che verrà usata come buffer.
 
 \begin{figure}[!phtb]
   \footnotesize \centering
@@ -4609,22 +4610,22 @@ infine (\texttt{\small 28--31}) la \textit{pipe} che verr
 
 Il ciclo principale (\texttt{\small 33--58}) inizia con la lettura dal file
 sorgente tramite la prima \func{splice} (\texttt{\small 34--35}), in questo
-caso si è usato come primo argomento il file descriptor del file sorgente e
+caso si è usato come primo argomento il file descriptor del file sorgente e
 come terzo quello del capo in scrittura della \textit{pipe} (il funzionamento
 delle \textit{pipe} e l'uso della coppia di file descriptor ad esse associati
-è trattato in dettaglio in sez.~\ref{sec:ipc_unix}; non ne parleremo qui dato
+è trattato in dettaglio in sez.~\ref{sec:ipc_unix}; non ne parleremo qui dato
 che nell'ottica dell'uso di \func{splice} questa operazione corrisponde
 semplicemente al trasferimento dei dati dal file al buffer).
 
 La lettura viene eseguita in blocchi pari alla dimensione specificata
-dall'opzione \texttt{-s} (il default è 4096); essendo in questo caso
+dall'opzione \texttt{-s} (il default è 4096); essendo in questo caso
 \func{splice} equivalente ad una \func{read} sul file, se ne controlla il
 valore di uscita in \var{nread} che indica quanti byte sono stati letti, se
-detto valore è nullo (\texttt{\small 36}) questo significa che si è giunti
-alla fine del file sorgente e pertanto l'operazione di copia è conclusa e si
-può uscire dal ciclo arrivando alla conclusione del programma (\texttt{\small
-  59}). In caso di valore negativo (\texttt{\small 37--44}) c'è stato un
-errore ed allora si ripete la lettura (\texttt{\small 36}) se questo è dovuto
+detto valore è nullo (\texttt{\small 36}) questo significa che si è giunti
+alla fine del file sorgente e pertanto l'operazione di copia è conclusa e si
+può uscire dal ciclo arrivando alla conclusione del programma (\texttt{\small
+  59}). In caso di valore negativo (\texttt{\small 37--44}) c'è stato un
+errore ed allora si ripete la lettura (\texttt{\small 36}) se questo è dovuto
 ad una interruzione, o altrimenti si esce con un messaggio di errore
 (\texttt{\small 41--43}).
 
@@ -4637,13 +4638,13 @@ veda al solito sez.~\ref{sec:ipc_unix}) mentre il terzo sia il file descriptor
 del file di destinazione.
 
 Di nuovo si controlla il numero di byte effettivamente scritti restituito in
-\var{nwrite} e in caso di errore al solito si ripete la scrittura se questo è
+\var{nwrite} e in caso di errore al solito si ripete la scrittura se questo è
 dovuto a una interruzione o si esce con un messaggio negli altri casi
 (\texttt{\small 48--55}). Infine si chiude il ciclo di scrittura sottraendo
-(\texttt{\small 57}) il numero di byte scritti a quelli di cui è richiesta la
+(\texttt{\small 57}) il numero di byte scritti a quelli di cui è richiesta la
 scrittura,\footnote{in questa parte del ciclo \var{nread}, il cui valore
-  iniziale è dato dai byte letti dalla precedente chiamata a \func{splice},
-  viene ad assumere il significato di byte da scrivere.} così che il ciclo di
+  iniziale è dato dai byte letti dalla precedente chiamata a \func{splice},
+  viene ad assumere il significato di byte da scrivere.} così che il ciclo di
 scrittura venga ripetuto fintanto che il valore risultante sia maggiore di
 zero, indice che la chiamata a \func{splice} non ha esaurito tutti i dati
 presenti sul buffer.
@@ -4651,8 +4652,8 @@ presenti sul buffer.
 Si noti come il programma sia concettualmente identico a quello che si sarebbe
 scritto usando \func{read} al posto della prima \func{splice} e \func{write}
 al posto della seconda, utilizzando un buffer in user space per eseguire la
-copia dei dati, solo che in questo caso non è stato necessario allocare nessun
-buffer e non si è trasferito nessun dato in user space.
+copia dei dati, solo che in questo caso non è stato necessario allocare nessun
+buffer e non si è trasferito nessun dato in user space.
 
 Si noti anche come si sia usata la combinazione \texttt{SPLICE\_F\_MOVE |
   SPLICE\_F\_MORE } per l'argomento \param{flags} di \func{splice}, infatti
@@ -4663,14 +4664,14 @@ genere di migliorare le prestazioni.
 Come accennato con l'introduzione di \func{splice} sono state realizzate anche
 altre due \textit{system call}, \func{vmsplice} e \func{tee}, che utilizzano
 la stessa infrastruttura e si basano sullo stesso concetto di manipolazione e
-trasferimento di dati attraverso un buffer in kernel space; benché queste non
+trasferimento di dati attraverso un buffer in kernel space; benché queste non
 attengono strettamente ad operazioni di trasferimento dati fra file
 descriptor, le tratteremo qui, essendo strettamente correlate fra loro.
 
-La prima funzione, \funcd{vmsplice}, è la più simile a \func{splice} e come
+La prima funzione, \funcd{vmsplice}, è la più simile a \func{splice} e come
 indica il suo nome consente di trasferire i dati dalla memoria virtuale di un
 processo (ad esempio per un file mappato in memoria) verso una \textit{pipe};
-il suo prototipo è:
+il suo prototipo è:
 \begin{functions}  
   \headdecl{fcntl.h} 
   \headdecl{sys/uio.h}
@@ -4681,24 +4682,24 @@ il suo prototipo 
   Trasferisce dati dalla memoria di un processo verso una \textit{pipe}.
 
   \bodydesc{La funzione restituisce il numero di byte trasferiti in caso di
-    successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
+    successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
     dei valori:
     \begin{errlist}
-    \item[\errcode{EBADF}] o \param{fd} non è un file descriptor valido o non
+    \item[\errcode{EBADF}] o \param{fd} non è un file descriptor valido o non
       fa riferimento ad una \textit{pipe}.
-    \item[\errcode{EINVAL}] si è usato un valore nullo per \param{nr\_segs}
-      oppure si è usato \const{SPLICE\_F\_GIFT} ma la memoria non è allineata.
-    \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
+    \item[\errcode{EINVAL}] si è usato un valore nullo per \param{nr\_segs}
+      oppure si è usato \const{SPLICE\_F\_GIFT} ma la memoria non è allineata.
+    \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
       richiesta.
     \end{errlist}
   }
 \end{functions}
 
-La \textit{pipe} indicata da \param{fd} dovrà essere specificata tramite il
+La \textit{pipe} indicata da \param{fd} dovrà essere specificata tramite il
 file descriptor corrispondente al suo capo aperto in scrittura (di nuovo si
 faccia riferimento a sez.~\ref{sec:ipc_unix}), mentre per indicare quali
 segmenti della memoria del processo devono essere trasferiti verso di essa si
-dovrà utilizzare un vettore di strutture \struct{iovec} (vedi
+dovrà utilizzare un vettore di strutture \struct{iovec} (vedi
 fig.~\ref{fig:file_iovec}), esattamente con gli stessi criteri con cui le si
 usano per l'I/O vettorizzato, indicando gli indirizzi e le dimensioni di
 ciascun segmento di memoria su cui si vuole operare; le dimensioni del
@@ -4709,19 +4710,19 @@ illustrate in sez.~\ref{sec:file_multiple_io}.
 
 In caso di successo la funzione ritorna il numero di byte trasferiti sulla
 \textit{pipe}. In generale, se i dati una volta creati non devono essere
-riutilizzati (se cioè l'applicazione che chiama \func{vmsplice} non
-modificherà più la memoria trasferita), è opportuno utilizzare
-per \param{flag} il valore \const{SPLICE\_F\_GIFT}; questo fa sì che il kernel
-possa rimuovere le relative pagine dalla cache della memoria virtuale, così
-che queste possono essere utilizzate immediatamente senza necessità di
+riutilizzati (se cioè l'applicazione che chiama \func{vmsplice} non
+modificherà più la memoria trasferita), è opportuno utilizzare
+per \param{flag} il valore \const{SPLICE\_F\_GIFT}; questo fa sì che il kernel
+possa rimuovere le relative pagine dalla cache della memoria virtuale, così
+che queste possono essere utilizzate immediatamente senza necessità di
 eseguire una copia dei dati che contengono.
 
-La seconda funzione aggiunta insieme a \func{splice} è \func{tee}, che deve il
-suo nome all'omonimo comando in user space, perché in analogia con questo
+La seconda funzione aggiunta insieme a \func{splice} è \func{tee}, che deve il
+suo nome all'omonimo comando in user space, perché in analogia con questo
 permette di duplicare i dati in ingresso su una \textit{pipe} su un'altra
 \textit{pipe}. In sostanza, sempre nell'ottica della manipolazione dei dati su
 dei buffer in kernel space, la funzione consente di eseguire una copia del
-contenuto del buffer stesso. Il prototipo di \funcd{tee} è il seguente:
+contenuto del buffer stesso. Il prototipo di \funcd{tee} è il seguente:
 \begin{functions}  
   \headdecl{fcntl.h} 
 
@@ -4731,13 +4732,13 @@ contenuto del buffer stesso. Il prototipo di \funcd{tee} 
   Duplica \param{len} byte da una \textit{pipe} ad un'altra.
 
   \bodydesc{La funzione restituisce il numero di byte copiati in caso di
-    successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
+    successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
     dei valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] o uno fra \param{fd\_in} e \param{fd\_out} non fa
       riferimento ad una \textit{pipe} o entrambi fanno riferimento alla
       stessa \textit{pipe}.
-    \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
+    \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
       richiesta.
     \end{errlist}
   }
@@ -4753,17 +4754,17 @@ comportamento delle \textit{pipe} si veda sez.~\ref{sec:ipc_unix}). Al
 momento\footnote{quello della stesura di questo paragrafo, avvenuta il Gennaio
   2010, in futuro potrebbe essere implementato anche \const{SPLICE\_F\_MORE}.}
 il solo valore utilizzabile per \param{flag}, fra quelli elencati in
-tab.~\ref{tab:splice_flag}, è \const{SPLICE\_F\_NONBLOCK} che rende la
+tab.~\ref{tab:splice_flag}, è \const{SPLICE\_F\_NONBLOCK} che rende la
 funzione non bloccante.
 
 La funzione restituisce il numero di byte copiati da una \textit{pipe}
 all'altra (o $-1$ in caso di errore), un valore nullo indica che non ci sono
-byte disponibili da copiare e che il capo in scrittura della pipe è stato
-chiuso.\footnote{si tenga presente però che questo non avviene se si è
+byte disponibili da copiare e che il capo in scrittura della pipe è stato
+chiuso.\footnote{si tenga presente però che questo non avviene se si è
   impostato il flag \const{SPLICE\_F\_NONBLOCK}, in tal caso infatti si
   avrebbe un errore di \errcode{EAGAIN}.} Un esempio di realizzazione del
 comando \texttt{tee} usando questa funzione, ripreso da quello fornito nella
-pagina di manuale e dall'esempio allegato al patch originale, è riportato in
+pagina di manuale e dall'esempio allegato al patch originale, è riportato in
 fig.~\ref{fig:tee_example}. Il programma consente di copiare il contenuto
 dello standard input sullo standard output e su un file specificato come
 argomento, il codice completo si trova nel file \texttt{tee.c} dei sorgenti
@@ -4788,11 +4789,11 @@ standard input (\texttt{\small 20--27}) che lo standard output (\texttt{\small
 
 Il ciclo principale (\texttt{\small 37--58}) inizia con la chiamata a
 \func{tee} che duplica il contenuto dello standard input sullo standard output
-(\texttt{\small 39}), questa parte è del tutto analoga ad una lettura ed
+(\texttt{\small 39}), questa parte è del tutto analoga ad una lettura ed
 infatti come nell'esempio di fig.~\ref{fig:splice_example} si controlla il
-valore di ritorno della funzione in \var{len}; se questo è nullo significa che
-non ci sono più dati da leggere e si chiude il ciclo (\texttt{\small 40}), se
-è negativo c'è stato un errore, ed allora si ripete la chiamata se questo è
+valore di ritorno della funzione in \var{len}; se questo è nullo significa che
+non ci sono più dati da leggere e si chiude il ciclo (\texttt{\small 40}), se
+è negativo c'è stato un errore, ed allora si ripete la chiamata se questo è
 dovuto ad una interruzione (\texttt{\small 42--44}) o si stampa un messaggio
 di errore e si esce negli altri casi (\texttt{\small 44--47}).
 
@@ -4800,20 +4801,20 @@ Una volta completata la copia dei dati sullo standard output si possono
 estrarre dalla standard input e scrivere sul file, di nuovo su usa un ciclo di
 scrittura (\texttt{\small 50--58}) in cui si ripete una chiamata a
 \func{splice} (\texttt{\small 51}) fintanto che non si sono scritti tutti i
-\var{len} byte copiati in precedenza con \func{tee} (il funzionamento è
+\var{len} byte copiati in precedenza con \func{tee} (il funzionamento è
 identico all'analogo ciclo di scrittura del precedente esempio di
 fig.~\ref{fig:splice_example}).
 
 Infine una nota finale riguardo \func{splice}, \func{vmsplice} e \func{tee}:
-occorre sottolineare che benché finora si sia parlato di trasferimenti o copie
-di dati in realtà nella implementazione di queste system call non è affatto
+occorre sottolineare che benché finora si sia parlato di trasferimenti o copie
+di dati in realtà nella implementazione di queste system call non è affatto
 detto che i dati vengono effettivamente spostati o copiati, il kernel infatti
 realizza le \textit{pipe} come un insieme di puntatori\footnote{per essere
   precisi si tratta di un semplice buffer circolare, un buon articolo sul tema
   si trova su \href{http://lwn.net/Articles/118750/}
   {\textsf{http://lwn.net/Articles/118750/}}.}  alle pagine di memoria interna
 che contengono i dati, per questo una volta che i dati sono presenti nella
-memoria del kernel tutto quello che viene fatto è creare i suddetti puntatori
+memoria del kernel tutto quello che viene fatto è creare i suddetti puntatori
 ed aumentare il numero di referenze; questo significa che anche con \func{tee}
 non viene mai copiato nessun byte, vengono semplicemente copiati i puntatori.
 
@@ -4825,29 +4826,29 @@ non viene mai copiato nessun byte, vengono semplicemente copiati i puntatori.
 
 Nell'uso generico dell'interfaccia per l'accesso al contenuto dei file le
 operazioni di lettura e scrittura non necessitano di nessun intervento di
-supervisione da parte dei programmi, si eseguirà una \func{read} o una
-\func{write}, i dati verranno passati al kernel che provvederà ad effettuare
+supervisione da parte dei programmi, si eseguirà una \func{read} o una
+\func{write}, i dati verranno passati al kernel che provvederà ad effettuare
 tutte le operazioni (e a gestire il \textit{caching} dei dati) per portarle a
-termine in quello che ritiene essere il modo più efficiente.
+termine in quello che ritiene essere il modo più efficiente.
 
-Il problema è che il concetto di migliore efficienza impiegato dal kernel è
+Il problema è che il concetto di migliore efficienza impiegato dal kernel è
 relativo all'uso generico, mentre esistono molti casi in cui ci sono esigenze
 specifiche dei singoli programmi, che avendo una conoscenza diretta di come
 verranno usati i file, possono necessitare di effettuare delle ottimizzazioni
-specifiche, relative alle proprie modalità di I/O sugli stessi. Tratteremo in
+specifiche, relative alle proprie modalità di I/O sugli stessi. Tratteremo in
 questa sezione una serie funzioni che consentono ai programmi di ottimizzare
 il loro accesso ai dati dei file e controllare la gestione del relativo
 \textit{caching}.
 
 \itindbeg{read-ahead}
 
-Una prima funzione che può essere utilizzata per modificare la gestione
-ordinaria dell'I/O su un file è \funcd{readahead},\footnote{questa è una
+Una prima funzione che può essere utilizzata per modificare la gestione
+ordinaria dell'I/O su un file è \funcd{readahead},\footnote{questa è una
   funzione specifica di Linux, introdotta con il kernel 2.4.13, e non deve
   essere usata se si vogliono scrivere programmi portabili.} che consente di
-richiedere una lettura anticipata del contenuto dello stesso in cache, così
+richiedere una lettura anticipata del contenuto dello stesso in cache, così
 che le seguenti operazioni di lettura non debbano subire il ritardo dovuto
-all'accesso al disco; il suo prototipo è:
+all'accesso al disco; il suo prototipo è:
 \begin{functions}
   \headdecl{fcntl.h}
 
@@ -4856,10 +4857,10 @@ all'accesso al disco; il suo prototipo 
   Esegue una lettura preventiva del contenuto di un file in cache.
 
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
-    \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
-      valido o non è aperto in lettura.
+    \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
+      valido o non è aperto in lettura.
     \item[\errcode{EINVAL}] l'argomento \param{fd} si riferisce ad un tipo di
       file che non supporta l'operazione (come una pipe o un socket).
     \end{errlist}
@@ -4874,9 +4875,9 @@ La funzione richiede che venga letto in anticipo il contenuto del file
 corrispondenti alle dimensioni delle pagine di memoria, ed i valori di
 \param{offset} e \param{count} vengono arrotondati di conseguenza.
 
-La funzione estende quello che è un comportamento normale del kernel che
+La funzione estende quello che è un comportamento normale del kernel che
 quando si legge un file, aspettandosi che l'accesso prosegua, esegue sempre
-una lettura preventiva di una certa quantità di dati; questo meccanismo di
+una lettura preventiva di una certa quantità di dati; questo meccanismo di
 lettura anticipata viene chiamato \textit{read-ahead}, da cui deriva il nome
 della funzione. La funzione \func{readahead}, per ottimizzare gli accessi a
 disco, effettua la lettura in cache della sezione richiesta e si blocca
@@ -4884,59 +4885,59 @@ fintanto che questa non viene completata.  La posizione corrente sul file non
 viene modificata ed indipendentemente da quanto indicato con \param{count} la
 lettura dei dati si interrompe una volta raggiunta la fine del file.
 
-Si può utilizzare questa funzione per velocizzare le operazioni di lettura
+Si può utilizzare questa funzione per velocizzare le operazioni di lettura
 all'interno di un programma tutte le volte che si conosce in anticipo quanti
-dati saranno necessari nelle elaborazioni successive. Si potrà così
+dati saranno necessari nelle elaborazioni successive. Si potrà così
 concentrare in un unico momento (ad esempio in fase di inizializzazione) la
-lettura dei dati da disco, così da ottenere una migliore velocità di risposta
+lettura dei dati da disco, così da ottenere una migliore velocità di risposta
 nelle operazioni successive.
 
 \itindend{read-ahead}
 
 Il concetto di \func{readahead} viene generalizzato nello standard
 POSIX.1-2001 dalla funzione \func{posix\_fadvise},\footnote{anche se
-  l'argomento \param{len} è stato modificato da \ctyp{size\_t} a \ctyp{off\_t}
+  l'argomento \param{len} è stato modificato da \ctyp{size\_t} a \ctyp{off\_t}
   nella revisione POSIX.1-2003 TC5.} che consente di ``\textsl{avvisare}'' il
-kernel sulle modalità con cui si intende accedere nel futuro ad una certa
-porzione di un file,\footnote{la funzione però è stata introdotta su Linux
-  solo a partire dal kernel 2.5.60.} così che esso possa provvedere le
-opportune ottimizzazioni; il prototipo di \funcd{posix\_fadvise}, che è
-disponibile soltanto se è stata definita la macro \macro{\_XOPEN\_SOURCE} ad
-valore di almeno 600, è:
+kernel sulle modalità con cui si intende accedere nel futuro ad una certa
+porzione di un file,\footnote{la funzione però è stata introdotta su Linux
+  solo a partire dal kernel 2.5.60.} così che esso possa provvedere le
+opportune ottimizzazioni; il prototipo di \funcd{posix\_fadvise}, che è
+disponibile soltanto se è stata definita la macro \macro{\_XOPEN\_SOURCE} ad
+valore di almeno 600, è:
 \begin{functions}  
   \headdecl{fcntl.h} 
 
   \funcdecl{int posix\_fadvise(int fd, off\_t offset, off\_t len, int advice)}
   
-  Dichiara al kernel le future modalità di accesso ad un file.
+  Dichiara al kernel le future modalità di accesso ad un file.
 
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
-    \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
+    \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
       valido.
-    \item[\errcode{EINVAL}] il valore di \param{advice} non è valido o
+    \item[\errcode{EINVAL}] il valore di \param{advice} non è valido o
       \param{fd} si riferisce ad un tipo di file che non supporta l'operazione
       (come una pipe o un socket).
-    \item[\errcode{ESPIPE}] previsto dallo standard se \param{fd} è una pipe o
+    \item[\errcode{ESPIPE}] previsto dallo standard se \param{fd} è una pipe o
       un socket (ma su Linux viene restituito \errcode{EINVAL}).
     \end{errlist}
   }
 \end{functions}
 
-La funzione dichiara al kernel le modalità con cui intende accedere alla
+La funzione dichiara al kernel le modalità con cui intende accedere alla
 regione del file indicato da \param{fd} che inizia alla posizione
 \param{offset} e si estende per \param{len} byte. Se per \param{len} si usa un
-valore nullo la regione coperta sarà da \param{offset} alla fine del
-file.\footnote{questo è vero solo per le versioni più recenti, fino al kernel
-  2.6.6 il valore nullo veniva interpretato letteralmente.} Le modalità sono
-indicate dall'argomento \param{advice} che è una maschera binaria dei valori
+valore nullo la regione coperta sarà da \param{offset} alla fine del
+file.\footnote{questo è vero solo per le versioni più recenti, fino al kernel
+  2.6.6 il valore nullo veniva interpretato letteralmente.} Le modalità sono
+indicate dall'argomento \param{advice} che è una maschera binaria dei valori
 illustrati in tab.~\ref{tab:posix_fadvise_flag}, che riprendono il significato
-degli analoghi già visti in sez.~\ref{sec:file_memory_map} per
-\func{madvise}.\footnote{dato che si tratta dello stesso tipo di funzionalità,
+degli analoghi già visti in sez.~\ref{sec:file_memory_map} per
+\func{madvise}.\footnote{dato che si tratta dello stesso tipo di funzionalità,
   in questo caso applicata direttamente al sistema ai contenuti di un file
   invece che alla sua mappatura in memoria.} Si tenga presente comunque che la
-funzione dà soltanto un avvertimento, non esiste nessun vincolo per il kernel,
+funzione dà soltanto un avvertimento, non esiste nessun vincolo per il kernel,
 che utilizza semplicemente l'informazione.
 
 \begin{table}[htb]
@@ -4948,12 +4949,12 @@ che utilizza semplicemente l'informazione.
     \hline
     \hline
     \const{POSIX\_FADV\_NORMAL}  & Non ci sono avvisi specifici da fare
-                                   riguardo le modalità di accesso, il
-                                   comportamento sarà identico a quello che si
+                                   riguardo le modalità di accesso, il
+                                   comportamento sarà identico a quello che si
                                    avrebbe senza nessun avviso.\\ 
     \const{POSIX\_FADV\_SEQUENTIAL}& L'applicazione si aspetta di accedere di
                                    accedere ai dati specificati in maniera
-                                   sequenziale, a partire dalle posizioni più
+                                   sequenziale, a partire dalle posizioni più
                                    basse.\\ 
     \const{POSIX\_FADV\_RANDOM}  & I dati saranno letti in maniera
                                    completamente causale.\\
@@ -4963,7 +4964,7 @@ che utilizza semplicemente l'informazione.
     \hline
   \end{tabular}
   \caption{Valori delle costanti usabili per l'argomento \param{advice} di
-    \func{posix\_fadvise}, che indicano la modalità con cui si intende accedere
+    \func{posix\_fadvise}, che indicano la modalità con cui si intende accedere
     ad un file.}
   \label{tab:posix_fadvise_flag}
 \end{table}
@@ -4973,39 +4974,39 @@ memoria virtuale ed al meccanismo standard del \textit{read-ahead} utilizzato
 dal kernel; in particolare utilizzando il valore
 \const{POSIX\_FADV\_SEQUENTIAL} si raddoppia la dimensione dell'ammontare di
 dati letti preventivamente rispetto al default, aspettandosi appunto una
-lettura sequenziale che li utilizzerà, mentre con \const{POSIX\_FADV\_RANDOM}
+lettura sequenziale che li utilizzerà, mentre con \const{POSIX\_FADV\_RANDOM}
 si disabilita del tutto il suddetto meccanismo, dato che con un accesso del
-tutto casuale è inutile mettersi a leggere i dati immediatamente successivi
+tutto casuale è inutile mettersi a leggere i dati immediatamente successivi
 gli attuali; infine l'uso di \const{POSIX\_FADV\_NORMAL} consente di
 riportarsi al comportamento di default.
 
-Le due modalità \const{POSIX\_FADV\_NOREUSE} e \const{POSIX\_FADV\_WILLNEED}
+Le due modalità \const{POSIX\_FADV\_NOREUSE} e \const{POSIX\_FADV\_WILLNEED}
 fino al kernel 2.6.18 erano equivalenti, a partire da questo kernel la prima
-viene non ha più alcun effetto, mentre la seconda dà inizio ad una lettura in
-cache della regione del file indicata.  La quantità di dati che verranno letti
-è ovviamente limitata in base al carico che si viene a creare sul sistema
+viene non ha più alcun effetto, mentre la seconda dà inizio ad una lettura in
+cache della regione del file indicata.  La quantità di dati che verranno letti
+è ovviamente limitata in base al carico che si viene a creare sul sistema
 della memoria virtuale, ma in genere una lettura di qualche megabyte viene
-sempre soddisfatta (ed un valore superiore è solo raramente di qualche
-utilità). In particolare l'uso di \const{POSIX\_FADV\_WILLNEED} si può
+sempre soddisfatta (ed un valore superiore è solo raramente di qualche
+utilità). In particolare l'uso di \const{POSIX\_FADV\_WILLNEED} si può
 considerare l'equivalente POSIX di \func{readahead}.
 
 Infine con \const{POSIX\_FADV\_DONTNEED} si dice al kernel di liberare le
 pagine di cache occupate dai dati presenti nella regione di file indicata.
-Questa è una indicazione utile che permette di alleggerire il carico sulla
-cache, ed un programma può utilizzare periodicamente questa funzione per
-liberare pagine di memoria da dati che non sono più utilizzati per far posto a
+Questa è una indicazione utile che permette di alleggerire il carico sulla
+cache, ed un programma può utilizzare periodicamente questa funzione per
+liberare pagine di memoria da dati che non sono più utilizzati per far posto a
 nuovi dati utili.\footnote{la pagina di manuale riporta l'esempio dello
-  streaming di file di grosse dimensioni, dove le pagine occupate dai dati già
+  streaming di file di grosse dimensioni, dove le pagine occupate dai dati già
   inviati possono essere tranquillamente scartate.}
 
 Sia \func{posix\_fadvise} che \func{readahead} attengono alla ottimizzazione
 dell'accesso in lettura; lo standard POSIX.1-2001 prevede anche una funzione
 specifica per le operazioni di scrittura,
-\funcd{posix\_fallocate},\footnote{la funzione è stata introdotta a partire
+\funcd{posix\_fallocate},\footnote{la funzione è stata introdotta a partire
   dalle glibc 2.1.94.} che consente di preallocare dello spazio disco per
 assicurarsi che una seguente scrittura non fallisca, il suo prototipo,
 anch'esso disponibile solo se si definisce la macro \macro{\_XOPEN\_SOURCE} ad
-almeno 600, è:
+almeno 600, è:
 \begin{functions}  
   \headdecl{fcntl.h} 
 
@@ -5015,34 +5016,34 @@ almeno 600, 
 
   \bodydesc{La funzione restituisce 0 in caso di successo e direttamente un
     codice di errore, in caso di fallimento, in questo caso \var{errno} non
-    viene impostata, ma sarà restituito direttamente uno dei valori:
+    viene impostata, ma sarà restituito direttamente uno dei valori:
     \begin{errlist}
-    \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
-      valido o non è aperto in scrittura.
+    \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
+      valido o non è aperto in scrittura.
     \item[\errcode{EINVAL}] o \param{offset} o \param{len} sono minori di
       zero.
     \item[\errcode{EFBIG}] il valore di (\param{offset} + \param{len}) eccede
       la dimensione massima consentita per un file.
     \item[\errcode{ENODEV}] l'argomento \param{fd} non fa riferimento ad un
       file regolare.
-    \item[\errcode{ENOSPC}] non c'è sufficiente spazio disco per eseguire
+    \item[\errcode{ENOSPC}] non c'è sufficiente spazio disco per eseguire
       l'operazione. 
-    \item[\errcode{ESPIPE}] l'argomento \param{fd} è una pipe.
+    \item[\errcode{ESPIPE}] l'argomento \param{fd} è una pipe.
   \end{errlist}
   }
 \end{functions}
 
-La funzione assicura che venga allocato sufficiente spazio disco perché sia
+La funzione assicura che venga allocato sufficiente spazio disco perché sia
 possibile scrivere sul file indicato dall'argomento \param{fd} nella regione
 che inizia dalla posizione \param{offset} e si estende per \param{len} byte;
 se questa regione si estende oltre la fine del file le dimensioni di
 quest'ultimo saranno incrementate di conseguenza. Dopo aver eseguito con
-successo la funzione è garantito che una successiva scrittura nella regione
-indicata non fallirà per mancanza di spazio disco. La funzione non ha nessun
-effetto né sul contenuto, né sulla posizione corrente del file.
+successo la funzione è garantito che una successiva scrittura nella regione
+indicata non fallirà per mancanza di spazio disco. La funzione non ha nessun
+effetto né sul contenuto, né sulla posizione corrente del file.
 
-Ci si può chiedere a cosa possa servire una funzione come
-\func{posix\_fallocate} dato che è sempre possibile ottenere l'effetto voluto
+Ci si può chiedere a cosa possa servire una funzione come
+\func{posix\_fallocate} dato che è sempre possibile ottenere l'effetto voluto
 eseguendo esplicitamente sul file la scrittura\footnote{usando \funcd{pwrite}
   per evitare spostamenti della posizione corrente sul file.} di una serie di
 zeri per l'estensione di spazio necessaria qualora il \itindex{sparse~file}
@@ -5050,26 +5051,26 @@ file debba essere esteso o abbia dei \index{file!\textit{hole}}
 buchi.\footnote{si ricordi che occorre scrivere per avere l'allocazione e che
   l'uso di \func{truncate} per estendere un file creerebbe soltanto uno
   \itindex{sparse~file} \textit{sparse file} (vedi sez.~\ref{sec:file_lseek})
-  senza una effettiva allocazione dello spazio disco.}  In realtà questa è la
-modalità con cui la funzione veniva realizzata nella prima versione fornita
+  senza una effettiva allocazione dello spazio disco.}  In realtà questa è la
+modalità con cui la funzione veniva realizzata nella prima versione fornita
 dalle \acr{glibc}, per cui la funzione costituiva in sostanza soltanto una
-standardizzazione delle modalità di esecuzione di questo tipo di allocazioni.
+standardizzazione delle modalità di esecuzione di questo tipo di allocazioni.
 
-Questo metodo, anche se funzionante, comporta però l'effettiva esecuzione una
+Questo metodo, anche se funzionante, comporta però l'effettiva esecuzione una
 scrittura su tutto lo spazio disco necessario, da fare al momento della
 richiesta di allocazione, pagandone il conseguente prezzo in termini di
-prestazioni; il tutto quando in realtà servirebbe solo poter riservare lo
+prestazioni; il tutto quando in realtà servirebbe solo poter riservare lo
 spazio per poi andarci a scrivere, una sola volta, quando il contenuto finale
 diventa effettivamente disponibile.
 
-Per poter fare tutto questo è però necessario il supporto da parte del kernel,
-e questo è divenuto disponibile solo a partire dal kernel 2.6.23 in cui è
+Per poter fare tutto questo è però necessario il supporto da parte del kernel,
+e questo è divenuto disponibile solo a partire dal kernel 2.6.23 in cui è
 stata introdotta la nuova \textit{system call} \func{fallocate},\footnote{non
-  è detto che la funzione sia disponibile per tutti i filesystem, ad esempio
-  per XFS il supporto è stato introdotto solo a partire dal kernel 2.6.25.}
+  è detto che la funzione sia disponibile per tutti i filesystem, ad esempio
+  per XFS il supporto è stato introdotto solo a partire dal kernel 2.6.25.}
 che consente di realizzare direttamente all'interno del kernel l'allocazione
-dello spazio disco così da poter realizzare una versione di
-\func{posix\_fallocate} con prestazioni molto più elevate.\footnote{nelle
+dello spazio disco così da poter realizzare una versione di
+\func{posix\_fallocate} con prestazioni molto più elevate.\footnote{nelle
   \acr{glibc} la nuova \textit{system call} viene sfruttata per la
   realizzazione di \func{posix\_fallocate} a partire dalla versione 2.10.}
 
@@ -5078,8 +5079,8 @@ esclusivamente su Linux, inizialmente \funcd{fallocate} non era stata definita
 come funzione di libreria,\footnote{pertanto poteva essere invocata soltanto
   in maniera indiretta con l'ausilio di \func{syscall}, vedi
   sez.~\ref{sec:intro_syscall}, come \code{long fallocate(int fd, int mode,
-      loff\_t offset, loff\_t len)}.} ma a partire dalle \acr{glibc} 2.10 è
-  stato fornito un supporto esplicito; il suo prototipo è:
+      loff\_t offset, loff\_t len)}.} ma a partire dalle \acr{glibc} 2.10 è
+  stato fornito un supporto esplicito; il suo prototipo è:
 \begin{functions}
   \headdecl{linux/fcntl.h} 
 
@@ -5088,17 +5089,17 @@ come funzione di libreria,\footnote{pertanto poteva essere invocata soltanto
   Prealloca dello spazio disco per un file.
   
   \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di errore,
-    nel qual caso \var{errno} può assumere i valori:
+    nel qual caso \var{errno} può assumere i valori:
     \begin{errlist}
     \item[\errcode{EBADF}] \param{fd} non fa riferimento ad un file descriptor
       valido aperto in scrittura.
     \item[\errcode{EFBIG}] la somma di \param{offset} e \param{len} eccede le
       dimensioni massime di un file. 
-    \item[\errcode{EINVAL}] \param{offset} è minore di zero o \param{len} è
+    \item[\errcode{EINVAL}] \param{offset} è minore di zero o \param{len} è
       minore o uguale a zero. 
     \item[\errcode{ENODEV}] \param{fd} non fa riferimento ad un file ordinario
       o a una directory. 
-    \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per l'operazione. 
+    \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per l'operazione. 
     \item[\errcode{ENOSYS}] il filesystem contenente il file associato
       a \param{fd} non supporta \func{fallocate}.
     \item[\errcode{EOPNOTSUPP}] il filesystem contenente il file associato
@@ -5110,16 +5111,16 @@ come funzione di libreria,\footnote{pertanto poteva essere invocata soltanto
 
 La funzione prende gli stessi argomenti di \func{posix\_fallocate} con lo
 stesso significato, a cui si aggiunge l'argomento \param{mode} che indica le
-modalità di allocazione; al momento quest'ultimo può soltanto essere nullo o
+modalità di allocazione; al momento quest'ultimo può soltanto essere nullo o
 assumere il valore \const{FALLOC\_FL\_KEEP\_SIZE} che richiede che la
 dimensione del file\footnote{quella ottenuta nel campo \var{st\_size} di una
   struttura \struct{stat} dopo una chiamata a \texttt{fstat}.} non venga
 modificata anche quando la somma di \param{offset} e \param{len} eccede la
 dimensione corrente. 
 
-Se \param{mode} è nullo invece la dimensione totale del file in caso di
+Se \param{mode} è nullo invece la dimensione totale del file in caso di
 estensione dello stesso viene aggiornata, come richiesto per
-\func{posix\_fallocate}, ed invocata in questo modo si può considerare
+\func{posix\_fallocate}, ed invocata in questo modo si può considerare
 \func{fallocate} come l'implementazione ottimale di \func{posix\_fallocate} a
 livello di kernel.
 
diff --git a/filedir.tex b/filedir.tex
index e007c50..1b24864 100644
--- a/filedir.tex
+++ b/filedir.tex
@@ -12,21 +12,21 @@
 \chapter{File e directory}
 \label{cha:files_and_dirs}
 
-In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
+In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
 file e directory, iniziando dalle funzioni di libreria che si usano per
 copiarli, spostarli e cambiarne i nomi. Esamineremo poi l'interfaccia che
 permette la manipolazione dei vari attributi di file e directory ed alla fine
-faremo una trattazione dettagliata su come è strutturato il sistema base di
+faremo una trattazione dettagliata su come è strutturato il sistema base di
 protezioni e controllo dell'accesso ai file e sulle funzioni che ne permettono
 la gestione. Tutto quello che riguarda invece la manipolazione del contenuto
-dei file è lasciato ai capitoli successivi.
+dei file è lasciato ai capitoli successivi.
 
 
 
 \section{La gestione di file e directory}
 \label{sec:file_dir}
 
-Come già accennato in sez.~\ref{sec:file_filesystem} in un sistema unix-like
+Come già accennato in sez.~\ref{sec:file_filesystem} in un sistema unix-like
 la gestione dei file ha delle caratteristiche specifiche che derivano
 direttamente dall'architettura del sistema.  In questa sezione esamineremo le
 funzioni usate per la manipolazione di file e directory, per la creazione di
@@ -40,12 +40,12 @@ riguarda il comportamento e gli effetti delle varie funzioni.
 \subsection{Le funzioni \func{link} e \func{unlink}}
 \label{sec:file_link}
 
-Una caratteristica comune a diversi sistemi operativi è quella di poter creare
+Una caratteristica comune a diversi sistemi operativi è quella di poter creare
 dei nomi fittizi (come gli alias del MacOS o i collegamenti di Windows o i
 nomi logici del VMS) che permettono di fare riferimento allo stesso file
 chiamandolo con nomi diversi o accedendovi da directory diverse.
 
-Questo è possibile anche in ambiente Unix, dove tali collegamenti sono
+Questo è possibile anche in ambiente Unix, dove tali collegamenti sono
 usualmente chiamati \textit{link}; ma data l'architettura del sistema riguardo
 la gestione dei file (ed in particolare quanto trattato in
 sez.~\ref{sec:file_arch_func}) ci sono due metodi sostanzialmente diversi per
@@ -53,24 +53,24 @@ fare questa operazione.
 
 Come spiegato in sez.~\ref{sec:file_filesystem} l'accesso al contenuto di un
 file su disco avviene passando attraverso il suo \itindex{inode}
-\textit{inode}, che è la struttura usata dal kernel che lo identifica
+\textit{inode}, che è la struttura usata dal kernel che lo identifica
 univocamente all'interno di un singolo filesystem. Il nome del file che si
-trova nella voce di una directory è solo un'etichetta, mantenuta all'interno
+trova nella voce di una directory è solo un'etichetta, mantenuta all'interno
 della directory, che viene associata ad un puntatore che fa riferimento al
 suddetto \textit{inode}.
 
 Questo significa che, fintanto che si resta sullo stesso filesystem, la
-realizzazione di un link è immediata, ed uno stesso file può avere tanti nomi
+realizzazione di un link è immediata, ed uno stesso file può avere tanti nomi
 diversi, dati da altrettante associazioni diverse allo stesso \itindex{inode}
 \textit{inode} effettuate tramite ``etichette'' diverse in directory
 diverse. Si noti anche che nessuno di questi nomi viene ad assumere una
-particolare preferenza o originalità rispetto agli altri, in quanto tutti
+particolare preferenza o originalità rispetto agli altri, in quanto tutti
 fanno comunque riferimento allo stesso \itindex{inode} \textit{inode}.
 
 Per aggiungere ad una directory una voce che faccia riferimento ad un
-\itindex{inode} \textit{inode} già esistente si utilizza la funzione
+\itindex{inode} \textit{inode} già esistente si utilizza la funzione
 \func{link}; si suole chiamare questo tipo di associazione un collegamento
-diretto, o \textit{hard link}.  Il prototipo della funzione è il seguente:
+diretto, o \textit{hard link}.  Il prototipo della funzione è il seguente:
 \begin{prototype}{unistd.h}
 {int link(const char *oldpath, const char *newpath)}
   Crea un nuovo collegamento diretto.
@@ -81,11 +81,11 @@ diretto, o \textit{hard link}.  Il prototipo della funzione 
   \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
     riferimento ad un filesystem montato sullo stesso \textit{mount point}.
   \item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
-    \param{newpath} non supporta i link diretti o è una directory.
+    \param{newpath} non supporta i link diretti o è una directory.
   \item[\errcode{EEXIST}] un file (o una directory) di nome \param{newpath}
-    esiste già.
+    esiste già.
   \item[\errcode{EMLINK}] ci sono troppi link al file \param{oldpath} (il
-    numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
+    numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
     sez.~\ref{sec:sys_limits}).
   \end{errlist}
   ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG}, \errval{ENOTDIR},
@@ -99,71 +99,71 @@ creazione di un nuovo collegamento diretto non copia il contenuto del file, ma
 si limita a creare una voce nella directory specificata da \param{newpath} e
 ad aumentare di uno il numero di riferimenti al file (riportato nel campo
 \var{st\_nlink} della struttura \struct{stat}, vedi sez.~\ref{sec:file_stat})
-aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può
-essere così chiamato con vari nomi in diverse directory.
+aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può
+essere così chiamato con vari nomi in diverse directory.
 
 Per quanto dicevamo in sez.~\ref{sec:file_filesystem} la creazione di un
-collegamento diretto è possibile solo se entrambi i \itindex{pathname}
+collegamento diretto è possibile solo se entrambi i \itindex{pathname}
 \textit{pathname} sono nello stesso filesystem; inoltre il filesystem deve
-supportare i collegamenti diretti (il meccanismo non è disponibile ad esempio
-con il filesystem \acr{vfat} di Windows). In realtà la funzione ha un
-ulteriore requisito, e cioè che non solo che i due file siano sullo stesso
+supportare i collegamenti diretti (il meccanismo non è disponibile ad esempio
+con il filesystem \acr{vfat} di Windows). In realtà la funzione ha un
+ulteriore requisito, e cioè che non solo che i due file siano sullo stesso
 filesystem, ma anche che si faccia riferimento ad essi sullo stesso
 \textit{mount point}.\footnote{si tenga presente infatti (vedi
   sez.~\ref{sec:sys_file_config}) che a partire dal kernel 2.4 uno stesso
-  filesystem può essere montato più volte su directory diverse.}
+  filesystem può essere montato più volte su directory diverse.}
 
 La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
 filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo
-l'amministratore è in grado di creare un collegamento diretto ad un'altra
-directory: questo viene fatto perché con una tale operazione è possibile
+l'amministratore è in grado di creare un collegamento diretto ad un'altra
+directory: questo viene fatto perché con una tale operazione è possibile
 creare dei \textit{loop} nel filesystem (vedi l'esempio mostrato in
 sez.~\ref{sec:file_symlink}, dove riprenderemo il discorso) che molti programmi
 non sono in grado di gestire e la cui rimozione diventerebbe estremamente
 complicata (in genere per questo tipo di errori occorre far girare il
 programma \cmd{fsck} per riparare il filesystem).
 
-Data la pericolosità di questa operazione e la disponibilità dei link
-simbolici che possono fornire la stessa funzionalità senza questi problemi,
-nel caso di Linux questa capacità è stata completamente disabilitata, e al
+Data la pericolosità di questa operazione e la disponibilità dei link
+simbolici che possono fornire la stessa funzionalità senza questi problemi,
+nel caso di Linux questa capacità è stata completamente disabilitata, e al
 tentativo di creare un link diretto ad una directory la funzione \func{link}
 restituisce l'errore \errcode{EPERM}.
 
-Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
+Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
 \textit{hard link} ad un link simbolico. In questo caso lo standard POSIX
 prevederebbe che quest'ultimo venga risolto e che il collegamento sia
 effettuato rispetto al file cui esso punta, e che venga riportato un errore
 qualora questo non esista o non sia un file. Questo era anche il comportamento
 iniziale di Linux ma a partire dai kernel della serie 2.0.x\footnote{per la
   precisione il comportamento era quello previsto dallo standard POSIX fino al
-  kernel di sviluppo 1.3.56, ed è stato temporaneamente ripristinato anche
+  kernel di sviluppo 1.3.56, ed è stato temporaneamente ripristinato anche
   durante lo sviluppo della serie 2.1.x, per poi tornare al comportamento
   attuale fino ad oggi (per riferimento si veda
   \href{http://lwn.net/Articles/293902}
-  {\texttt{http://lwn.net/Articles/293902}}).} è stato adottato un
-comportamento che non segue più lo standard per cui l'\textit{hard link} viene
+  {\texttt{http://lwn.net/Articles/293902}}).} è stato adottato un
+comportamento che non segue più lo standard per cui l'\textit{hard link} viene
 creato rispetto al link simbolico, e non al file cui questo punta.
 
 La ragione di questa differenza rispetto allo standard, presente anche in
-altri sistemi unix-like, sono dovute al fatto che un link simbolico può fare
+altri sistemi unix-like, sono dovute al fatto che un link simbolico può fare
 riferimento anche ad un file non esistente o a una directory, per i quali
-l'\textit{hard link} non può essere creato, per cui la scelta di seguire il
-link simbolico è stata ritenuta una scelta scorretta nella progettazione
+l'\textit{hard link} non può essere creato, per cui la scelta di seguire il
+link simbolico è stata ritenuta una scelta scorretta nella progettazione
 dell'interfaccia.  Infatti se non ci fosse il comportamento adottato da Linux
-sarebbe impossibile creare un \textit{hard link} ad un link simbolico, perché
+sarebbe impossibile creare un \textit{hard link} ad un link simbolico, perché
 la funzione lo risolverebbe e l'\textit{hard link} verrebbe creato verso la
 destinazione. Invece evitando di seguire lo standard l'operazione diventa
-possibile, ed anche il comportamento della funzione risulta molto più
-comprensibile. Tanto più che se proprio se si vuole creare un \textit{hard
-  link} rispetto alla destinazione di un link simbolico è sempre possibile
-farlo direttamente.\footnote{ciò non toglie che questo comportamento fuori
+possibile, ed anche il comportamento della funzione risulta molto più
+comprensibile. Tanto più che se proprio se si vuole creare un \textit{hard
+  link} rispetto alla destinazione di un link simbolico è sempre possibile
+farlo direttamente.\footnote{ciò non toglie che questo comportamento fuori
   standard possa causare problemi, come nell'esempio descritto nell'articolo
   citato nella nota precedente, a programmi che non si aspettano questa
   differenza rispetto allo standard POSIX.}
 
-La rimozione di un file (o più precisamente della voce che lo referenzia
+La rimozione di un file (o più precisamente della voce che lo referenzia
 all'interno di una directory) si effettua con la funzione \funcd{unlink}; il
-suo prototipo è il seguente:
+suo prototipo è il seguente:
 \begin{prototype}{unistd.h}{int unlink(const char *pathname)}
 
   Cancella un file.
@@ -174,7 +174,7 @@ suo prototipo 
   \begin{errlist}
   \item[\errcode{EISDIR}] \param{pathname} si riferisce ad una directory.
     \footnotemark
-  \item[\errcode{EROFS}] \param{pathname} è su un filesystem montato in sola
+  \item[\errcode{EROFS}] \param{pathname} è su un filesystem montato in sola
   lettura.
   \item[\errcode{EISDIR}] \param{pathname} fa riferimento a una directory.
   \end{errlist}
@@ -183,9 +183,9 @@ suo prototipo 
   \errval{EIO}.}
 \end{prototype}
 
-\footnotetext{questo è un valore specifico ritornato da Linux che non consente
+\footnotetext{questo è un valore specifico ritornato da Linux che non consente
   l'uso di \func{unlink} con le directory (vedi sez.~\ref{sec:file_remove}).
-  Non è conforme allo standard POSIX, che prescrive invece l'uso di
+  Non è conforme allo standard POSIX, che prescrive invece l'uso di
   \errcode{EPERM} in caso l'operazione non sia consentita o il processo non
   abbia privilegi sufficienti.}
 
@@ -196,16 +196,16 @@ caso di socket, fifo o file di dispositivo \index{file!di~dispositivo} rimuove
 il nome, ma come per i file i processi che hanno aperto uno di questi oggetti
 possono continuare ad utilizzarlo.
 
-Per cancellare una voce in una directory è necessario avere il permesso di
+Per cancellare una voce in una directory è necessario avere il permesso di
 scrittura su di essa, dato che si va a rimuovere una voce dal suo contenuto, e
 il diritto di esecuzione sulla directory che la contiene (affronteremo in
 dettaglio l'argomento dei permessi di file e directory in
 sez.~\ref{sec:file_access_control}). Se inoltre lo \itindex{sticky~bit}
-\textit{sticky bit} (vedi sez.~\ref{sec:file_special_perm}) è impostato
-occorrerà anche essere proprietari del file o proprietari della directory (o
-root, per cui nessuna delle restrizioni è applicata).
+\textit{sticky bit} (vedi sez.~\ref{sec:file_special_perm}) è impostato
+occorrerà anche essere proprietari del file o proprietari della directory (o
+root, per cui nessuna delle restrizioni è applicata).
 
-Una delle caratteristiche di queste funzioni è che la creazione/rimozione del
+Una delle caratteristiche di queste funzioni è che la creazione/rimozione del
 nome dalla directory e l'incremento/decremento del numero di riferimenti
 \itindex{inode} nell'\textit{inode} devono essere effettuati in maniera
 atomica (si veda sez.~\ref{sec:proc_atom_oper}) senza possibili interruzioni
@@ -222,13 +222,13 @@ sempre un'ulteriore condizione,\footnote{come vedremo in
   \itindex{inode} \textit{inode} ad essi relativi. Prima di procedere alla
   cancellazione dello spazio occupato su disco dal contenuto di un file il
   kernel controlla anche questa tabella, per verificare che anche in essa non
-  ci sia più nessun riferimento all'\textit{inode} in questione.} e cioè che
+  ci sia più nessun riferimento all'\textit{inode} in questione.} e cioè che
 non ci siano processi che abbiano il suddetto file aperto).
 
-Questa proprietà viene spesso usata per essere sicuri di non lasciare file
-temporanei su disco in caso di crash dei programmi; la tecnica è quella di
+Questa proprietà viene spesso usata per essere sicuri di non lasciare file
+temporanei su disco in caso di crash dei programmi; la tecnica è quella di
 aprire il file e chiamare \func{unlink} subito dopo, in questo modo il
-contenuto del file è sempre disponibile all'interno del processo attraverso il
+contenuto del file è sempre disponibile all'interno del processo attraverso il
 suo file descriptor (vedi sez.~\ref{sec:file_fd}) fintanto che il processo non
 chiude il file, ma non ne resta traccia in nessuna directory, e lo spazio
 occupato su disco viene immediatamente rilasciato alla conclusione del
@@ -238,15 +238,15 @@ processo (quando tutti i file vengono chiusi).
 \subsection{Le funzioni \func{remove} e \func{rename}}
 \label{sec:file_remove}
 
-Al contrario di quanto avviene con altri Unix, in Linux non è possibile usare
-\func{unlink} sulle directory; per cancellare una directory si può usare la
+Al contrario di quanto avviene con altri Unix, in Linux non è possibile usare
+\func{unlink} sulle directory; per cancellare una directory si può usare la
 funzione \func{rmdir} (vedi sez.~\ref{sec:file_dir_creat_rem}), oppure la
 funzione \funcd{remove}. 
 
-Questa è la funzione prevista dallo standard ANSI C per cancellare un file o
+Questa è la funzione prevista dallo standard ANSI C per cancellare un file o
 una directory (e funziona anche per i sistemi che non supportano i link
-diretti). Per i file è identica a \func{unlink} e per le directory è identica
-a \func{rmdir}; il suo prototipo è:
+diretti). Per i file è identica a \func{unlink} e per le directory è identica
+a \func{rmdir}; il suo prototipo è:
 \begin{prototype}{stdio.h}{int remove(const char *pathname)}
   Cancella un nome dal filesystem. 
   
@@ -254,23 +254,23 @@ a \func{rmdir}; il suo prototipo 
     errore, nel qual caso il file non viene toccato.
     
     I codici di errore riportati in \var{errno} sono quelli della chiamata
-    utilizzata, pertanto si può fare riferimento a quanto illustrato nelle
+    utilizzata, pertanto si può fare riferimento a quanto illustrato nelle
     descrizioni di \func{unlink} e \func{rmdir}.}
 \end{prototype}
 
 La funzione utilizza la funzione \func{unlink}\footnote{questo vale usando le
-  \acr{glibc}; nelle libc4 e nelle libc5 la funzione \func{remove} è un
-  semplice alias alla funzione \func{unlink} e quindi non può essere usata per
+  \acr{glibc}; nelle libc4 e nelle libc5 la funzione \func{remove} è un
+  semplice alias alla funzione \func{unlink} e quindi non può essere usata per
   le directory.} per cancellare i file e la funzione \func{rmdir} per
 cancellare le directory; si tenga presente che per alcune implementazioni del
-protocollo NFS utilizzare questa funzione può comportare la scomparsa di file
+protocollo NFS utilizzare questa funzione può comportare la scomparsa di file
 ancora in uso.
 
 Per cambiare nome ad un file o a una directory (che devono comunque essere
 nello stesso filesystem) si usa invece la funzione \funcd{rename},\footnote{la
-  funzione è definita dallo standard ANSI C, ma si applica solo per i file, lo
+  funzione è definita dallo standard ANSI C, ma si applica solo per i file, lo
   standard POSIX estende la funzione anche alle directory.} il cui prototipo
-è:
+è:
 \begin{prototype}{stdio.h}
   {int rename(const char *oldpath, const char *newpath)} 
   
@@ -280,21 +280,21 @@ nello stesso filesystem) si usa invece la funzione \funcd{rename},\footnote{la
     errore, nel qual caso il file non viene toccato. La variabile
     \var{errno} viene impostata secondo i seguenti codici di errore:
   \begin{errlist} 
-  \item[\errcode{EISDIR}] \param{newpath} è una directory mentre
-    \param{oldpath} non è una directory.
+  \item[\errcode{EISDIR}] \param{newpath} è una directory mentre
+    \param{oldpath} non è una directory.
   \item[\errcode{EXDEV}] \param{oldpath} e \param{newpath} non sono sullo
     stesso filesystem.
-  \item[\errcode{ENOTEMPTY}] \param{newpath} è una directory già esistente e
+  \item[\errcode{ENOTEMPTY}] \param{newpath} è una directory già esistente e
     non vuota.
   \item[\errcode{EBUSY}] o \param{oldpath} o \param{newpath} sono in uso da
     parte di qualche processo (come directory di lavoro o come radice) o del
     sistema (come mount point).
   \item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
-    \param{oldpath} o più in generale si è cercato di creare una directory come
+    \param{oldpath} o più in generale si è cercato di creare una directory come
     sotto-directory di se stessa.
   \item[\errcode{ENOTDIR}] uno dei componenti dei \itindex{pathname}
-    \textit{pathname} non è una directory o \param{oldpath} è una directory e
-    \param{newpath} esiste e non è una directory.
+    \textit{pathname} non è una directory o \param{oldpath} è una directory e
+    \param{newpath} esiste e non è una directory.
   \end{errlist} 
   ed inoltre \errval{EACCES}, \errval{EPERM}, \errval{EMLINK},
   \errval{ENOENT}, \errval{ENOMEM}, \errval{EROFS}, \errval{ELOOP} e
@@ -305,36 +305,36 @@ La funzione rinomina il file \param{oldpath} in \param{newpath}, eseguendo se
 necessario lo spostamento di un file fra directory diverse. Eventuali altri
 link diretti allo stesso file non vengono influenzati.
 
-Il comportamento della funzione è diverso a seconda che si voglia rinominare
+Il comportamento della funzione è diverso a seconda che si voglia rinominare
 un file o una directory; se ci riferisce ad un file allora \param{newpath}, se
 esiste, non deve essere una directory (altrimenti si ha l'errore
 \errcode{EISDIR}). Nel caso \param{newpath} indichi un file esistente questo
 viene cancellato e rimpiazzato (atomicamente).
 
-Se \param{oldpath} è una directory allora \param{newpath}, se esiste, deve
+Se \param{oldpath} è una directory allora \param{newpath}, se esiste, deve
 essere una directory vuota, altrimenti si avranno gli errori \errcode{ENOTDIR}
-(se non è una directory) o \errcode{ENOTEMPTY} (se non è vuota). Chiaramente
-\param{newpath} non può contenere \param{oldpath} altrimenti si avrà un errore
+(se non è una directory) o \errcode{ENOTEMPTY} (se non è vuota). Chiaramente
+\param{newpath} non può contenere \param{oldpath} altrimenti si avrà un errore
 \errcode{EINVAL}.
 
-Se \param{oldpath} si riferisce ad un link simbolico questo sarà rinominato; se
-\param{newpath} è un link simbolico verrà cancellato come qualunque altro
+Se \param{oldpath} si riferisce ad un link simbolico questo sarà rinominato; se
+\param{newpath} è un link simbolico verrà cancellato come qualunque altro
 file.  Infine qualora \param{oldpath} e \param{newpath} siano due nomi dello
 stesso file lo standard POSIX prevede che la funzione non dia errore, e non
 faccia nulla, lasciando entrambi i nomi; Linux segue questo standard, anche
-se, come fatto notare dal manuale delle \textit{glibc}, il comportamento più
+se, come fatto notare dal manuale delle \textit{glibc}, il comportamento più
 ragionevole sarebbe quello di cancellare \param{oldpath}.
 
 Il vantaggio nell'uso di questa funzione al posto della chiamata successiva di
-\func{link} e \func{unlink} è che l'operazione è eseguita atomicamente, non
-può esistere cioè nessun istante in cui un altro processo può trovare attivi
+\func{link} e \func{unlink} è che l'operazione è eseguita atomicamente, non
+può esistere cioè nessun istante in cui un altro processo può trovare attivi
 entrambi i nomi dello stesso file, o, in caso di sostituzione di un file
 esistente, non trovare quest'ultimo prima che la sostituzione sia stata
 eseguita.
 
 In ogni caso se \param{newpath} esiste e l'operazione fallisce per un qualche
 motivo (come un crash del kernel), \func{rename} garantisce di lasciare
-presente un'istanza di \param{newpath}. Tuttavia nella sovrascrittura potrà
+presente un'istanza di \param{newpath}. Tuttavia nella sovrascrittura potrà
 esistere una finestra in cui sia \param{oldpath} che \param{newpath} fanno
 riferimento allo stesso file.
 
@@ -343,42 +343,42 @@ riferimento allo stesso file.
 \label{sec:file_symlink}
 
 Come abbiamo visto in sez.~\ref{sec:file_link} la funzione \func{link} crea
-riferimenti agli \itindex{inode} \textit{inode}, pertanto può funzionare
+riferimenti agli \itindex{inode} \textit{inode}, pertanto può funzionare
 soltanto per file che risiedono sullo stesso filesystem e solo per un
-filesystem di tipo Unix.  Inoltre abbiamo visto che in Linux non è consentito
+filesystem di tipo Unix.  Inoltre abbiamo visto che in Linux non è consentito
 eseguire un link diretto ad una directory.
 
 Per ovviare a queste limitazioni i sistemi Unix supportano un'altra forma di
 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
 come avviene in altri sistemi operativi, dei file speciali che contengono
-semplicemente il riferimento ad un altro file (o directory). In questo modo è
+semplicemente il riferimento ad un altro file (o directory). In questo modo è
 possibile effettuare link anche attraverso filesystem diversi, a file posti in
 filesystem che non supportano i link diretti, a delle directory, ed anche a
 file che non esistono ancora.
 
 Il sistema funziona in quanto i link simbolici sono riconosciuti come tali dal
-kernel\footnote{è uno dei diversi tipi di file visti in
+kernel\footnote{è uno dei diversi tipi di file visti in
   tab.~\ref{tab:file_file_types}, contrassegnato come tale
   nell'\textit{inode}, e riconoscibile dal valore del campo \var{st\_mode}
   della struttura \struct{stat} (vedi sez.~\ref{sec:file_stat}).}  per cui
 alcune funzioni di libreria (come \func{open} o \func{stat}) quando ricevono
 come argomento un link simbolico vengono automaticamente applicate al file da
 esso specificato.  La funzione che permette di creare un nuovo link simbolico
-è \funcd{symlink}, ed il suo prototipo è:
+è \funcd{symlink}, ed il suo prototipo è:
 \begin{prototype}{unistd.h}
   {int symlink(const char *oldpath, const char *newpath)} 
-  Crea un nuovo link simbolico di nome \param{newpath} il cui contenuto è
+  Crea un nuovo link simbolico di nome \param{newpath} il cui contenuto è
   \param{oldpath}.
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
-    errore, nel qual caso la variabile \var{errno} assumerà i valori:
+    errore, nel qual caso la variabile \var{errno} assumerà i valori:
   \begin{errlist}
   \item[\errcode{EPERM}] il filesystem che contiene \param{newpath} non
     supporta i link simbolici.
   \item[\errcode{ENOENT}] una componente di \param{newpath} non esiste o
-    \param{oldpath} è una stringa vuota.
-  \item[\errcode{EEXIST}] esiste già un file \param{newpath}.
-  \item[\errcode{EROFS}] \param{newpath} è su un filesystem montato in sola
+    \param{oldpath} è una stringa vuota.
+  \item[\errcode{EEXIST}] esiste già un file \param{newpath}.
+  \item[\errcode{EROFS}] \param{newpath} è su un filesystem montato in sola
     lettura.
   \end{errlist}
   ed inoltre \errval{EFAULT}, \errval{EACCES}, \errval{ENAMETOOLONG},
@@ -388,13 +388,13 @@ esso specificato.  La funzione che permette di creare un nuovo link simbolico
 
 Si tenga presente che la funzione non effettua nessun controllo sull'esistenza
 di un file di nome \param{oldpath}, ma si limita ad inserire quella stringa
-nel link simbolico. Pertanto un link simbolico può anche riferirsi ad un file
+nel link simbolico. Pertanto un link simbolico può anche riferirsi ad un file
 che non esiste: in questo caso si ha quello che viene chiamato un
 \textit{dangling link}, letteralmente un \textsl{link ciondolante}.
 
 Come accennato i link simbolici sono risolti automaticamente dal kernel
 all'invocazione delle varie system call; in tab.~\ref{tab:file_symb_effect} si
-è riportato un elenco dei comportamenti delle varie funzioni di libreria che
+è riportato un elenco dei comportamenti delle varie funzioni di libreria che
 operano sui file nei confronti della risoluzione dei link simbolici,
 specificando quali seguono il link simbolico e quali invece possono operare
 direttamente sul suo contenuto.
@@ -436,7 +436,7 @@ direttamente sul suo contenuto.
 \footnotetext{a partire dalla serie 2.0, e contrariamente a quanto indicato
   dallo standard POSIX, si veda quanto detto in sez.~\ref{sec:file_link}.}
 
-Si noti che non si è specificato il comportamento delle funzioni che operano
+Si noti che non si è specificato il comportamento delle funzioni che operano
 con i file descriptor, in quanto la risoluzione del link simbolico viene in
 genere effettuata dalla funzione che restituisce il file descriptor
 (normalmente la \func{open}, vedi sez.~\ref{sec:file_open}) e tutte le
@@ -446,7 +446,7 @@ Dato che, come indicato in tab.~\ref{tab:file_symb_effect}, funzioni come la
 \func{open} seguono i link simbolici, occorrono funzioni apposite per accedere
 alle informazioni del link invece che a quelle del file a cui esso fa
 riferimento. Quando si vuole leggere il contenuto di un link simbolico si usa
-la funzione \funcd{readlink}, il cui prototipo è:
+la funzione \funcd{readlink}, il cui prototipo è:
 \begin{prototype}{unistd.h}
 {int readlink(const char *path, char *buff, size\_t size)} 
   Legge il contenuto del link simbolico indicato da \param{path} nel buffer
@@ -454,10 +454,10 @@ la funzione \funcd{readlink}, il cui prototipo 
   
   \bodydesc{La funzione restituisce il numero di caratteri letti dentro
     \param{buff} o -1 per un errore, nel qual caso la variabile
-    \var{errno} assumerà i valori:
+    \var{errno} assumerà i valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] \param{path} non è un link simbolico o \param{size}
-    non è positiva.
+  \item[\errcode{EINVAL}] \param{path} non è un link simbolico o \param{size}
+    non è positiva.
   \end{errlist}
   ed inoltre \errval{ENOTDIR}, \errval{ENAMETOOLONG}, \errval{ENOENT},
   \errval{EACCES}, \errval{ELOOP}, \errval{EIO}, \errval{EFAULT} e
@@ -476,59 +476,59 @@ stringa con un carattere nullo e la tronca alla dimensione specificata da
   \label{fig:file_link_loop}
 \end{figure}
 
-Un caso comune che si può avere con i link simbolici è la creazione dei
-cosiddetti \textit{loop}. La situazione è illustrata in
+Un caso comune che si può avere con i link simbolici è la creazione dei
+cosiddetti \textit{loop}. La situazione è illustrata in
 fig.~\ref{fig:file_link_loop}, che riporta la struttura della directory
-\file{/boot}. Come si vede si è creato al suo interno un link simbolico che
+\file{/boot}. Come si vede si è creato al suo interno un link simbolico che
 punta di nuovo a \file{/boot}.\footnote{il loop mostrato in
-  fig.~\ref{fig:file_link_loop} è un usato per poter permettere a \cmd{grub}
+  fig.~\ref{fig:file_link_loop} è un usato per poter permettere a \cmd{grub}
   (un bootloader in grado di leggere direttamente da vari filesystem il file
   da lanciare come sistema operativo) di vedere i file contenuti nella
   directory \file{/boot} con lo stesso \textit{pathname} con cui verrebbero
   visti dal sistema operativo, anche se essi si trovano, come accade spesso,
   su una partizione separata (che \cmd{grub}, all'avvio, vede come radice).}
 
-Questo può causare problemi per tutti quei programmi che effettuano la
+Questo può causare problemi per tutti quei programmi che effettuano la
 scansione di una directory senza tener conto dei link simbolici, ad esempio se
 lanciassimo un comando del tipo \code{grep -r linux *}, il loop nella
 directory porterebbe il comando ad esaminare \file{/boot}, \file{/boot/boot},
-\file{/boot/boot/boot} e così via.
+\file{/boot/boot/boot} e così via.
 
 Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
 un \itindex{pathname} \textit{pathname} possano essere seguiti un numero
-limitato di link simbolici, il cui valore limite è specificato dalla costante
+limitato di link simbolici, il cui valore limite è specificato dalla costante
 \const{MAXSYMLINKS}. Qualora questo limite venga superato viene generato un
 errore ed \var{errno} viene impostata al valore \errcode{ELOOP}.
 
-Un punto da tenere sempre presente è che, come abbiamo accennato, un link
-simbolico può fare riferimento anche ad un file che non esiste; ad esempio
+Un punto da tenere sempre presente è che, come abbiamo accennato, un link
+simbolico può fare riferimento anche ad un file che non esiste; ad esempio
 possiamo creare un file temporaneo nella nostra directory con un link del
 tipo:
 \begin{verbatim}
 $ ln -s /tmp/tmp_file temporaneo
 \end{verbatim}%$
-anche se \file{/tmp/tmp\_file} non esiste. Questo può generare confusione, in
-quanto aprendo in scrittura \file{temporaneo} verrà creato
+anche se \file{/tmp/tmp\_file} non esiste. Questo può generare confusione, in
+quanto aprendo in scrittura \file{temporaneo} verrà creato
 \file{/tmp/tmp\_file} e scritto; ma accedendo in sola lettura a
 \file{temporaneo}, ad esempio con \cmd{cat}, otterremmo:
 \begin{verbatim}
 $ cat temporaneo
 cat: temporaneo: No such file or directory
 \end{verbatim}%$
-con un errore che può sembrare sbagliato, dato che un'ispezione con \cmd{ls}
+con un errore che può sembrare sbagliato, dato che un'ispezione con \cmd{ls}
 ci mostrerebbe invece l'esistenza di \file{temporaneo}.
 
 
 \subsection{La creazione e la cancellazione delle directory} 
 \label{sec:file_dir_creat_rem}
 
-Benché in sostanza le directory non siano altro che dei file contenenti
-elenchi di nomi ed \itindex{inode} \textit{inode}, non è possibile trattarle
+Benché in sostanza le directory non siano altro che dei file contenenti
+elenchi di nomi ed \itindex{inode} \textit{inode}, non è possibile trattarle
 come file ordinari e devono essere create direttamente dal kernel attraverso
-una opportuna system call.\footnote{questo è quello che permette anche,
+una opportuna system call.\footnote{questo è quello che permette anche,
   attraverso l'uso del VFS, l'utilizzo di diversi formati per la gestione dei
-  suddetti elenchi.}  La funzione usata per creare una directory è
-\funcd{mkdir}, ed il suo prototipo è:
+  suddetti elenchi.}  La funzione usata per creare una directory è
+\funcd{mkdir}, ed il suo prototipo è:
 \begin{functions}
   \headdecl{sys/stat.h}
   \headdecl{sys/types.h}
@@ -537,29 +537,29 @@ una opportuna system call.\footnote{questo 
   Crea una nuova directory.
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
   \item[\errcode{EEXIST}] un file (o una directory) con quel nome esiste di
-    già.
-  \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory in
+    già.
+  \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory in
     cui si vuole inserire la nuova directory.
   \item[\errcode{EMLINK}] la directory in cui si vuole creare la nuova
     directory contiene troppi file; sotto Linux questo normalmente non avviene
-    perché il filesystem standard consente la creazione di un numero di file
+    perché il filesystem standard consente la creazione di un numero di file
     maggiore di quelli che possono essere contenuti nel disco, ma potendo
-    avere a che fare anche con filesystem di altri sistemi questo errore può
+    avere a che fare anche con filesystem di altri sistemi questo errore può
     presentarsi.
-  \item[\errcode{ENOSPC}] non c'è abbastanza spazio sul file system per creare
-    la nuova directory o si è esaurita la quota disco dell'utente.
+  \item[\errcode{ENOSPC}] non c'è abbastanza spazio sul file system per creare
+    la nuova directory o si è esaurita la quota disco dell'utente.
   \end{errlist}
   ed inoltre anche \errval{EPERM}, \errval{EFAULT}, \errval{ENAMETOOLONG},
   \errval{ENOENT}, \errval{ENOTDIR}, \errval{ENOMEM}, \errval{ELOOP},
   \errval{EROFS}.}
 \end{functions}
 
-La funzione crea una nuova directory vuota, che contiene cioè solo le due voci
-standard presenti in ogni directory (cioè ``\file{.}'' e ``\file{..}''), con
-il nome indicato dall'argomento \param{dirname}. Il nome può essere indicato
+La funzione crea una nuova directory vuota, che contiene cioè solo le due voci
+standard presenti in ogni directory (cioè ``\file{.}'' e ``\file{..}''), con
+il nome indicato dall'argomento \param{dirname}. Il nome può essere indicato
 sia come \itindex{pathname} \textit{pathname} assoluto che come
 \itindex{pathname} \textit{pathname} relativo.
 
@@ -567,46 +567,46 @@ I permessi di accesso (vedi sez.~\ref{sec:file_access_control}) con cui la
 directory viene creata sono specificati dall'argomento \param{mode}, i cui
 possibili valori sono riportati in tab.~\ref{tab:file_permission_const}; si
 tenga presente che questi sono modificati dalla maschera di creazione dei file
-(si veda sez.~\ref{sec:file_perm_management}).  La titolarità della nuova
-directory è impostata secondo quanto riportato in
+(si veda sez.~\ref{sec:file_perm_management}).  La titolarità della nuova
+directory è impostata secondo quanto riportato in
 sez.~\ref{sec:file_ownership_management}.
 
-La funzione che permette la cancellazione di una directory è invece
-\funcd{rmdir}, ed il suo prototipo è:
+La funzione che permette la cancellazione di una directory è invece
+\funcd{rmdir}, ed il suo prototipo è:
 \begin{prototype}{sys/stat.h}{int rmdir(const char *dirname)} 
   Cancella una directory.
 
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
   \item[\errcode{EPERM}] il filesystem non supporta la cancellazione di
     directory, oppure la directory che contiene \param{dirname} ha lo
     \itindex{sticky~bit} \textit{sticky bit} impostato e l'user-ID effettivo
     del processo non corrisponde al proprietario della directory.
-  \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory
-    che contiene la directory che si vuole cancellare, o non c'è il permesso
+  \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory
+    che contiene la directory che si vuole cancellare, o non c'è il permesso
     di attraversare (esecuzione) una delle directory specificate in
     \param{dirname}.
-  \item[\errcode{EBUSY}] la directory specificata è la directory di lavoro o la
+  \item[\errcode{EBUSY}] la directory specificata è la directory di lavoro o la
     radice di qualche processo.
-  \item[\errcode{ENOTEMPTY}] la directory non è vuota.
+  \item[\errcode{ENOTEMPTY}] la directory non è vuota.
   \end{errlist}
   ed inoltre anche \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
   \errval{ENOTDIR}, \errval{ENOMEM}, \errval{ELOOP}, \errval{EROFS}.}
 \end{prototype}
 
 La funzione cancella la directory \param{dirname}, che deve essere vuota (la
-directory deve cioè contenere soltanto le due voci standard ``\file{.}'' e
-``\file{..}'').  Il nome può essere indicato con il \itindex{pathname}
+directory deve cioè contenere soltanto le due voci standard ``\file{.}'' e
+``\file{..}'').  Il nome può essere indicato con il \itindex{pathname}
 \textit{pathname} assoluto o relativo.
 
-La modalità con cui avviene la cancellazione è analoga a quella di
+La modalità con cui avviene la cancellazione è analoga a quella di
 \func{unlink}: fintanto che il numero di link \itindex{inode}
 all'\textit{inode} della directory non diventa nullo e nessun processo ha la
 directory aperta lo spazio occupato su disco non viene rilasciato. Se un
 processo ha la directory aperta la funzione rimuove il link \itindex{inode}
 all'\textit{inode} e nel caso sia l'ultimo, pure le voci standard ``\file{.}''
-e ``\file{..}'', a questo punto il kernel non consentirà di creare più nuovi
+e ``\file{..}'', a questo punto il kernel non consentirà di creare più nuovi
 file nella directory.
 
 
@@ -616,17 +616,17 @@ file nella directory.
 \index{file!di~dispositivo|(} 
 
 Finora abbiamo parlato esclusivamente di file, directory e link simbolici; in
-sez.~\ref{sec:file_file_types} abbiamo visto però che il sistema prevede pure
+sez.~\ref{sec:file_file_types} abbiamo visto però che il sistema prevede pure
 degli altri tipi di file speciali, come i file di dispositivo, le fifo ed i
 socket (questi ultimi sono un caso a parte, essendo associati anche alla
 comunicazione via rete, per cui ci saranno trattati in dettaglio a partire da
 cap.~\ref{cha:socket_intro}).
 
 La manipolazione delle caratteristiche di questi diversi tipi di file e la
-loro cancellazione può essere effettuata con le stesse funzioni che operano
+loro cancellazione può essere effettuata con le stesse funzioni che operano
 sui file regolari; ma quando li si devono creare sono necessarie delle
-funzioni apposite. La prima di queste funzioni è \funcd{mknod}, il cui
-prototipo è:
+funzioni apposite. La prima di queste funzioni è \funcd{mknod}, il cui
+prototipo è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{sys/stat.h}
@@ -637,14 +637,14 @@ prototipo 
   Crea un \textit{inode} del tipo specificato sul filesystem.
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
   \item[\errcode{EPERM}] non si hanno privilegi sufficienti a creare
-    l'\texttt{inode}, o il filesystem su cui si è cercato di
+    l'\texttt{inode}, o il filesystem su cui si è cercato di
     creare \param{pathname} non supporta l'operazione.
   \item[\errcode{EINVAL}] il valore di \param{mode} non indica un file, una
     fifo, un socket o un dispositivo.
-  \item[\errcode{EEXIST}] \param{pathname} esiste già o è un link simbolico.
+  \item[\errcode{EEXIST}] \param{pathname} esiste già o è un link simbolico.
   \end{errlist}
   ed inoltre anche \errval{EFAULT}, \errval{EACCES}, \errval{ENAMETOOLONG},
   \errval{ENOENT}, \errval{ENOTDIR}, \errval{ENOMEM}, \errval{ELOOP},
@@ -653,36 +653,36 @@ prototipo 
 
 La funzione, come suggerisce il nome, permette di creare un ``\textsl{nodo}''
 sul filesystem, e viene in genere utilizzata per creare i file di dispositivo,
-ma si può usare anche per creare file regolari. L'argomento
+ma si può usare anche per creare file regolari. L'argomento
 \param{mode} specifica sia il tipo di file che si vuole creare che i relativi
 permessi, secondo i valori riportati in tab.~\ref{tab:file_mode_flags}, che
 vanno combinati con un OR binario. I permessi sono comunque modificati nella
 maniera usuale dal valore di \itindex{umask} \textit{umask} (si veda
 sez.~\ref{sec:file_perm_management}).
 
-Per il tipo di file può essere specificato solo uno fra i seguenti valori:
-\const{S\_IFREG} per un file regolare (che sarà creato vuoto),
+Per il tipo di file può essere specificato solo uno fra i seguenti valori:
+\const{S\_IFREG} per un file regolare (che sarà creato vuoto),
 \const{S\_IFBLK} per un dispositivo a blocchi, \const{S\_IFCHR} per un
 dispositivo a caratteri, \const{S\_IFSOCK} per un socket e \const{S\_IFIFO}
-per una fifo;\footnote{con Linux la funzione non può essere usata per creare
+per una fifo;\footnote{con Linux la funzione non può essere usata per creare
   directory o link simbolici, si dovranno usare le funzioni \func{mkdir} e
-  \func{symlink} a questo dedicate.} un valore diverso comporterà l'errore
+  \func{symlink} a questo dedicate.} un valore diverso comporterà l'errore
 \errcode{EINVAL}.  
 
 Qualora si sia specificato in \param{mode} un file di dispositivo (vale a dire
-o \const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev} dovrà essere
+o \const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev} dovrà essere
 usato per indicare a quale dispositivo si fa riferimento, altrimenti il suo
-valore verrà ignorato.  Solo l'amministratore può creare un file di
+valore verrà ignorato.  Solo l'amministratore può creare un file di
 dispositivo usando questa funzione (il processo deve avere la
 \itindex{capabilities} \textit{capability} \const{CAP\_MKNOD}), ma in
-Linux\footnote{questo è un comportamento specifico di Linux, la funzione non è
-  prevista dallo standard POSIX.1 originale, mentre è presente in SVr4 e
+Linux\footnote{questo è un comportamento specifico di Linux, la funzione non è
+  prevista dallo standard POSIX.1 originale, mentre è presente in SVr4 e
   4.4BSD, ma esistono differenze nei comportamenti e nei codici di errore,
-  tanto che questa è stata introdotta in POSIX.1-2001 con una nota che la
+  tanto che questa è stata introdotta in POSIX.1-2001 con una nota che la
   definisce portabile solo quando viene usata per creare delle fifo, ma
   comunque deprecata essendo utilizzabile a tale scopo la specifica
   \func{mkfifo}.} l'uso per la creazione di un file ordinario, di una fifo o
-di un socket è consentito anche agli utenti normali.
+di un socket è consentito anche agli utenti normali.
 
 I nuovi \itindex{inode} \textit{inode} creati con \func{mknod} apparterranno
 al proprietario e al gruppo del processo che li ha creati, a meno che non si
@@ -692,8 +692,8 @@ sez.~\ref{sec:file_ownership_management}) in cui si va a creare
 \itindex{inode} l'\textit{inode}.
 
 Nella creazione di un file di dispositivo occorre poi specificare
-correttamente il valore di \param{dev}; questo infatti è di tipo
-\type{dev\_t}, che è un tipo primitivo (vedi
+correttamente il valore di \param{dev}; questo infatti è di tipo
+\type{dev\_t}, che è un tipo primitivo (vedi
 tab.~\ref{tab:intro_primitive_types}) riservato per indicare un
 \textsl{numero} di dispositivo; il kernel infatti identifica ciascun
 dispositivo con un valore numerico. Originariamente questo era un intero a 16
@@ -705,23 +705,23 @@ dispositivo.
 
 Il \itindex{major~number} \textit{major number} identifica una classe di
 dispositivi (ad esempio la seriale, o i dischi IDE) e serve in sostanza per
-indicare al kernel quale è il modulo che gestisce quella classe di
+indicare al kernel quale è il modulo che gestisce quella classe di
 dispositivi; per identificare uno specifico dispositivo di quella classe (ad
 esempio una singola porta seriale, o una partizione di un disco) si usa invece
 il \itindex{minor~number} \textit{minor number}. L'elenco aggiornato di questi
-numeri con le relative corrispondenze ai vari dispositivi può essere trovato
+numeri con le relative corrispondenze ai vari dispositivi può essere trovato
 nel file \texttt{Documentation/devices.txt} allegato alla documentazione dei
 sorgenti del kernel.
 
 Data la crescita nel numero di dispositivi supportati, ben presto il limite
-massimo di 256 si è rivelato troppo basso, e nel passaggio dai kernel della
-serie 2.4 alla serie 2.6 è stata aumentata a 32 bit la dimensione del tipo
+massimo di 256 si è rivelato troppo basso, e nel passaggio dai kernel della
+serie 2.4 alla serie 2.6 è stata aumentata a 32 bit la dimensione del tipo
 \type{dev\_t}, con delle dimensioni passate a 12 bit per il
 \itindex{major~number} \textit{major number} e 20 bit per il
-\itindex{minor~number} \textit{minor number}. La transizione però ha anche
-comportato il passaggio di \type{dev\_t} a tipo opaco, e la necessità di
-specificare il numero tramite delle opportune macro, così da non avere
-problemi di compatibilità con eventuali ulteriori estensioni.  
+\itindex{minor~number} \textit{minor number}. La transizione però ha anche
+comportato il passaggio di \type{dev\_t} a tipo opaco, e la necessità di
+specificare il numero tramite delle opportune macro, così da non avere
+problemi di compatibilità con eventuali ulteriori estensioni.  
 
 Le macro sono definite nel file \file{sys/sysmacros.h}, che viene
 automaticamente incluso quando si include \file{sys/types.h}; si possono
@@ -739,7 +739,7 @@ con le macro \macro{major} e \macro{minor}:
   \param{dev}.
 \end{functions}
 \noindent mentre una volta che siano noti \itindex{major~number} \textit{major
-  number} e \itindex{minor~number} \textit{minor number} si potrà costruire il
+  number} e \itindex{minor~number} \textit{minor number} si potrà costruire il
 relativo identificativo con la macro \macro{makedev}:
 \begin{functions}
   \headdecl{sys/types.h}
@@ -751,9 +751,9 @@ relativo identificativo con la macro \macro{makedev}:
 
 \index{file!di~dispositivo|)}
 
-Infine con lo standard POSIX.1-2001 è stata introdotta una funzione specifica
+Infine con lo standard POSIX.1-2001 è stata introdotta una funzione specifica
 per creare una fifo (tratteremo le fifo in in sez.~\ref{sec:ipc_named_pipe});
-la funzione è \funcd{mkfifo} ed il suo prototipo è:
+la funzione è \funcd{mkfifo} ed il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} \headdecl{sys/stat.h} 
   
@@ -762,7 +762,7 @@ la funzione 
   Crea una fifo.
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
-    errore, nel qual caso \var{errno} assumerà i valori \errval{EACCES},
+    errore, nel qual caso \var{errno} assumerà i valori \errval{EACCES},
     \errval{EEXIST}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOSPC},
     \errval{ENOTDIR} e \errval{EROFS}.}
 \end{functions}
@@ -777,29 +777,29 @@ modificati dal valore di \itindex{umask} \textit{umask}.
 \subsection{Accesso alle directory}
 \label{sec:file_dir_read}
 
-Benché le directory alla fine non siano altro che dei file che contengono
+Benché le directory alla fine non siano altro che dei file che contengono
 delle liste di nomi ed \itindex{inode} \textit{inode}, per il ruolo che
 rivestono nella struttura del sistema, non possono essere trattate come dei
 normali file di dati. Ad esempio, onde evitare inconsistenze all'interno del
-filesystem, solo il kernel può scrivere il contenuto di una directory, e non
-può essere un processo a inserirvi direttamente delle voci con le usuali
+filesystem, solo il kernel può scrivere il contenuto di una directory, e non
+può essere un processo a inserirvi direttamente delle voci con le usuali
 funzioni di scrittura.
 
-Ma se la scrittura e l'aggiornamento dei dati delle directory è compito del
+Ma se la scrittura e l'aggiornamento dei dati delle directory è compito del
 kernel, sono molte le situazioni in cui i processi necessitano di poterne
-leggere il contenuto. Benché questo possa essere fatto direttamente (vedremo
-in sez.~\ref{sec:file_open} che è possibile aprire una directory come se fosse
+leggere il contenuto. Benché questo possa essere fatto direttamente (vedremo
+in sez.~\ref{sec:file_open} che è possibile aprire una directory come se fosse
 un file, anche se solo in sola lettura) in generale il formato con cui esse
-sono scritte può dipendere dal tipo di filesystem, tanto che, come riportato
+sono scritte può dipendere dal tipo di filesystem, tanto che, come riportato
 in tab.~\ref{tab:file_file_operations}, il VFS del kernel prevede una apposita
 funzione per la lettura delle directory.
 
 Tutto questo si riflette nello standard POSIX\footnote{le funzioni sono
   previste pure in BSD e SVID.} che ha introdotto una apposita interfaccia per
 la lettura delle directory, basata sui cosiddetti \textit{directory stream}
-(chiamati così per l'analogia con i file stream dell'interfaccia standard ANSI
+(chiamati così per l'analogia con i file stream dell'interfaccia standard ANSI
 C di cap.~\ref{cha:files_std_interface}). La prima funzione di questa
-interfaccia è \funcd{opendir}, il cui prototipo è:
+interfaccia è \funcd{opendir}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} \headdecl{dirent.h} 
   
@@ -809,21 +809,21 @@ interfaccia 
   
   \bodydesc{La funzione restituisce un puntatore al \textit{directory stream}
     in caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
-    assumerà i valori \errval{EACCES}, \errval{EMFILE}, \errval{ENFILE},
+    assumerà i valori \errval{EACCES}, \errval{EMFILE}, \errval{ENFILE},
     \errval{ENOENT}, \errval{ENOMEM} e \errval{ENOTDIR}.}
 \end{functions}
 
 La funzione apre un \textit{directory stream} per la directory
 \param{dirname}, ritornando il puntatore ad un oggetto di tipo \type{DIR} (che
-è il \index{tipo!opaco} tipo opaco usato dalle librerie per gestire i
+è il \index{tipo!opaco} tipo opaco usato dalle librerie per gestire i
 \textit{directory stream}) da usare per tutte le operazioni successive, la
 funzione inoltre posiziona lo stream sulla prima voce contenuta nella
 directory.
 
-Dato che le directory sono comunque dei file, in alcuni casi può servire
+Dato che le directory sono comunque dei file, in alcuni casi può servire
 conoscere il \textit{file descriptor} associato ad un \textit{directory
-  stream}, a questo scopo si può usare la funzione \funcd{dirfd}, il cui
-prototipo è:
+  stream}, a questo scopo si può usare la funzione \funcd{dirfd}, il cui
+prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} \headdecl{dirent.h} 
   
@@ -835,21 +835,21 @@ prototipo 
     caso di successo e -1 in caso di errore.}
 \end{functions}
 
-La funzione\footnote{questa funzione è una estensione di BSD non presente in
-  POSIX, introdotta con BSD 4.3-Reno; è presente in Linux con le libc5 (a
+La funzione\footnote{questa funzione è una estensione di BSD non presente in
+  POSIX, introdotta con BSD 4.3-Reno; è presente in Linux con le libc5 (a
   partire dalla versione 5.1.2) e con le \acr{glibc}.} restituisce il file
-descriptor associato al \textit{directory stream} \param{dir}, essa è
+descriptor associato al \textit{directory stream} \param{dir}, essa è
 disponibile solo definendo \macro{\_BSD\_SOURCE} o \macro{\_SVID\_SOURCE}. Di
 solito si utilizza questa funzione in abbinamento alla funzione \func{fchdir}
 per cambiare la directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) a
 quella relativa allo stream che si sta esaminando.
 
-Viceversa se si è aperto un file descriptor corrispondente ad una directory è
+Viceversa se si è aperto un file descriptor corrispondente ad una directory è
 possibile associarvi un \textit{directory stream} con la funzione
-\funcd{fopendir},\footnote{questa funzione è però disponibile solo a partire
+\funcd{fopendir},\footnote{questa funzione è però disponibile solo a partire
   dalla versione 2.4 delle \acr{glibc}, e pur essendo candidata per
-  l'inclusione nella successiva revisione dello standard POSIX.1-2001, non è
-  ancora presente in nessuna specifica formale.} il cui prototipo è:
+  l'inclusione nella successiva revisione dello standard POSIX.1-2001, non è
+  ancora presente in nessuna specifica formale.} il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{dirent.h} 
@@ -860,19 +860,19 @@ possibile associarvi un \textit{directory stream} con la funzione
   
   \bodydesc{La funzione restituisce un puntatore al \textit{directory stream}
     in caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
-    assumerà il valore \errval{EBADF}.}
+    assumerà il valore \errval{EBADF}.}
 \end{functions}
 
-La funzione è identica a \func{opendir}, ma ritorna un \textit{directory
+La funzione è identica a \func{opendir}, ma ritorna un \textit{directory
   stream} facendo riferimento ad un file descriptor \param{fd} che deve essere
-stato aperto in precedenza e la funzione darà un errore qualora questo non
-corrisponda ad una directory. Una volta utilizzata il file descriptor verrà
+stato aperto in precedenza e la funzione darà un errore qualora questo non
+corrisponda ad una directory. Una volta utilizzata il file descriptor verrà
 usato dalle funzioni che operano sul \textit{directory stream} e non deve
-essere più utilizzato direttamente all'interno del proprio programma.
+essere più utilizzato direttamente all'interno del proprio programma.
 
 Una volta che si sia aperto un \textit{directory stream} la lettura del
 contenuto della directory viene effettuata attraverso la funzione
-\funcd{readdir}, il suo prototipo è:
+\funcd{readdir}, il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} \headdecl{dirent.h} 
   
@@ -882,30 +882,30 @@ contenuto della directory viene effettuata attraverso la funzione
   
   \bodydesc{La funzione restituisce il puntatore alla struttura contenente i
     dati in caso di successo e \val{NULL} altrimenti, in caso di descrittore
-    non valido \var{errno} assumerà il valore \errval{EBADF}, il valore
+    non valido \var{errno} assumerà il valore \errval{EBADF}, il valore
     \val{NULL} viene restituito anche quando si raggiunge la fine dello
     stream.}
 \end{functions}
 
 La funzione legge la voce corrente nella directory, posizionandosi sulla voce
 successiva. Pertanto se si vuole leggere l'intero contenuto di una directory
-occorrerà ripetere l'esecuzione della funzione fintanto che non si siano
+occorrerà ripetere l'esecuzione della funzione fintanto che non si siano
 esaurite tutte le voci in essa presenti.
 
 I dati vengono memorizzati in una struttura \struct{dirent} (la cui
-definizione\footnote{la definizione è quella usata a Linux, che si trova nel
+definizione\footnote{la definizione è quella usata a Linux, che si trova nel
   file \file{/usr/include/bits/dirent.h}, essa non contempla la presenza del
   campo \var{d\_namlen} che indica la lunghezza del nome del file (ed infatti
-  la macro \macro{\_DIRENT\_HAVE\_D\_NAMLEN} non è definita).}  è riportata in
+  la macro \macro{\_DIRENT\_HAVE\_D\_NAMLEN} non è definita).}  è riportata in
 fig.~\ref{fig:file_dirent_struct}). La funzione restituisce il puntatore alla
-struttura; si tenga presente però che quest'ultima è allocata staticamente,
+struttura; si tenga presente però che quest'ultima è allocata staticamente,
 per cui viene sovrascritta tutte le volte che si ripete la lettura di una voce
 sullo stesso \textit{directory stream}.
 
 Di questa funzione esiste anche una versione \index{funzioni!rientranti}
 rientrante, \func{readdir\_r}, che non usa una struttura allocata
-staticamente, e può essere utilizzata anche con i \itindex{thread}
-\textit{thread}, il suo prototipo è:
+staticamente, e può essere utilizzata anche con i \itindex{thread}
+\textit{thread}, il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} \headdecl{dirent.h} 
   
@@ -922,7 +922,7 @@ La funzione restituisce in \param{result} (come
 \itindex{value~result~argument} \textit{value result argument}) l'indirizzo
 dove sono stati salvati i dati, che di norma corrisponde a quello della
 struttura precedentemente allocata e specificata dall'argomento \param{entry}
-(anche se non è assicurato che la funzione usi lo spazio fornito dall'utente).
+(anche se non è assicurato che la funzione usi lo spazio fornito dall'utente).
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -938,18 +938,18 @@ struttura precedentemente allocata e specificata dall'argomento \param{entry}
 I vari campi di \struct{dirent} contengono le informazioni relative alle voci
 presenti nella directory; sia BSD che SVr4\footnote{lo standard POSIX prevede
   invece solo la presenza del campo \var{d\_fileno}, identico \var{d\_ino},
-  che in Linux è definito come alias di quest'ultimo. Il campo \var{d\_name} è
+  che in Linux è definito come alias di quest'ultimo. Il campo \var{d\_name} è
   considerato dipendente dall'implementazione.} prevedono che siano sempre
 presenti il campo \var{d\_name}, che contiene il nome del file nella forma di
 una stringa terminata da uno zero,\footnote{lo standard POSIX non specifica
   una lunghezza, ma solo un limite \const{NAME\_MAX}; in SVr4 la lunghezza del
-  campo è definita come \code{NAME\_MAX+1} che di norma porta al valore di 256
+  campo è definita come \code{NAME\_MAX+1} che di norma porta al valore di 256
   byte usato anche in Linux.} ed il campo \var{d\_ino}, che contiene il numero
-di \itindex{inode} \textit{inode} cui il file è associato (di solito
+di \itindex{inode} \textit{inode} cui il file è associato (di solito
 corrisponde al campo \var{st\_ino} di \struct{stat}).
 
-La presenza di ulteriori campi opzionali è segnalata dalla definizione di
-altrettante macro nella forma \code{\_DIRENT\_HAVE\_D\_XXX} dove \code{XXX} è
+La presenza di ulteriori campi opzionali è segnalata dalla definizione di
+altrettante macro nella forma \code{\_DIRENT\_HAVE\_D\_XXX} dove \code{XXX} è
 il nome del relativo campo; nel nostro caso sono definite le macro
 \macro{\_DIRENT\_HAVE\_D\_TYPE}, \macro{\_DIRENT\_HAVE\_D\_OFF} e
 \macro{\_DIRENT\_HAVE\_D\_RECLEN}.
@@ -998,16 +998,16 @@ letta. Con questi due campi diventa possibile, determinando la posizione delle
 varie voci, spostarsi all'interno dello stream usando la funzione
 \funcd{seekdir},\footnote{sia questa funzione che \func{telldir}, sono
   estensioni prese da BSD, non previste dallo standard POSIX.} il cui
-prototipo è:
+prototipo è:
 \begin{prototype}{dirent.h}{void seekdir(DIR *dir, off\_t offset)}
   Cambia la posizione all'interno di un \textit{directory stream}.
 \end{prototype}
 
-La funzione non ritorna nulla e non segnala errori, è però necessario che il
+La funzione non ritorna nulla e non segnala errori, è però necessario che il
 valore dell'argomento \param{offset} sia valido per lo stream \param{dir};
 esso pertanto deve essere stato ottenuto o dal valore di \var{d\_off} di
 \struct{dirent} o dal valore restituito dalla funzione \funcd{telldir}, che
-legge la posizione corrente; il prototipo di quest'ultima è:
+legge la posizione corrente; il prototipo di quest'ultima è:
 \begin{prototype}{dirent.h}{off\_t telldir(DIR *dir)}
   Ritorna la posizione corrente in un \textit{directory stream}.
   
@@ -1018,8 +1018,8 @@ legge la posizione corrente; il prototipo di quest'ultima 
 \end{prototype}
 
 La sola funzione di posizionamento nello stream prevista dallo standard POSIX
-è \funcd{rewinddir}, che riporta la posizione a quella iniziale; il suo
-prototipo è:
+è \funcd{rewinddir}, che riporta la posizione a quella iniziale; il suo
+prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} \headdecl{dirent.h} 
   
@@ -1029,8 +1029,8 @@ prototipo 
 \end{functions}
 
 
-Una volta completate le operazioni si può chiudere il \textit{directory
-  stream} con la funzione \funcd{closedir}, il cui prototipo è:
+Una volta completate le operazioni si può chiudere il \textit{directory
+  stream} con la funzione \funcd{closedir}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} \headdecl{dirent.h} 
   
@@ -1042,11 +1042,11 @@ Una volta completate le operazioni si pu
     qual caso \var{errno} assume il valore \errval{EBADF}.}
 \end{functions}
 
-A parte queste funzioni di base in BSD 4.3 è stata introdotta un'altra
+A parte queste funzioni di base in BSD 4.3 è stata introdotta un'altra
 funzione che permette di eseguire una scansione completa (con tanto di ricerca
-ed ordinamento) del contenuto di una directory; la funzione è
-\funcd{scandir}\footnote{in Linux questa funzione è stata introdotta fin dalle
-  \acr{libc4}.} ed il suo prototipo è:
+ed ordinamento) del contenuto di una directory; la funzione è
+\funcd{scandir}\footnote{in Linux questa funzione è stata introdotta fin dalle
+  \acr{libc4}.} ed il suo prototipo è:
 \begin{prototype}{dirent.h}{int scandir(const char *dir, 
     struct dirent ***namelist, int(*filter)(const struct dirent *),
     int(*compar)(const struct dirent **, const struct dirent **))} 
@@ -1058,7 +1058,7 @@ ed ordinamento) del contenuto di una directory; la funzione 
 \end{prototype}
 
 Al solito, per la presenza fra gli argomenti di due puntatori a funzione, il
-prototipo non è molto comprensibile; queste funzioni però sono quelle che
+prototipo non è molto comprensibile; queste funzioni però sono quelle che
 controllano rispettivamente la selezione di una voce (quella passata con
 l'argomento \param{filter}) e l'ordinamento di tutte le voci selezionate
 (quella specificata dell'argomento \param{compar}).
@@ -1071,7 +1071,7 @@ inserito in un vettore che viene allocato dinamicamente con \func{malloc}.
 Qualora si specifichi un valore \val{NULL} per l'argomento \func{filter} non
 viene fatta nessuna selezione e si ottengono tutte le voci presenti.
 
-Le voci selezionate possono essere riordinate tramite \func{qsort}, le modalità
+Le voci selezionate possono essere riordinate tramite \func{qsort}, le modalità
 del riordinamento possono essere personalizzate usando la funzione
 \param{compar} come criterio di ordinamento di \func{qsort}, la funzione
 prende come argomenti le due strutture \struct{dirent} da confrontare
@@ -1101,8 +1101,8 @@ Per l'ordinamento, vale a dire come valori possibili per l'argomento
     maggiore del secondo.}
 \end{functions}
 
-La funzione \func{alphasort} deriva da BSD ed è presente in Linux fin dalle
-\acr{libc4}\footnote{la versione delle \acr{libc4} e \acr{libc5} usa però come
+La funzione \func{alphasort} deriva da BSD ed è presente in Linux fin dalle
+\acr{libc4}\footnote{la versione delle \acr{libc4} e \acr{libc5} usa però come
   argomenti dei puntatori a delle strutture \struct{dirent}; le glibc usano il
   prototipo originario di BSD, mostrato anche nella definizione, che prevede
   puntatori a \ctyp{void}.} e deve essere specificata come argomento
@@ -1111,11 +1111,11 @@ campo \var{d\_name} delle varie voci). Le \acr{glibc} prevedono come
 estensione\footnote{le glibc, a partire dalla versione 2.1, effettuano anche
   l'ordinamento alfabetico tenendo conto delle varie localizzazioni, usando
   \func{strcoll} al posto di \func{strcmp}.} anche \func{versionsort}, che
-ordina i nomi tenendo conto del numero di versione (cioè qualcosa per cui
+ordina i nomi tenendo conto del numero di versione (cioè qualcosa per cui
 \texttt{file10} viene comunque dopo \texttt{file4}.)
 
-Un semplice esempio dell'uso di queste funzioni è riportato in
-fig.~\ref{fig:file_my_ls}, dove si è riportata la sezione principale di un
+Un semplice esempio dell'uso di queste funzioni è riportato in
+fig.~\ref{fig:file_my_ls}, dove si è riportata la sezione principale di un
 programma che, usando la funzione di scansione illustrata in
 fig.~\ref{fig:file_dirscan}, stampa i nomi dei file contenuti in una directory
 e la relativa dimensione (in sostanza una versione semplificata del comando
@@ -1131,25 +1131,25 @@ e la relativa dimensione (in sostanza una versione semplificata del comando
   \label{fig:file_my_ls}
 \end{figure}
 
-Il programma è estremamente semplice; in fig.~\ref{fig:file_my_ls} si è omessa
+Il programma è estremamente semplice; in fig.~\ref{fig:file_my_ls} si è omessa
 la parte di gestione delle opzioni (che prevede solo l'uso di una funzione per
-la stampa della sintassi, anch'essa omessa) ma il codice completo potrà essere
+la stampa della sintassi, anch'essa omessa) ma il codice completo potrà essere
 trovato coi sorgenti allegati nel file \file{myls.c}.
 
 In sostanza tutto quello che fa il programma, dopo aver controllato
-(\texttt{\small 10--13}) di avere almeno un argomento (che indicherà la
-directory da esaminare) è chiamare (\texttt{\small 14}) la funzione
+(\texttt{\small 10--13}) di avere almeno un argomento (che indicherà la
+directory da esaminare) è chiamare (\texttt{\small 14}) la funzione
 \func{DirScan} per eseguire la scansione, usando la funzione \code{do\_ls}
 (\texttt{\small 20--26}) per fare tutto il lavoro. 
 
 Quest'ultima si limita (\texttt{\small 23}) a chiamare \func{stat} sul file
-indicato dalla directory entry passata come argomento (il cui nome è appunto
+indicato dalla directory entry passata come argomento (il cui nome è appunto
 \var{direntry->d\_name}), memorizzando in una opportuna struttura \var{data} i
 dati ad esso relativi, per poi provvedere (\texttt{\small 24}) a stampare il
 nome del file e la dimensione riportata in \var{data}.  
 
-Dato che la funzione verrà chiamata all'interno di \func{DirScan} per ogni
-voce presente questo è sufficiente a stampare la lista completa dei file e
+Dato che la funzione verrà chiamata all'interno di \func{DirScan} per ogni
+voce presente questo è sufficiente a stampare la lista completa dei file e
 delle relative dimensioni.  Si noti infine come si restituisca sempre 0 come
 valore di ritorno per indicare una esecuzione senza errori.
 
@@ -1163,19 +1163,19 @@ valore di ritorno per indicare una esecuzione senza errori.
   \label{fig:file_dirscan}
 \end{figure}
 
-Tutto il grosso del lavoro è svolto dalla funzione \func{DirScan}, riportata
-in fig.~\ref{fig:file_dirscan}. La funzione è volutamente generica e permette
+Tutto il grosso del lavoro è svolto dalla funzione \func{DirScan}, riportata
+in fig.~\ref{fig:file_dirscan}. La funzione è volutamente generica e permette
 di eseguire una funzione, passata come secondo argomento, su tutte le voci di
 una directory.  La funzione inizia con l'aprire (\texttt{\small 19--23}) uno
 stream sulla directory passata come primo argomento, stampando un messaggio in
 caso di errore.
 
-Il passo successivo (\texttt{\small 24--25}) è cambiare directory di lavoro
+Il passo successivo (\texttt{\small 24--25}) è cambiare directory di lavoro
 (vedi sez.~\ref{sec:file_work_dir}), usando in sequenza le funzione
-\func{dirfd} e \func{fchdir} (in realtà si sarebbe potuto usare direttamente
+\func{dirfd} e \func{fchdir} (in realtà si sarebbe potuto usare direttamente
 \func{chdir} su \var{dirname}), in modo che durante il successivo ciclo
 (\texttt{\small 27--31}) sulle singole voci dello stream ci si trovi
-all'interno della directory.\footnote{questo è essenziale al funzionamento
+all'interno della directory.\footnote{questo è essenziale al funzionamento
   della funzione \code{do\_ls} (e ad ogni funzione che debba usare il campo
   \var{d\_name}, in quanto i nomi dei file memorizzati all'interno di una
   struttura \struct{dirent} sono sempre relativi alla directory in questione,
@@ -1184,16 +1184,16 @@ all'interno della directory.\footnote{questo 
 
 Avendo usato lo stratagemma di fare eseguire tutte le manipolazioni necessarie
 alla funzione passata come secondo argomento, il ciclo di scansione della
-directory è molto semplice; si legge una voce alla volta (\texttt{\small 27})
+directory è molto semplice; si legge una voce alla volta (\texttt{\small 27})
 all'interno di una istruzione di \code{while} e fintanto che si riceve una
-voce valida (cioè un puntatore diverso da \val{NULL}) si esegue
+voce valida (cioè un puntatore diverso da \val{NULL}) si esegue
 (\texttt{\small 27}) la funzione di elaborazione \var{compare} (che nel nostro
-caso sarà \code{do\_ls}), ritornando con un codice di errore (\texttt{\small
+caso sarà \code{do\_ls}), ritornando con un codice di errore (\texttt{\small
   28}) qualora questa presenti una anomalia (identificata da un codice di
 ritorno negativo). Una volta terminato il ciclo la funzione si conclude con la
 chiusura (\texttt{\small 32}) dello stream\footnote{nel nostro caso, uscendo
-  subito dopo la chiamata, questo non servirebbe, in generale però
-  l'operazione è necessaria, dato che la funzione può essere invocata molte
+  subito dopo la chiamata, questo non servirebbe, in generale però
+  l'operazione è necessaria, dato che la funzione può essere invocata molte
   volte all'interno dello stesso processo, per cui non chiudere i
   \textit{directory stream} comporterebbe un consumo progressivo di risorse,
   con conseguente rischio di esaurimento delle stesse.} e la restituzione
@@ -1205,14 +1205,14 @@ chiusura (\texttt{\small 32}) dello stream\footnote{nel nostro caso, uscendo
 
 \itindbeg{pathname}
 
-Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una
+Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una
 directory nel filesystem,\footnote{questa viene mantenuta all'interno dei dati
-  della sua \struct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
+  della sua \struct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
   precisamente nel campo \texttt{pwd} della sotto-struttura
-  \struct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
+  \struct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
 \textsl{directory di lavoro} (in inglese \textit{current working directory}).
-La directory di lavoro è quella da cui si parte quando un
-\itindsub{pathname}{relativo} \textit{pathname} è espresso in forma relativa,
+La directory di lavoro è quella da cui si parte quando un
+\itindsub{pathname}{relativo} \textit{pathname} è espresso in forma relativa,
 dove il ``\textsl{relativa}'' fa riferimento appunto a questa directory.
 
 Quando un utente effettua il login, questa directory viene impostata alla
@@ -1223,28 +1223,28 @@ resta la stessa quando viene creato un processo figlio (vedi
 sez.~\ref{sec:proc_fork}), la directory corrente della shell diventa anche la
 directory corrente di qualunque comando da essa lanciato.
 
-Dato che è il kernel che tiene traccia per ciascun processo \itindex{inode}
+Dato che è il kernel che tiene traccia per ciascun processo \itindex{inode}
 dell'\textit{inode} della directory di lavoro, per ottenerne il
 \textit{pathname} occorre usare una apposita funzione di libreria,
-\funcd{getcwd},\footnote{con Linux \func{getcwd} è una \textit{system call}
+\funcd{getcwd},\footnote{con Linux \func{getcwd} è una \textit{system call}
   dalla versione 2.1.9, in precedenza il valore doveva essere ottenuto tramite
   il filesystem \texttt{/proc} da \procfile{/proc/self/cwd}.} il cui prototipo
-è:
+è:
 \begin{prototype}{unistd.h}{char *getcwd(char *buffer, size\_t size)}
   Legge il \textit{pathname} della directory di lavoro corrente.
   
   \bodydesc{La funzione restituisce il puntatore \param{buffer} se riesce,
     \val{NULL} se fallisce, in quest'ultimo caso la variabile
-    \var{errno} è impostata con i seguenti codici di errore:
+    \var{errno} è impostata con i seguenti codici di errore:
   \begin{errlist}
-  \item[\errcode{EINVAL}] l'argomento \param{size} è zero e \param{buffer} non
-    è nullo.
-  \item[\errcode{ERANGE}] l'argomento \param{size} è più piccolo della
+  \item[\errcode{EINVAL}] l'argomento \param{size} è zero e \param{buffer} non
+    è nullo.
+  \item[\errcode{ERANGE}] l'argomento \param{size} è più piccolo della
     lunghezza del \textit{pathname}. 
   \item[\errcode{EACCES}] manca il permesso di lettura o di ricerca su uno dei
-    componenti del \textit{pathname} (cioè su una delle directory superiori
+    componenti del \textit{pathname} (cioè su una delle directory superiori
     alla corrente).
-  \item[\errcode{ENOENT}] la directory di lavoro è stata eliminata.
+  \item[\errcode{ENOENT}] la directory di lavoro è stata eliminata.
   \end{errlist}}
 \end{prototype}
 
@@ -1252,52 +1252,52 @@ La funzione restituisce il \textit{pathname} completo della directory di
 lavoro corrente nella stringa puntata da \param{buffer}, che deve essere
 precedentemente allocata, per una dimensione massima di \param{size}.  Il
 buffer deve essere sufficientemente largo da poter contenere il
-\textit{pathname} completo più lo zero di terminazione della stringa. Qualora
+\textit{pathname} completo più lo zero di terminazione della stringa. Qualora
 esso ecceda le dimensioni specificate con \param{size} la funzione restituisce
 un errore.
 
-Si può anche specificare un puntatore nullo come
-\param{buffer},\footnote{questa è un'estensione allo standard POSIX.1,
-  supportata da Linux e dalla \acr{glibc}.} nel qual caso la stringa sarà
+Si può anche specificare un puntatore nullo come
+\param{buffer},\footnote{questa è un'estensione allo standard POSIX.1,
+  supportata da Linux e dalla \acr{glibc}.} nel qual caso la stringa sarà
 allocata automaticamente per una dimensione pari a \param{size} qualora questa
 sia diversa da zero, o della lunghezza esatta del \textit{pathname}
 altrimenti. In questo caso ci si deve ricordare di disallocare la stringa una
 volta cessato il suo utilizzo.
 
 Di questa funzione esiste una versione \code{char *getwd(char *buffer)} fatta
-per compatibilità all'indietro con BSD, che non consente di specificare la
+per compatibilità all'indietro con BSD, che non consente di specificare la
 dimensione del buffer; esso deve essere allocato in precedenza ed avere una
 dimensione superiore a \const{PATH\_MAX} (di solito 256 byte, vedi
-sez.~\ref{sec:sys_limits}); il problema è che in Linux non esiste una
-dimensione superiore per un \textit{pathname}, per cui non è detto che il
-buffer sia sufficiente a contenere il nome del file, e questa è la ragione
-principale per cui questa funzione è deprecata.
+sez.~\ref{sec:sys_limits}); il problema è che in Linux non esiste una
+dimensione superiore per un \textit{pathname}, per cui non è detto che il
+buffer sia sufficiente a contenere il nome del file, e questa è la ragione
+principale per cui questa funzione è deprecata.
 
-Un uso comune di \func{getcwd} è quello di salvare la directory di lavoro
+Un uso comune di \func{getcwd} è quello di salvare la directory di lavoro
 iniziale per poi potervi tornare in un tempo successivo, un metodo alternativo
-più veloce, se non si è a corto di file descriptor, è invece quello di aprire
+più veloce, se non si è a corto di file descriptor, è invece quello di aprire
 la directory corrente (vale a dire ``\texttt{.}'') e tornarvi in seguito con
 \func{fchdir}. 
 
-Una seconda usata per ottenere la directory di lavoro è \code{char
-  *get\_current\_dir\_name(void)} che è sostanzialmente equivalente ad una
+Una seconda usata per ottenere la directory di lavoro è \code{char
+  *get\_current\_dir\_name(void)} che è sostanzialmente equivalente ad una
 \code{getcwd(NULL, 0)}, con la sola differenza che essa ritorna il valore
-della variabile di ambiente \val{PWD}, che essendo costruita dalla shell può
+della variabile di ambiente \val{PWD}, che essendo costruita dalla shell può
 contenere un \textit{pathname} comprendente anche dei link simbolici. Usando
 \func{getcwd} infatti, essendo il \textit{pathname} ricavato risalendo
 all'indietro l'albero della directory, si perderebbe traccia di ogni passaggio
 attraverso eventuali link simbolici.
 
-Per cambiare la directory di lavoro si può usare la funzione \funcd{chdir}
+Per cambiare la directory di lavoro si può usare la funzione \funcd{chdir}
 (equivalente del comando di shell \cmd{cd}) il cui nome sta appunto per
-\textit{change directory}, il suo prototipo è:
+\textit{change directory}, il suo prototipo è:
 \begin{prototype}{unistd.h}{int chdir(const char *pathname)} 
   Cambia la directory di lavoro in \param{pathname}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore,
-    nel qual caso \var{errno} assumerà i valori:
+    nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
-  \item[\errcode{ENOTDIR}] non si è specificata una directory.
+  \item[\errcode{ENOTDIR}] non si è specificata una directory.
   \item[\errcode{EACCES}] manca il permesso di ricerca su uno dei componenti
     di \param{path}.
   \end{errlist}
@@ -1307,20 +1307,20 @@ Per cambiare la directory di lavoro si pu
 \noindent ed ovviamente \param{pathname} deve indicare una directory per la
 quale si hanno i permessi di accesso.
 
-Dato che anche le directory sono file, è possibile riferirsi ad esse anche
+Dato che anche le directory sono file, è possibile riferirsi ad esse anche
 tramite il file descriptor, e non solo tramite il \textit{pathname}, per fare
-questo si usa \funcd{fchdir}, il cui prototipo è:
+questo si usa \funcd{fchdir}, il cui prototipo è:
 \begin{prototype}{unistd.h}{int fchdir(int fd)} 
   Identica a \func{chdir}, ma usa il file descriptor \param{fd} invece del
   \textit{pathname}.
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
-    errore, in caso di errore \var{errno} assumerà i valori \errval{EBADF} o
+    errore, in caso di errore \var{errno} assumerà i valori \errval{EBADF} o
     \errval{EACCES}.}
 \end{prototype}
 \noindent anche in questo caso \param{fd} deve essere un file descriptor
 valido che fa riferimento ad una directory. Inoltre l'unico errore di accesso
-possibile (tutti gli altri sarebbero occorsi all'apertura di \param{fd}), è
+possibile (tutti gli altri sarebbero occorsi all'apertura di \param{fd}), è
 quello in cui il processo non ha il permesso di accesso alla directory
 specificata da \param{fd}.
 
@@ -1331,8 +1331,8 @@ specificata da \param{fd}.
 \subsection{I file temporanei}
 \label{sec:file_temp_file}
 
-In molte occasioni è utile poter creare dei file temporanei; benché la cosa
-sembri semplice, in realtà il problema è più sottile di quanto non appaia a
+In molte occasioni è utile poter creare dei file temporanei; benché la cosa
+sembri semplice, in realtà il problema è più sottile di quanto non appaia a
 prima vista. Infatti anche se sembrerebbe banale generare un nome a caso e
 creare il file dopo aver controllato che questo non esista, nel momento fra il
 controllo e la creazione si ha giusto lo spazio per una possibile
@@ -1340,8 +1340,8 @@ controllo e la creazione si ha giusto lo spazio per una possibile
 sez.~\ref{sec:proc_race_cond}).
 
 Le \acr{glibc} provvedono varie funzioni per generare nomi di file temporanei,
-di cui si abbia certezza di unicità (al momento della generazione); la prima
-di queste funzioni è \funcd{tmpnam} il cui prototipo è:
+di cui si abbia certezza di unicità (al momento della generazione); la prima
+di queste funzioni è \funcd{tmpnam} il cui prototipo è:
 \begin{prototype}{stdio.h}{char *tmpnam(char *string)}
   Restituisce il puntatore ad una stringa contente un nome di file valido e
   non esistente al momento dell'invocazione. 
@@ -1349,11 +1349,11 @@ di queste funzioni 
   \bodydesc{La funzione ritorna il puntatore alla stringa con il nome o
   \val{NULL} in caso di fallimento. Non sono definiti errori.}
 \end{prototype}
-\noindent se si è passato un puntatore \param{string} non nullo questo deve
+\noindent se si è passato un puntatore \param{string} non nullo questo deve
 essere di dimensione \const{L\_tmpnam} (costante definita in \file{stdio.h},
-come \const{P\_tmpdir} e \const{TMP\_MAX}) ed il nome generato vi verrà
-copiato automaticamente; altrimenti il nome sarà generato in un buffer statico
-interno che verrà sovrascritto ad una chiamata successiva.  Successive
+come \const{P\_tmpdir} e \const{TMP\_MAX}) ed il nome generato vi verrà
+copiato automaticamente; altrimenti il nome sarà generato in un buffer statico
+interno che verrà sovrascritto ad una chiamata successiva.  Successive
 invocazioni della funzione continueranno a restituire nomi unici fino ad un
 massimo di \const{TMP\_MAX} volte. Al nome viene automaticamente aggiunto come
 prefisso la directory specificata da \const{P\_tmpdir}.
@@ -1361,7 +1361,7 @@ prefisso la directory specificata da \const{P\_tmpdir}.
 Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
 \func{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
 Una funzione simile, \funcd{tempnam}, permette di specificare un prefisso per
-il file esplicitamente, il suo prototipo è:
+il file esplicitamente, il suo prototipo è:
 \begin{prototype}{stdio.h}{char *tempnam(const char *dir, const char *pfx)}
   Restituisce il puntatore ad una stringa contente un nome di file valido e
   non esistente al momento dell'invocazione.
@@ -1372,124 +1372,124 @@ il file esplicitamente, il suo prototipo 
 \end{prototype}
 
 La funzione alloca con \code{malloc} la stringa in cui restituisce il nome,
-per cui è sempre \index{funzioni!rientranti} rientrante, occorre però
+per cui è sempre \index{funzioni!rientranti} rientrante, occorre però
 ricordarsi di disallocare con \code{free} il puntatore che restituisce.
 L'argomento \param{pfx} specifica un prefisso di massimo 5 caratteri per il
 nome provvisorio. La funzione assegna come directory per il file temporaneo
 (verificando che esista e sia accessibili), la prima valida delle seguenti:
 \begin{itemize}
-\item La variabile di ambiente \const{TMPDIR} (non ha effetto se non è
-  definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
+\item La variabile di ambiente \const{TMPDIR} (non ha effetto se non è
+  definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
   \itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_special_perm}).
 \item il valore dell'argomento \param{dir} (se diverso da \val{NULL}).
 \item Il valore della costante \const{P\_tmpdir}.
 \item la directory \file{/tmp}.
 \end{itemize}
 
-In ogni caso, anche se la generazione del nome è casuale, ed è molto difficile
+In ogni caso, anche se la generazione del nome è casuale, ed è molto difficile
 ottenere un nome duplicato, nulla assicura che un altro processo non possa
 avere creato, fra l'ottenimento del nome e l'apertura del file, un altro file
 con lo stesso nome; per questo motivo quando si usa il nome ottenuto da una di
-queste funzioni occorre sempre aprire il nuovo file in modalità di esclusione
-(cioè con l'opzione \const{O\_EXCL} per i file descriptor o con il flag
-\code{x} per gli stream) che fa fallire l'apertura in caso il file sia già
+queste funzioni occorre sempre aprire il nuovo file in modalità di esclusione
+(cioè con l'opzione \const{O\_EXCL} per i file descriptor o con il flag
+\code{x} per gli stream) che fa fallire l'apertura in caso il file sia già
 esistente.
 
 Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
 POSIX definisce la funzione \funcd{tmpfile}, che permette di ottenere in
-maniera sicura l'accesso ad un file temporaneo, il suo prototipo è:
+maniera sicura l'accesso ad un file temporaneo, il suo prototipo è:
 \begin{prototype}{stdio.h}{FILE *tmpfile (void)}
   Restituisce un file temporaneo aperto in lettura/scrittura.
   
   \bodydesc{La funzione ritorna il puntatore allo stream associato al file
     temporaneo in caso di successo e \val{NULL} in caso di errore, nel qual
-    caso \var{errno} assumerà i valori:
+    caso \var{errno} assumerà i valori:
     \begin{errlist}
-    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
-    \item[\errcode{EEXIST}] non è stato possibile generare un nome univoco.
+    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+    \item[\errcode{EEXIST}] non è stato possibile generare un nome univoco.
     \end{errlist}
     ed inoltre \errval{EFAULT}, \errval{EMFILE}, \errval{ENFILE},
     \errval{ENOSPC}, \errval{EROFS} e \errval{EACCES}.}
 \end{prototype}
 
-La funzione restituisce direttamente uno stream già aperto (in modalità
+La funzione restituisce direttamente uno stream già aperto (in modalità
 \code{r+b}, si veda sez.~\ref{sec:file_fopen}) e pronto per l'uso, che viene
 automaticamente cancellato alla sua chiusura o all'uscita dal programma. Lo
-standard non specifica in quale directory verrà aperto il file, ma le
+standard non specifica in quale directory verrà aperto il file, ma le
 \acr{glibc} prima tentano con \const{P\_tmpdir} e poi con \file{/tmp}. Questa
-funzione è \index{funzioni!rientranti} rientrante e non soffre di problemi di
+funzione è \index{funzioni!rientranti} rientrante e non soffre di problemi di
 \itindex{race~condition} \textit{race condition}.
 
 Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
 caso si possono usare le vecchie funzioni \funcd{mktemp} e \func{mkstemp} che
 modificano una stringa di input che serve da modello e che deve essere
 conclusa da 6 caratteri \code{X} che verranno sostituiti da un codice
-unico. La prima delle due è analoga a \func{tmpnam} e genera un nome casuale,
-il suo prototipo è:
+unico. La prima delle due è analoga a \func{tmpnam} e genera un nome casuale,
+il suo prototipo è:
 \begin{prototype}{stlib.h}{char *mktemp(char *template)}
   Genera un filename univoco sostituendo le \code{XXXXXX} finali di
   \param{template}.
   
   \bodydesc{La funzione ritorna il puntatore \param{template} in caso di
     successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
-    assumerà i valori:
+    assumerà i valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
     \end{errlist}}
 \end{prototype}
 \noindent dato che \param{template} deve poter essere modificata dalla
-funzione non si può usare una stringa costante.  Tutte le avvertenze riguardo
+funzione non si può usare una stringa costante.  Tutte le avvertenze riguardo
 alle possibili \itindex{race~condition} \textit{race condition} date per
 \func{tmpnam} continuano a valere; inoltre in alcune vecchie implementazioni
 il valore usato per sostituire le \code{XXXXXX} viene formato con il \acr{pid}
-del processo più una lettera, il che mette a disposizione solo 26 possibilità
+del processo più una lettera, il che mette a disposizione solo 26 possibilità
 diverse per il nome del file, e rende il nome temporaneo facile da indovinare.
-Per tutti questi motivi la funzione è deprecata e non dovrebbe mai essere
+Per tutti questi motivi la funzione è deprecata e non dovrebbe mai essere
 usata.
 
-La seconda funzione, \funcd{mkstemp} è sostanzialmente equivalente a
+La seconda funzione, \funcd{mkstemp} è sostanzialmente equivalente a
 \func{tmpfile}, ma restituisce un file descriptor invece di uno stream; il suo
-prototipo è:
+prototipo è:
 \begin{prototype}{stlib.h}{int mkstemp(char *template)}
   Genera un file temporaneo con un nome ottenuto sostituendo le \code{XXXXXX}
   finali di \param{template}.
   
   \bodydesc{La funzione ritorna il file descriptor in caso successo e
-    -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
+    -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
-    \item[\errcode{EEXIST}] non è riuscita a creare un file temporaneo, il
-      contenuto di \param{template} è indefinito.
+    \item[\errcode{EEXIST}] non è riuscita a creare un file temporaneo, il
+      contenuto di \param{template} è indefinito.
     \end{errlist}}
 \end{prototype}
-\noindent come per \func{mktemp} anche in questo caso \param{template} non può
+\noindent come per \func{mktemp} anche in questo caso \param{template} non può
 essere una stringa costante. La funzione apre un file in lettura/scrittura con
 la funzione \func{open}, usando l'opzione \const{O\_EXCL} (si veda
 sez.~\ref{sec:file_open}), in questo modo al ritorno della funzione si ha la
 certezza di essere i soli utenti del file. I permessi sono impostati al valore
-\code{0600}\footnote{questo è vero a partire dalle \acr{glibc} 2.0.7, le
+\code{0600}\footnote{questo è vero a partire dalle \acr{glibc} 2.0.7, le
   versioni precedenti delle \acr{glibc} e le vecchie \acr{libc5} e \acr{libc4}
   usavano il valore \code{0666} che permetteva a chiunque di leggere i
   contenuti del file.} (si veda sez.~\ref{sec:file_perm_overview}).
 
-In OpenBSD è stata introdotta un'altra funzione\footnote{introdotta anche in
+In OpenBSD è stata introdotta un'altra funzione\footnote{introdotta anche in
   Linux a partire dalle \acr{glibc} 2.1.91.} simile alle precedenti,
-\funcd{mkdtemp}, che crea una directory temporanea; il suo prototipo è:
+\funcd{mkdtemp}, che crea una directory temporanea; il suo prototipo è:
 \begin{prototype}{stlib.h}{char *mkdtemp(char *template)}
-  Genera una directory temporaneo il cui nome è ottenuto sostituendo le
+  Genera una directory temporaneo il cui nome è ottenuto sostituendo le
   \code{XXXXXX} finali di \param{template}.
   
   \bodydesc{La funzione ritorna il puntatore al nome della directory in caso
     successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
-    assumerà i valori:
+    assumerà i valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
     \end{errlist}
-    più gli altri eventuali codici di errore di \func{mkdir}.}
+    più gli altri eventuali codici di errore di \func{mkdir}.}
 \end{prototype}
-\noindent la directory è creata con permessi \code{0700} (al solito si veda
+\noindent la directory è creata con permessi \code{0700} (al solito si veda
 cap.~\ref{cha:file_unix_interface} per i dettagli); dato che la creazione
-della directory è sempre esclusiva i precedenti problemi di
+della directory è sempre esclusiva i precedenti problemi di
 \itindex{race~condition} \textit{race condition} non si pongono.
 
 
@@ -1512,9 +1512,9 @@ sez.~\ref{sec:file_access_control}).
 \subsection{La lettura delle caratteristiche dei file}
 \label{sec:file_stat}
 
-La lettura delle informazioni relative ai file è fatta attraverso la famiglia
+La lettura delle informazioni relative ai file è fatta attraverso la famiglia
 delle funzioni \func{stat} (\funcd{stat}, \funcd{fstat} e \funcd{lstat});
-questa è la funzione che ad esempio usa il comando \cmd{ls} per poter ottenere
+questa è la funzione che ad esempio usa il comando \cmd{ls} per poter ottenere
 e mostrare tutti i dati relativi ad un file. I prototipi di queste funzioni
 sono i seguenti:
 \begin{functions}
@@ -1527,7 +1527,7 @@ sono i seguenti:
   \param{buf}.
   
   \funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a
-  \func{stat} eccetto che se il \param{file\_name} è un link simbolico vengono
+  \func{stat} eccetto che se il \param{file\_name} è un link simbolico vengono
   lette le informazioni relative ad esso e non al file a cui fa riferimento.
   
   \funcdecl{int fstat(int filedes, struct stat *buf)} Identica a \func{stat}
@@ -1535,19 +1535,19 @@ sono i seguenti:
   descriptor \param{filedes}.
   
   \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un
-    errore, nel qual caso \var{errno} assumerà uno dei valori: \errval{EBADF},
+    errore, nel qual caso \var{errno} assumerà uno dei valori: \errval{EBADF},
     \errval{ENOENT}, \errval{ENOTDIR}, \errval{ELOOP}, \errval{EFAULT},
     \errval{EACCES}, \errval{ENOMEM}, \errval{ENAMETOOLONG}.}
 \end{functions}
-\noindent il loro comportamento è identico, solo che operano rispettivamente
+\noindent il loro comportamento è identico, solo che operano rispettivamente
 su un file, su un link simbolico e su un file descriptor.
 
-La struttura \struct{stat} usata da queste funzioni è definita nell'header
+La struttura \struct{stat} usata da queste funzioni è definita nell'header
 \file{sys/stat.h} e in generale dipende dall'implementazione; la versione
-usata da Linux è mostrata in fig.~\ref{fig:file_stat_struct}, così come
-riportata dalla pagina di manuale di \func{stat}; in realtà la definizione
+usata da Linux è mostrata in fig.~\ref{fig:file_stat_struct}, così come
+riportata dalla pagina di manuale di \func{stat}; in realtà la definizione
 effettivamente usata nel kernel dipende dall'architettura e ha altri campi
-riservati per estensioni come tempi dei file più precisi (vedi
+riservati per estensioni come tempi dei file più precisi (vedi
 sez.~\ref{sec:file_file_times}), o per il padding dei campi.
 
 \begin{figure}[!htb]
@@ -1571,15 +1571,15 @@ tab.~\ref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.h}).
 
 Come riportato in tab.~\ref{tab:file_file_types} in Linux oltre ai file e alle
 directory esistono altri oggetti che possono stare su un filesystem.  Il tipo
-di file è ritornato dalla funzione \func{stat} come maschera binaria nel campo
+di file è ritornato dalla funzione \func{stat} come maschera binaria nel campo
 \var{st\_mode} (che contiene anche le informazioni relative ai permessi) di
 una struttura \struct{stat}.
 
-Dato che il valore numerico può variare a seconda delle implementazioni, lo
+Dato che il valore numerico può variare a seconda delle implementazioni, lo
 standard POSIX definisce un insieme di macro per verificare il tipo di file,
 queste vengono usate anche da Linux che supporta pure le estensioni allo
 standard per i link simbolici e i socket definite da BSD; l'elenco completo
-delle macro con cui è possibile estrarre l'informazione da \var{st\_mode} è
+delle macro con cui è possibile estrarre l'informazione da \var{st\_mode} è
 riportato in tab.~\ref{tab:file_type_macro}.
 \begin{table}[htb]
   \centering
@@ -1602,13 +1602,13 @@ riportato in tab.~\ref{tab:file_type_macro}.
   \label{tab:file_type_macro}
 \end{table}
 
-Oltre alle macro di tab.~\ref{tab:file_type_macro} è possibile usare
+Oltre alle macro di tab.~\ref{tab:file_type_macro} è possibile usare
 direttamente il valore di \var{st\_mode} per ricavare il tipo di file
 controllando direttamente i vari bit in esso memorizzati. Per questo sempre in
 \file{sys/stat.h} sono definite le costanti numeriche riportate in
 tab.~\ref{tab:file_mode_flags}.
 
-Il primo valore dell'elenco di tab.~\ref{tab:file_mode_flags} è la maschera
+Il primo valore dell'elenco di tab.~\ref{tab:file_mode_flags} è la maschera
 binaria che permette di estrarre i bit nei quali viene memorizzato il tipo di
 file, i valori successivi sono le costanti corrispondenti ai singoli bit, e
 possono essere usati per effettuare la selezione sul tipo di file voluto, con
@@ -1657,7 +1657,7 @@ un'opportuna combinazione.
 \end{table}
 
 Ad esempio se si volesse impostare una condizione che permetta di controllare
-se un file è una directory o un file ordinario si potrebbe definire la macro
+se un file è una directory o un file ordinario si potrebbe definire la macro
 di preprocessore:
 \includecodesnip{listati/is_file_dir.h}
 in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e
@@ -1669,16 +1669,16 @@ poi si effettua il confronto con la combinazione di tipi scelta.
 
 Il campo \var{st\_size} di una struttura \struct{stat} contiene la dimensione
 del file in byte, se si tratta di un file regolare. Nel caso di un link
-simbolico la dimensione è quella del \itindex{pathname} \textit{pathname} che
-il link stesso contiene; per le fifo questo campo è sempre nullo.
+simbolico la dimensione è quella del \itindex{pathname} \textit{pathname} che
+il link stesso contiene; per le fifo questo campo è sempre nullo.
 
 Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
 byte. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
-i trasferimenti sui file (che è la dimensione usata anche dalle librerie del C
+i trasferimenti sui file (che è la dimensione usata anche dalle librerie del C
 per l'interfaccia degli stream); scrivere sul file a blocchi di dati di
 dimensione inferiore sarebbe inefficiente.
 
-Si tenga conto che la lunghezza del file riportata in \var{st\_size} non è
+Si tenga conto che la lunghezza del file riportata in \var{st\_size} non è
 detto che corrisponda all'occupazione dello spazio su disco per via della
 possibile esistenza dei cosiddetti \index{file!\textit{hole}} \textit{holes}
 (letteralmente \textsl{buchi}) che si formano tutte le volte che si va a
@@ -1688,18 +1688,18 @@ sua fine.
 
 In questo caso si avranno risultati differenti a seconda del modo in cui si
 calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
-numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
+numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
 legge dal file (ad esempio usando il comando \cmd{wc -c}), dato che in tal
-caso per le parti non scritte vengono restituiti degli zeri, si avrà lo stesso
+caso per le parti non scritte vengono restituiti degli zeri, si avrà lo stesso
 risultato di \cmd{ls}.
 
-Se è sempre possibile allargare un file, scrivendoci sopra od usando la
+Se è sempre possibile allargare un file, scrivendoci sopra od usando la
 funzione \func{lseek} per spostarsi oltre la sua fine, esistono anche casi in
-cui si può avere bisogno di effettuare un troncamento, scartando i dati
-presenti al di là della dimensione scelta come nuova fine del file.
+cui si può avere bisogno di effettuare un troncamento, scartando i dati
+presenti al di là della dimensione scelta come nuova fine del file.
 
-Un file può sempre essere troncato a zero aprendolo con il flag
-\const{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra
+Un file può sempre essere troncato a zero aprendolo con il flag
+\const{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra
 dimensione si possono usare le due funzioni \funcd{truncate} e
 \funcd{ftruncate}, i cui prototipi sono:
 \begin{functions}
@@ -1715,24 +1715,24 @@ dimensione si possono usare le due funzioni \funcd{truncate} e
     errore, nel qual caso \var{errno} viene impostata opportunamente; per
     \func{ftruncate} si hanno i valori:
   \begin{errlist}
-  \item[\errcode{EBADF}] \param{fd}  non è un file descriptor.
-  \item[\errcode{EINVAL}] \param{fd} è un riferimento ad un socket, non a un
-    file o non è aperto in scrittura.
+  \item[\errcode{EBADF}] \param{fd}  non è un file descriptor.
+  \item[\errcode{EINVAL}] \param{fd} è un riferimento ad un socket, non a un
+    file o non è aperto in scrittura.
   \end{errlist}
   per \func{truncate} si hanno:
   \begin{errlist}
   \item[\errcode{EACCES}] il file non ha permesso di scrittura o non si ha il
     permesso di esecuzione una delle directory del \itindex{pathname}
     \textit{pathname}.
-  \item[\errcode{ETXTBSY}] il file è un programma in esecuzione.
+  \item[\errcode{ETXTBSY}] il file è un programma in esecuzione.
   \end{errlist}
   ed anche \errval{ENOTDIR}, \errval{ENAMETOOLONG}, \errval{ENOENT},
   \errval{EROFS}, \errval{EIO}, \errval{EFAULT}, \errval{ELOOP}.}
 \end{functions}
 
-Se il file è più lungo della lunghezza specificata i dati in eccesso saranno
-perduti; il comportamento in caso di lunghezza inferiore non è specificato e
-dipende dall'implementazione: il file può essere lasciato invariato o esteso
+Se il file è più lungo della lunghezza specificata i dati in eccesso saranno
+perduti; il comportamento in caso di lunghezza inferiore non è specificato e
+dipende dall'implementazione: il file può essere lasciato invariato o esteso
 fino alla lunghezza scelta; nel caso di Linux viene esteso con la creazione di
 un \index{file!\textit{hole}} \textsl{buco} nel \itindex{sparse~file} file e
 ad una lettura si otterranno degli zeri.
@@ -1745,9 +1745,9 @@ Il sistema mantiene per ciascun file tre tempi. Questi sono registrati
 possono essere letti tramite la funzione \func{stat}, che li restituisce
 attraverso tre campi della struttura \struct{stat} di
 fig.~\ref{fig:file_stat_struct}. Il significato di detti tempi e dei relativi
-campi è riportato nello schema in tab.~\ref{tab:file_file_times}, dove è anche
+campi è riportato nello schema in tab.~\ref{tab:file_file_times}, dove è anche
 riportato un esempio delle funzioni che effettuano cambiamenti su di essi. Il
-valore è espresso nel cosiddetto \itindex{calendar~time} \textit{calendar
+valore è espresso nel cosiddetto \itindex{calendar~time} \textit{calendar
   time}, su cui torneremo in dettaglio in sez.~\ref{sec:sys_time}.
 
 \begin{table}[htb]
@@ -1771,7 +1771,7 @@ valore 
   \label{tab:file_file_times}
 \end{table}
 
-Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di
+Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di
 modifica (il \textit{modification time}, \var{st\_mtime}) e il tempo di
 cambiamento di stato (il \textit{change time}, \var{st\_ctime}). Il primo
 infatti fa riferimento ad una modifica del contenuto di un file, mentre il
@@ -1785,9 +1785,9 @@ Il tempo di ultima modifica viene usato ad esempio da programmi come
 \cmd{make} per decidere quali file necessitano di essere ricompilati o
 (talvolta insieme anche al tempo di cambiamento di stato) per decidere quali
 file devono essere archiviati per il backup. Il tempo di ultimo accesso viene
-di solito usato per identificare i file che non vengono più utilizzati per un
+di solito usato per identificare i file che non vengono più utilizzati per un
 certo lasso di tempo. Ad esempio un programma come \texttt{leafnode} lo usa
-per cancellare gli articoli letti più vecchi, mentre \texttt{mutt} lo usa per
+per cancellare gli articoli letti più vecchi, mentre \texttt{mutt} lo usa per
 marcare i messaggi di posta che risultano letti.  Il sistema non tiene conto
 dell'ultimo accesso \itindex{inode} all'\textit{inode}, pertanto funzioni come
 \func{access} o \func{stat} non hanno alcuna influenza sui tre tempi. Il
@@ -1795,8 +1795,8 @@ comando \cmd{ls} (quando usato con le opzioni \cmd{-l} o \cmd{-t}) mostra i
 tempi dei file secondo lo schema riportato nell'ultima colonna di
 tab.~\ref{tab:file_file_times}.
 
-L'aggiornamento del tempo di ultimo accesso è stato a lungo considerato un
-difetto progettuale di Unix, questo infatti comporta la necessità di
+L'aggiornamento del tempo di ultimo accesso è stato a lungo considerato un
+difetto progettuale di Unix, questo infatti comporta la necessità di
 effettuare un accesso in scrittura sul disco anche in tutti i casi in cui
 questa informazione non interessa e sarebbe possibile avere un semplice
 accesso in lettura sui dati bufferizzati. Questo comporta un ovvio costo sia
@@ -1804,26 +1804,26 @@ in termini di prestazioni, che di consumo di risorse come la batteria per i
 portatili, o cicli di riscrittura per i dischi su memorie riscrivibili.
 
 Per questo motivo, onde evitare di mantenere una informazione che nella
-maggior parte dei casi non interessa, è sempre stato possibile disabilitare
+maggior parte dei casi non interessa, è sempre stato possibile disabilitare
 l'aggiornamento del tempo di ultimo accesso con l'opzione di montaggio
-\texttt{noatime}. Dato però che questo può creare problemi a qualche
-programma, in Linux è stata introdotta la opzione \texttt{relatime} che esegue
-l'aggiornamento soltanto se il tempo di ultimo accesso è precedente al tempo di
-ultima modifica o cambiamento, così da rendere evidente che vi è stato un
+\texttt{noatime}. Dato però che questo può creare problemi a qualche
+programma, in Linux è stata introdotta la opzione \texttt{relatime} che esegue
+l'aggiornamento soltanto se il tempo di ultimo accesso è precedente al tempo di
+ultima modifica o cambiamento, così da rendere evidente che vi è stato un
 accesso dopo la scrittura, ed evitando al contempo ulteriori operazioni su
 disco negli accessi successivi. In questo modo l'informazione relativa al
 fatto che un file sia stato letto resta disponibile, e ad esempio i programmi
 citati in precedenza continuano a funzionare. Questa opzione, a partire dal
-kernel 2.6.30, è diventata il comportamento di default e non deve più essere
-specificata esplicitamente.\footnote{si può comunque riottenere il vecchio
+kernel 2.6.30, è diventata il comportamento di default e non deve più essere
+specificata esplicitamente.\footnote{si può comunque riottenere il vecchio
   comportamento usando la opzione di montaggio \texttt{strictatime}.}
 
-L'effetto delle varie funzioni di manipolazione dei file sui relativi tempi è
+L'effetto delle varie funzioni di manipolazione dei file sui relativi tempi è
 illustrato in tab.~\ref{tab:file_times_effects}, facendo riferimento al
 comportamento classico per quanto riguarda \var{st\_atime}. Si sono riportati
 gli effetti sia per il file a cui si fa riferimento, sia per la directory che
 lo contiene; questi ultimi possono essere capiti se si tiene conto di quanto
-già detto, e cioè che anche le directory sono file (che contengono una lista
+già detto, e cioè che anche le directory sono file (che contengono una lista
 di nomi) che il sistema tratta in maniera del tutto analoga a tutti gli altri.
 
 \begin{table}[htb]
@@ -1909,7 +1909,7 @@ di nomi) che il sistema tratta in maniera del tutto analoga a tutti gli altri.
 Per questo motivo tutte le volte che compiremo un'operazione su un file che
 comporta una modifica del nome contenuto nella directory, andremo anche a
 scrivere sulla directory che lo contiene cambiandone il tempo di modifica. Un
-esempio di questo può essere la cancellazione di un file, invece leggere o
+esempio di questo può essere la cancellazione di un file, invece leggere o
 scrivere o cambiare i permessi di un file ha effetti solo sui tempi di
 quest'ultimo.
 
@@ -1917,29 +1917,29 @@ Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di
 creazione del file, usato in molti altri sistemi operativi, ma che in Unix non
 esiste. Per questo motivo quando si copia un file, a meno di preservare
 esplicitamente i tempi (ad esempio con l'opzione \cmd{-p} di \cmd{cp}) esso
-avrà sempre il tempo corrente come data di ultima modifica.
+avrà sempre il tempo corrente come data di ultima modifica.
 
 I tempi di ultimo accesso e modifica possono essere modificati esplicitamente
-usando la funzione \funcd{utime}, il cui prototipo è:
+usando la funzione \funcd{utime}, il cui prototipo è:
 \begin{prototype}{utime.h}
   {int utime(const char *filename, struct utimbuf *times)} 
 
   Cambia i tempi di ultimo accesso e modifica \itindex{inode}
   dell'\textit{inode} specificato da \param{filename} secondo i valori dei
-  campi \var{actime} e \var{modtime} di \param{times}. Se questa è \val{NULL}
+  campi \var{actime} e \var{modtime} di \param{times}. Se questa è \val{NULL}
   allora viene usato il tempo corrente.
 
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
     \item[\errcode{EACCES}] non si ha il permesso di scrittura sul file.
-    \item[\errcode{EPERM}] non si è proprietari del file.
+    \item[\errcode{EPERM}] non si è proprietari del file.
     \end{errlist}
     ed inoltre \errval{EROFS} e \errval{ENOENT}.}
 \end{prototype}
 
 La funzione prende come argomento \param{times} una struttura
-\struct{utimbuf}, la cui definizione è riportata in
+\struct{utimbuf}, la cui definizione è riportata in
 fig.~\ref{fig:struct_utimebuf}, con la quale si possono specificare i nuovi
 valori che si vogliono impostare per tempi.
 
@@ -1955,24 +1955,24 @@ valori che si vogliono impostare per tempi.
 \end{figure}
 
 L'effetto della funzione e i privilegi necessari per eseguirla dipendono da
-cosa è l'argomento \param{times}; se è \val{NULL} la funzione imposta il
-tempo corrente ed è sufficiente avere accesso in scrittura al file; se invece
-si è specificato un valore la funzione avrà successo solo se si è proprietari
+cosa è l'argomento \param{times}; se è \val{NULL} la funzione imposta il
+tempo corrente ed è sufficiente avere accesso in scrittura al file; se invece
+si è specificato un valore la funzione avrà successo solo se si è proprietari
 del file (o si hanno i privilegi di amministratore).
 
-Si tenga presente che non è comunque possibile specificare il tempo di
+Si tenga presente che non è comunque possibile specificare il tempo di
 cambiamento di stato del file, che viene comunque cambiato dal kernel tutte le
 volte che si modifica \itindex{inode} l'\textit{inode} (quindi anche alla
 chiamata di \func{utime}).  Questo serve anche come misura di sicurezza per
 evitare che si possa modificare un file nascondendo completamente le proprie
-tracce. In realtà la cosa resta possibile, se si è in grado di accedere al
+tracce. In realtà la cosa resta possibile, se si è in grado di accedere al
 \index{file!di~dispositivo} file di dispositivo, scrivendo direttamente sul
 disco senza passare attraverso il filesystem, ma ovviamente in questo modo la
-cosa è molto più complicata da realizzare.
+cosa è molto più complicata da realizzare.
 
 A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di
-tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai
-nanosecondi per la gran parte dei filesystem. La ulteriore informazione può
+tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai
+nanosecondi per la gran parte dei filesystem. La ulteriore informazione può
 essere acceduta attraverso altri campi appositamente aggiunti alla struttura
 \struct{stat}. Se si sono definite le macro \macro{\_BSD\_SOURCE} o
 \macro{\_SVID\_SOURCE} questi sono \var{st\_atim.tv\_nsec},
@@ -1981,30 +1981,30 @@ essere acceduta attraverso altri campi appositamente aggiunti alla struttura
 supporto per questa maggior precisione sia assente questi campi aggiuntivi
 saranno nulli.
 
-Per la gestione di questi nuovi valori è stata definita una seconda funzione
+Per la gestione di questi nuovi valori è stata definita una seconda funzione
 di modifica, \funcd{utimes}, che consente di specificare tempi con maggior
-precisione; il suo prototipo è:
+precisione; il suo prototipo è:
 \begin{prototype}
   {sys/time.h}
   {int utimes(const char *filename, struct timeval times[2])} 
 
   Cambia i tempi di ultimo accesso e modifica \itindex{inode}
   dell'\textit{inode} specificato da \param{filename} secondo i valori
-  specificati da \param{times}. Se questo è \val{NULL} allora viene usato il
+  specificati da \param{times}. Se questo è \val{NULL} allora viene usato il
   tempo corrente.
 
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
     \item[\errcode{EACCES}] non si ha il permesso di scrittura sul file.
-    \item[\errcode{EPERM}] non si è proprietari del file.
+    \item[\errcode{EPERM}] non si è proprietari del file.
     \end{errlist} 
     ed inoltre \errval{EROFS} e \errval{ENOENT}.}
 \end{prototype}
 
-La funzione è del tutto analoga alla precedente \func{utime} ma usa come
+La funzione è del tutto analoga alla precedente \func{utime} ma usa come
 argomento \param{times}, un vettore di due strutture \struct{timeval}, la cui
-definizione è riportata in fig.~\ref{fig:sys_timeval_struct}, che consentono
+definizione è riportata in fig.~\ref{fig:sys_timeval_struct}, che consentono
 di indicare i tempi con una precisione del microsecondo. Il primo elemento
 di \param{times} indica il valore per il tempo di ultimo accesso, il secondo
 quello per il tempo di ultima modifica.
@@ -2024,30 +2024,30 @@ Oltre ad \func{utimes} su Linux sono presenti altre due funzioni,\footnote{le
   due funzioni non sono definite in nessuno standard, ma sono presenti, oltre
   che su Linux, anche su BSD.} \funcd{futimes} e \funcd{lutimes}, che
 consentono rispettivamente di effettuare la modifica utilizzando un file
-già aperto o di eseguirla direttamente su un link simbolico. I relativi
+già aperto o di eseguirla direttamente su un link simbolico. I relativi
 prototipi sono:
 \begin{functions}
   \headdecl{sys/time.h} 
   
   \funcdecl{int futimes(int fd, const struct timeval tv[2])} Cambia i tempi
-  di un file già aperto specificato tramite il file descriptor \param{fd}.
+  di un file già aperto specificato tramite il file descriptor \param{fd}.
 
   \funcdecl{int lutimes(const char *filename, const struct timeval tv[2])}
-  Cambia i tempi di \param{filename} anche se questo è un link simbolico.
+  Cambia i tempi di \param{filename} anche se questo è un link simbolico.
   
   
   \bodydesc{Le funzioni restituiscono zero in caso di successo e $-1$ per un
-    errore, nel qual caso \var{errno} assumerà gli stessi valori di
-    \func{utimes}, con in più per \func{futimes}:
+    errore, nel qual caso \var{errno} assumerà gli stessi valori di
+    \func{utimes}, con in più per \func{futimes}:
   \begin{errlist}
-  \item[\errcode{EBADF}] \param{fd}  non è un file descriptor.
-  \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile.
+  \item[\errcode{EBADF}] \param{fd}  non è un file descriptor.
+  \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile.
   \end{errlist}}
 \end{functions}
 
 Le due funzioni anno lo stesso comportamento di \texttt{utimes} e richiedono
-gli stessi privilegi per poter operare, la differenza è che con \func{futimes}
-si può indicare il file su cui operare facendo riferimento al relativo file
+gli stessi privilegi per poter operare, la differenza è che con \func{futimes}
+si può indicare il file su cui operare facendo riferimento al relativo file
 descriptor (tratteremo in dettaglio l'argomento in
 sez.~\ref{cha:file_unix_interface}) mentre con \func{lutimes} nel caso in
 cui \param{filename} sia un link simbolico saranno modificati i suoi tempi
@@ -2062,25 +2062,25 @@ compito; i rispettivi prototipi sono:
   \headdecl{sys/time.h} 
   
   \funcdecl{futimens(int fd, const struct timespec times[2])} Cambia i tempi
-  di un file già aperto, specificato dal file descriptor \param{fd}.
+  di un file già aperto, specificato dal file descriptor \param{fd}.
 
   \funcdecl{int utimensat(int dirfd, const char *pathname, const struct
     timespec times[2], int flags)} Cambia i tempi del file \param{pathname}.
   
   
   \bodydesc{Le funzioni restituiscono zero in caso di successo e $-1$ per un
-    errore, nel qual caso \var{errno} assumerà gli stessi valori di
-    \func{utimes}, con in più per \func{futimes}:
+    errore, nel qual caso \var{errno} assumerà gli stessi valori di
+    \func{utimes}, con in più per \func{futimes}:
   \begin{errlist}
-  \item[\errcode{EBADF}] \param{fd}  non è un file descriptor.
-  \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile.
+  \item[\errcode{EBADF}] \param{fd}  non è un file descriptor.
+  \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile.
   \end{errlist}}
 \end{functions}
 
 Entrambe le funzioni utilizzano per indicare i valori dei tempi un
 vettore \param{times} di due strutture \struct{timespec} che permette di
 specificare un valore di tempo con una precisione fino al nanosecondo, la cui
-definizione è riportata in fig.~\ref{fig:sys_timespec_struct}.
+definizione è riportata in fig.~\ref{fig:sys_timespec_struct}.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -2095,11 +2095,11 @@ definizione 
 
 Come per le precedenti funzioni il primo elemento di \param{times} indica il
 tempo di ultimo accesso ed il secondo quello di ultima modifica, e se si usa
-il valore \const{NULL} verrà impostato il tempo corrente sia per l'ultimo
+il valore \const{NULL} verrà impostato il tempo corrente sia per l'ultimo
 accesso che per l'ultima modifica. Nei singoli elementi di \param{times} si
 possono inoltre utilizzare due valori speciali per il campo \var{tv\_nsec}:
 con \const{UTIME\_NOW} si richiede l'uso del tempo corrente, mentre con
-\const{UTIME\_OMIT} si richiede di non impostare il tempo. Si può così
+\const{UTIME\_OMIT} si richiede di non impostare il tempo. Si può così
 aggiornare in maniera specifica soltanto uno fra il tempo di ultimo accesso e
 quello di ultima modifica. Quando si usa uno di questi valori speciali per
 \var{tv\_nsec} il corrispondente valore di \var{tv\_sec} viene ignorato.
@@ -2109,25 +2109,25 @@ dello standard POSIX (la POSIX.1-2008); sono state introdotte a partire dal
 kernel 2.6.22, e supportate dalle \acr{glibc} a partire dalla versione
 2.6.\footnote{in precedenza, a partire dal kernel 2.6.16, era stata introdotta
   la funzione \func{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 la tratteremo.} La prima è
+  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 la tratteremo.} La prima è
 sostanzialmente una estensione di \func{futimes} che consente di specificare i
 tempi con precisione maggiore, la seconda supporta invece, rispetto ad
-\func{utimes}, una sintassi più complessa che, come vedremo in
+\func{utimes}, una sintassi più complessa che, come vedremo in
 sez.~\ref{sec:file_openat},\footnote{si rimanda pertanto la spiegazione del
   significato degli argomenti aggiuntivi alla trattazione generica delle varie
   funzioni che usano la stessa sintassi, effettuata in
   sez.~\ref{sec:file_openat}.}  consente una indicazione sicura dei
 \textit{pathname relativi} specificando la directory da usare come riferimento
-in \param{dirfd} e la possibilità di usare \param{flags} per indicare alla
+in \param{dirfd} e la possibilità di usare \param{flags} per indicare alla
 funzione di dereferenziare o meno i link simbolici.
 
 
 \section{Il controllo di accesso ai file}
 \label{sec:file_access_control}
 
-Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella
+Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella
 del controllo di accesso ai file, che viene implementato per qualunque
 filesystem standard.\footnote{per standard si intende che implementa le
   caratteristiche previste dallo standard POSIX; in Linux sono disponibili
@@ -2139,13 +2139,13 @@ concetti essenziali e le funzioni usate per gestirne i vari aspetti.
 \subsection{I permessi per l'accesso ai file}
 \label{sec:file_perm_overview}
 
-Ad ogni file Linux associa sempre l'utente che ne è proprietario (il
+Ad ogni file Linux associa sempre l'utente che ne è proprietario (il
 cosiddetto \textit{owner}) ed un gruppo di appartenenza, secondo il meccanismo
 degli identificatori di utente e gruppo (\acr{uid} e \acr{gid}). Questi valori
 sono accessibili da programma tramite la funzione \func{stat}, e sono
 mantenuti nei campi \var{st\_uid} e \var{st\_gid} della struttura
-\struct{stat} (si veda sez.~\ref{sec:file_stat}).\footnote{questo è vero solo
-  per filesystem di tipo Unix, ad esempio non è vero per il filesystem vfat di
+\struct{stat} (si veda sez.~\ref{sec:file_stat}).\footnote{questo è vero solo
+  per filesystem di tipo Unix, ad esempio non è vero per il filesystem vfat di
   Windows, che non fornisce nessun supporto per l'accesso multiutente, e per
   il quale i permessi vengono assegnati in maniera fissa con un opzione in
   fase di montaggio.}
@@ -2155,9 +2155,9 @@ prevede tre permessi fondamentali strutturati su tre livelli di accesso.
 Esistono varie estensioni a questo modello,\footnote{come le \textit{Access
     Control List} che sono state aggiunte ai filesystem standard con opportune
   estensioni (vedi sez.~\ref{sec:file_ACL}) per arrivare a meccanismi di
-  controllo ancora più sofisticati come il \textit{mandatory access control}
-  di SE-Linux.} ma nella maggior parte dei casi il meccanismo standard è più
-che sufficiente a soddisfare tutte le necessità più comuni.  I tre permessi di
+  controllo ancora più sofisticati come il \textit{mandatory access control}
+  di SE-Linux.} ma nella maggior parte dei casi il meccanismo standard è più
+che sufficiente a soddisfare tutte le necessità più comuni.  I tre permessi di
 base associati ad ogni file sono:
 \begin{itemize*}
 \item il permesso di lettura (indicato con la lettera \texttt{r}, dall'inglese
@@ -2190,9 +2190,9 @@ rispettivamente al proprietario, al gruppo, a tutti gli altri.
 
 I restanti tre bit (noti come \itindex{suid~bit} \textit{suid bit},
 \itindex{sgid~bit} \textit{sgid bit}, e \itindex{sticky~bit} \textit{sticky
-  bit}) sono usati per indicare alcune caratteristiche più complesse del
+  bit}) sono usati per indicare alcune caratteristiche più complesse del
 meccanismo del controllo di accesso su cui torneremo in seguito (in
-sez.~\ref{sec:file_special_perm}); lo schema di allocazione dei bit è
+sez.~\ref{sec:file_special_perm}); lo schema di allocazione dei bit è
 riportato in fig.~\ref{fig:file_perm_bit}.
 
 Anche i permessi, come tutte le altre informazioni pertinenti al file, sono
@@ -2218,13 +2218,13 @@ che permettono di accedere al valore numerico di questi bit nel campo
     \textbf{\var{st\_mode}} bit & \textbf{Significato} \\
     \hline 
     \hline 
-    \const{S\_IRUSR} & \textit{user-read}, l'utente può leggere.\\
-    \const{S\_IWUSR} & \textit{user-write}, l'utente può scrivere.\\
-    \const{S\_IXUSR} & \textit{user-execute}, l'utente può eseguire.\\ 
+    \const{S\_IRUSR} & \textit{user-read}, l'utente può leggere.\\
+    \const{S\_IWUSR} & \textit{user-write}, l'utente può scrivere.\\
+    \const{S\_IXUSR} & \textit{user-execute}, l'utente può eseguire.\\ 
     \hline            
-    \const{S\_IRGRP} & \textit{group-read}, il gruppo può leggere.\\
-    \const{S\_IWGRP} & \textit{group-write}, il gruppo può scrivere.\\
-    \const{S\_IXGRP} & \textit{group-execute}, il gruppo può eseguire.\\
+    \const{S\_IRGRP} & \textit{group-read}, il gruppo può leggere.\\
+    \const{S\_IWGRP} & \textit{group-write}, il gruppo può scrivere.\\
+    \const{S\_IXGRP} & \textit{group-execute}, il gruppo può eseguire.\\
     \hline            
     \const{S\_IROTH} & \textit{other-read}, tutti possono leggere.\\
     \const{S\_IWOTH} & \textit{other-write}, tutti possono scrivere.\\
@@ -2238,37 +2238,37 @@ che permettono di accedere al valore numerico di questi bit nel campo
 
 I permessi vengono usati in maniera diversa dalle varie funzioni, e a seconda
 che si riferiscano a dei file, dei link simbolici o delle directory; qui ci
-limiteremo ad un riassunto delle regole generali, entrando nei dettagli più
+limiteremo ad un riassunto delle regole generali, entrando nei dettagli più
 avanti.
 
-La prima regola è che per poter accedere ad un file attraverso il suo
+La prima regola è che per poter accedere ad un file attraverso il suo
 \itindex{pathname} \textit{pathname} occorre il permesso di esecuzione in
 ciascuna delle directory che compongono il \textit{pathname}; lo stesso vale
 per aprire un file nella directory corrente (per la quale appunto serve il
 diritto di esecuzione).
 
-Per una directory infatti il permesso di esecuzione significa che essa può
+Per una directory infatti il permesso di esecuzione significa che essa può
 essere attraversata nella risoluzione del \itindex{pathname}
-\textit{pathname}, ed è distinto dal permesso di lettura che invece implica
-che si può leggere il contenuto della directory.
+\textit{pathname}, ed è distinto dal permesso di lettura che invece implica
+che si può leggere il contenuto della directory.
 
 Questo significa che se si ha il permesso di esecuzione senza permesso di
-lettura si potrà lo stesso aprire un file in una directory (se si hanno i
-permessi opportuni per il medesimo) ma non si potrà vederlo con \cmd{ls}
-(mentre per crearlo occorrerà anche il permesso di scrittura per la
+lettura si potrà lo stesso aprire un file in una directory (se si hanno i
+permessi opportuni per il medesimo) ma non si potrà vederlo con \cmd{ls}
+(mentre per crearlo occorrerà anche il permesso di scrittura per la
 directory).
 
 Avere il permesso di lettura per un file consente di aprirlo con le opzioni
 (si veda quanto riportato in tab.~\ref{tab:file_open_flags}) di sola lettura o
 di lettura/scrittura e leggerne il contenuto. Avere il permesso di scrittura
 consente di aprire un file in sola scrittura o lettura/scrittura e modificarne
-il contenuto, lo stesso permesso è necessario per poter troncare il file.
+il contenuto, lo stesso permesso è necessario per poter troncare il file.
 
-Non si può creare un file fintanto che non si disponga del permesso di
+Non si può creare un file fintanto che non si disponga del permesso di
 esecuzione e di quello di scrittura per la directory di destinazione; gli
 stessi permessi occorrono per cancellare un file da una directory (si ricordi
 che questo non implica necessariamente la rimozione del contenuto del file dal
-disco), non è necessario nessun tipo di permesso per il file stesso (infatti
+disco), non è necessario nessun tipo di permesso per il file stesso (infatti
 esso non viene toccato, viene solo modificato il contenuto della directory,
 rimuovendo la voce che ad esso fa riferimento).
 
@@ -2281,7 +2281,7 @@ I permessi per un link simbolico sono ignorati, contano quelli del file a cui
 fa riferimento; per questo in genere il comando \cmd{ls} riporta per un link
 simbolico tutti i permessi come concessi; utente e gruppo a cui esso
 appartiene vengono pure ignorati quando il link viene risolto, vengono
-controllati solo quando viene richiesta la rimozione del link e quest'ultimo è
+controllati solo quando viene richiesta la rimozione del link e quest'ultimo è
 in una directory con lo \itindex{sticky~bit} \textit{sticky bit} impostato (si
 veda sez.~\ref{sec:file_special_perm}).
 
@@ -2290,7 +2290,7 @@ permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra
 l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e
 \var{st\_gid} accennati in precedenza) e l'user-ID effettivo, il group-ID
 effettivo e gli eventuali group-ID supplementari del processo.\footnote{in
-  realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli
+  realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli
   identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in
   sez.~\ref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi,
   eccetto il caso in cui si voglia scrivere un server NFS, ignoreremo questa
@@ -2306,34 +2306,34 @@ cui l'utente appartiene.
 I passi attraverso i quali viene stabilito se il processo possiede il diritto
 di accesso sono i seguenti:
 \begin{enumerate}
-\item Se l'user-ID effettivo del processo è zero (corrispondente
-  all'amministratore) l'accesso è sempre garantito senza nessun ulteriore
-  controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a
+\item Se l'user-ID effettivo del processo è zero (corrispondente
+  all'amministratore) l'accesso è sempre garantito senza nessun ulteriore
+  controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a
   tutti i file.
-\item Se l'user-ID effettivo del processo è uguale all'\acr{uid} del
-  proprietario del file (nel qual caso si dice che il processo è proprietario
+\item Se l'user-ID effettivo del processo è uguale all'\acr{uid} del
+  proprietario del file (nel qual caso si dice che il processo è proprietario
   del file) allora:
   \begin{itemize*}
   \item se il relativo\footnote{per relativo si intende il bit di user-read se
       il processo vuole accedere in lettura, quello di user-write per
-      l'accesso in scrittura, ecc.} bit dei permessi d'accesso dell'utente è
-    impostato, l'accesso è consentito
-  \item altrimenti l'accesso è negato
+      l'accesso in scrittura, ecc.} bit dei permessi d'accesso dell'utente è
+    impostato, l'accesso è consentito
+  \item altrimenti l'accesso è negato
   \end{itemize*}
 \item Se il group-ID effettivo del processo o uno dei group-ID supplementari
   dei processi corrispondono al \acr{gid} del file allora:
   \begin{itemize*}
-  \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
+  \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
     consentito, 
-  \item altrimenti l'accesso è negato
+  \item altrimenti l'accesso è negato
   \end{itemize*}
-\item Se il bit dei permessi d'accesso per tutti gli altri è impostato,
-  l'accesso è consentito, altrimenti l'accesso è negato.
+\item Se il bit dei permessi d'accesso per tutti gli altri è impostato,
+  l'accesso è consentito, altrimenti l'accesso è negato.
 \end{enumerate}
 
 Si tenga presente che questi passi vengono eseguiti esattamente in
-quest'ordine. Questo vuol dire che se un processo è il proprietario di un file,
-l'accesso è consentito o negato solo sulla base dei permessi per l'utente; i
+quest'ordine. Questo vuol dire che se un processo è il proprietario di un file,
+l'accesso è consentito o negato solo sulla base dei permessi per l'utente; i
 permessi per il gruppo non vengono neanche controllati. Lo stesso vale se il
 processo appartiene ad un gruppo appropriato, in questo caso i permessi per
 tutti gli altri non vengono controllati.
@@ -2345,32 +2345,32 @@ tutti gli altri non vengono controllati.
 \itindbeg{suid~bit}
 \itindbeg{sgid~bit}
 
-Come si è accennato (in sez.~\ref{sec:file_perm_overview}) nei dodici bit del
+Come si è accennato (in sez.~\ref{sec:file_perm_overview}) nei dodici bit del
 campo \var{st\_mode} di \struct{stat} che vengono usati per il controllo di
 accesso oltre ai bit dei permessi veri e propri, ci sono altri tre bit che
-vengono usati per indicare alcune proprietà speciali dei file.  Due di questi
+vengono usati per indicare alcune proprietà speciali dei file.  Due di questi
 sono i bit detti \acr{suid} (da \textit{set-user-ID bit}) e \acr{sgid} (da
 \textit{set-group-ID bit}) che sono identificati dalle costanti
 \const{S\_ISUID} e \const{S\_ISGID}.
 
 Come spiegato in dettaglio in sez.~\ref{sec:proc_exec}, quando si lancia un
-programma il comportamento normale del kernel è quello di impostare gli
+programma il comportamento normale del kernel è quello di impostare gli
 identificatori del gruppo \textit{effective} del nuovo processo al valore dei
 corrispondenti del gruppo \textit{real} del processo corrente, che normalmente
-corrispondono a quelli dell'utente con cui si è entrati nel sistema.
+corrispondono a quelli dell'utente con cui si è entrati nel sistema.
 
-Se però il file del programma (che ovviamente deve essere
+Se però il file del programma (che ovviamente deve essere
 eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid}
   e \acr{sgid} per gli script eseguibili.}) ha il bit \acr{suid} impostato, il
-kernel assegnerà come user-ID effettivo al nuovo processo l'\acr{uid} del
+kernel assegnerà come user-ID effettivo al nuovo processo l'\acr{uid} del
 proprietario del file al posto dell'\acr{uid} del processo originario.  Avere
 il bit \acr{sgid} impostato ha lo stesso effetto sul group-ID effettivo del
 processo.
 
 I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali
-di usare programmi che richiedono privilegi speciali; l'esempio classico è il
-comando \cmd{passwd} che ha la necessità di modificare il file delle password,
-quest'ultimo ovviamente può essere scritto solo dall'amministratore, ma non è
+di usare programmi che richiedono privilegi speciali; l'esempio classico è il
+comando \cmd{passwd} che ha la necessità di modificare il file delle password,
+quest'ultimo ovviamente può essere scritto solo dall'amministratore, ma non è
 necessario chiamare l'amministratore per cambiare la propria password. Infatti
 il comando \cmd{passwd} appartiene a root ma ha il bit \acr{suid} impostato
 per cui quando viene lanciato da un utente normale parte con i privilegi di
@@ -2379,13 +2379,13 @@ root.
 Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe
 normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di
 programmi devono essere scritti accuratamente per evitare che possano essere
-usati per guadagnare privilegi non consentiti (l'argomento è affrontato in
+usati per guadagnare privilegi non consentiti (l'argomento è affrontato in
 dettaglio in sez.~\ref{sec:proc_perms}).
 
-La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere rilevata con
+La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere rilevata con
 il comando \cmd{ls -l}, che visualizza una lettera \cmd{s} al posto della
 \cmd{x} in corrispondenza dei permessi di utente o gruppo. La stessa lettera
-\cmd{s} può essere usata nel comando \cmd{chmod} per impostare questi bit.
+\cmd{s} può essere usata nel comando \cmd{chmod} per impostare questi bit.
 Infine questi bit possono essere controllati all'interno di \var{st\_mode} con
 l'uso delle due costanti \const{S\_ISUID} e \const{S\_IGID}, i cui valori sono
 riportati in tab.~\ref{tab:file_mode_flags}.
@@ -2400,7 +2400,7 @@ Infine Linux utilizza il bit \acr{sgid} per un'ulteriore estensione mutuata
 da SVr4. Il caso in cui un file ha il bit \acr{sgid} impostato senza che lo
 sia anche il corrispondente bit di esecuzione viene utilizzato per attivare
 per quel file il \itindex{mandatory~locking} \textit{mandatory locking}
-(affronteremo questo argomento in dettaglio più avanti, in
+(affronteremo questo argomento in dettaglio più avanti, in
 sez.~\ref{sec:file_mand_locking}).
 
 \itindend{suid~bit}
@@ -2409,10 +2409,10 @@ sez.~\ref{sec:file_mand_locking}).
 
 \itindbeg{sticky~bit}
 
-L'ultimo dei bit rimanenti, identificato dalla costante \const{S\_ISVTX}, è in
+L'ultimo dei bit rimanenti, identificato dalla costante \const{S\_ISVTX}, è in
 parte un rimasuglio delle origini dei sistemi Unix. A quell'epoca infatti la
 memoria virtuale e l'accesso ai file erano molto meno sofisticati e per
-ottenere la massima velocità possibile per i programmi usati più comunemente
+ottenere la massima velocità possibile per i programmi usati più comunemente
 si poteva impostare questo bit.
 
 L'effetto di questo bit era che il \index{segmento!testo} segmento di testo
@@ -2421,7 +2421,7 @@ scritto nella swap la prima volta che questo veniva lanciato, e vi permaneva
 fino al riavvio della macchina (da questo il nome di \textsl{sticky bit});
 essendo la swap un file continuo o una partizione indicizzata direttamente si
 poteva risparmiare in tempo di caricamento rispetto alla ricerca attraverso la
-struttura del filesystem. Lo \textsl{sticky bit} è indicato usando la lettera
+struttura del filesystem. Lo \textsl{sticky bit} è indicato usando la lettera
 \texttt{t} al posto della \texttt{x} nei permessi per gli altri.
 
 Ovviamente per evitare che gli utenti potessero intasare la swap solo
@@ -2430,29 +2430,29 @@ anche con il nome di \textit{saved text bit}, da cui deriva quello della
 costante.  Le attuali implementazioni di memoria virtuale e filesystem rendono
 sostanzialmente inutile questo procedimento.
 
-Benché ormai non venga più utilizzato per i file, lo \textit{sticky bit} ha
+Benché ormai non venga più utilizzato per i file, lo \textit{sticky bit} ha
 invece assunto un uso importante per le directory;\footnote{lo \textit{sticky
-    bit} per le directory è un'estensione non definita nello standard POSIX,
-  Linux però la supporta, così come BSD e SVr4.} in questo caso se tale bit è
-impostato un file potrà essere rimosso dalla directory soltanto se l'utente ha
-il permesso di scrittura su di essa ed inoltre è vera una delle seguenti
+    bit} per le directory è un'estensione non definita nello standard POSIX,
+  Linux però la supporta, così come BSD e SVr4.} in questo caso se tale bit è
+impostato un file potrà essere rimosso dalla directory soltanto se l'utente ha
+il permesso di scrittura su di essa ed inoltre è vera una delle seguenti
 condizioni:
 \begin{itemize*}
-\item l'utente è proprietario del file
-\item l'utente è proprietario della directory
-\item l'utente è l'amministratore 
+\item l'utente è proprietario del file
+\item l'utente è proprietario della directory
+\item l'utente è l'amministratore 
 \end{itemize*}
-un classico esempio di directory che ha questo bit impostato è \file{/tmp}, i
+un classico esempio di directory che ha questo bit impostato è \file{/tmp}, i
 permessi infatti di solito sono i seguenti:
 \begin{verbatim}
 $ ls -ld /tmp
 drwxrwxrwt    6 root     root         1024 Aug 10 01:03 /tmp
 \end{verbatim}%$
 quindi con lo \textit{sticky bit} bit impostato. In questo modo qualunque
-utente nel sistema può creare dei file in questa directory (che, come
-suggerisce il nome, è normalmente utilizzata per la creazione di file
-temporanei), ma solo l'utente che ha creato un certo file potrà cancellarlo o
-rinominarlo. In questo modo si evita che un utente possa, più o meno
+utente nel sistema può creare dei file in questa directory (che, come
+suggerisce il nome, è normalmente utilizzata per la creazione di file
+temporanei), ma solo l'utente che ha creato un certo file potrà cancellarlo o
+rinominarlo. In questo modo si evita che un utente possa, più o meno
 consapevolmente, cancellare i file temporanei creati degli altri utenti.
 
 \itindend{sticky~bit}
@@ -2462,26 +2462,26 @@ consapevolmente, cancellare i file temporanei creati degli altri utenti.
 
 Come visto in sez.~\ref{sec:file_access_control} il controllo di accesso ad un
 file viene fatto utilizzando l'user-ID ed il group-ID effettivo del processo;
-ci sono casi però in cui si può voler effettuare il controllo con l'user-ID
+ci sono casi però in cui si può voler effettuare il controllo con l'user-ID
 reale ed il group-ID reale, vale a dire usando i valori di \acr{uid} e
 \acr{gid} relativi all'utente che ha lanciato il programma, e che, come
 accennato in sez.~\ref{sec:file_special_perm} e spiegato in dettaglio in
-sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.
+sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.
 
-Per far questo si può usare la funzione \funcd{access}, il cui prototipo è:
+Per far questo si può usare la funzione \funcd{access}, il cui prototipo è:
 \begin{prototype}{unistd.h}
 {int access(const char *pathname, int mode)}
 
 Verifica i permessi di accesso.
   
-\bodydesc{La funzione ritorna 0 se l'accesso è consentito, -1 se l'accesso non
-  è consentito ed in caso di errore; nel qual caso la variabile \var{errno}
-  assumerà i valori:
+\bodydesc{La funzione ritorna 0 se l'accesso è consentito, -1 se l'accesso non
+  è consentito ed in caso di errore; nel qual caso la variabile \var{errno}
+  assumerà i valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] il valore di \param{mode} non è valido.
-  \item[\errcode{EACCES}] l'accesso al file non è consentito, o non si ha il
+  \item[\errcode{EINVAL}] il valore di \param{mode} non è valido.
+  \item[\errcode{EACCES}] l'accesso al file non è consentito, o non si ha il
     permesso di attraversare una delle directory di \param{pathname}.
-  \item[\errcode{EROFS}] si è richiesto l'accesso in scrittura per un file su
+  \item[\errcode{EROFS}] si è richiesto l'accesso in scrittura per un file su
     un filesystem montato in sola lettura.
   \end{errlist}
   ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
@@ -2493,9 +2493,9 @@ file indicato da \param{pathname}. I valori possibili per l'argomento
 \param{mode} sono esprimibili come combinazione delle costanti numeriche
 riportate in tab.~\ref{tab:file_access_mode_val} (attraverso un OR binario
 delle stesse). I primi tre valori implicano anche la verifica dell'esistenza
-del file, se si vuole verificare solo quest'ultima si può usare \const{F\_OK},
+del file, se si vuole verificare solo quest'ultima si può usare \const{F\_OK},
 o anche direttamente \func{stat}. Nel caso in cui \param{pathname} si
-riferisca ad un link simbolico, questo viene seguito ed il controllo è fatto
+riferisca ad un link simbolico, questo viene seguito ed il controllo è fatto
 sul file a cui esso fa riferimento.
 
 La funzione controlla solo i bit dei permessi di accesso, si ricordi che il
@@ -2523,18 +2523,18 @@ contrario (o di errore) ritorna -1.
   \label{tab:file_access_mode_val}
 \end{table}
 
-Un esempio tipico per l'uso di questa funzione è quello di un processo che sta
+Un esempio tipico per l'uso di questa funzione è quello di un processo che sta
 eseguendo un programma coi privilegi di un altro utente (ad esempio attraverso
 l'uso del \itindex{suid~bit} \textit{suid bit}) che vuole controllare se
 l'utente originale ha i permessi per accedere ad un certo file.
 
 Del tutto analoghe a \func{access} sono le due funzioni \funcd{euidaccess} e
-\funcd{eaccess} che ripetono lo stesso controllo usando però gli
-identificatori del gruppo effettivo, verificando quindi le effettive capacità
+\funcd{eaccess} che ripetono lo stesso controllo usando però gli
+identificatori del gruppo effettivo, verificando quindi le effettive capacità
 di accesso ad un file. Le funzioni hanno entrambe lo stesso
-prototipo\footnote{in realtà \func{eaccess} è solo un sinonimo di
-  \func{euidaccess} fornita per compatibilità con l'uso di questo nome in
-  altri sistemi.} che è del tutto identico a quello di \func{access}. Prendono
+prototipo\footnote{in realtà \func{eaccess} è solo un sinonimo di
+  \func{euidaccess} fornita per compatibilità con l'uso di questo nome in
+  altri sistemi.} che è del tutto identico a quello di \func{access}. Prendono
 anche gli stessi valori e restituiscono gli stessi risultati e gli stessi
 codici di errore.
 
@@ -2552,11 +2552,11 @@ filename e su un file descriptor, i loro prototipi sono:
   il file descriptor \param{fd} per indicare il file.
   
   \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
-    un errore, in caso di errore \var{errno} può assumere i valori:
+    un errore, in caso di errore \var{errno} può assumere i valori:
   \begin{errlist}
   \item[\errcode{EPERM}] l'user-ID effettivo non corrisponde a quello del
-    proprietario del file o non è zero.
-    \item[\errcode{EROFS}] il file è su un filesystem in sola lettura.
+    proprietario del file o non è zero.
+    \item[\errcode{EROFS}] il file è su un filesystem in sola lettura.
   \end{errlist}
   ed inoltre \errval{EIO}; \func{chmod} restituisce anche \errval{EFAULT},
   \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR},
@@ -2602,11 +2602,11 @@ file.
 \end{table}
 
 Le costanti con cui specificare i singoli bit di \param{mode} sono riportate
-in tab.~\ref{tab:file_permission_const}. Il valore di \param{mode} può essere
+in tab.~\ref{tab:file_permission_const}. Il valore di \param{mode} può essere
 ottenuto combinando fra loro con un OR binario le costanti simboliche relative
 ai vari bit, o specificato direttamente, come per l'omonimo comando di shell,
 con un valore numerico (la shell lo vuole in ottale, dato che i bit dei
-permessi sono divisibili in gruppi di tre), che si può calcolare direttamente
+permessi sono divisibili in gruppi di tre), che si può calcolare direttamente
 usando lo schema si utilizzo dei bit illustrato in
 fig.~\ref{fig:file_perm_bit}.
 
@@ -2618,46 +2618,46 @@ bit \itindex{suid~bit} \acr{suid} il valore da fornire sarebbe $4755$.
 
 Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha
 comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle
-funzioni infatti è possibile solo se l'user-ID effettivo del processo
+funzioni infatti è possibile solo se l'user-ID effettivo del processo
 corrisponde a quello del proprietario del file o dell'amministratore,
 altrimenti esse falliranno con un errore di \errcode{EPERM}.
 
 Ma oltre a questa regola generale, di immediata comprensione, esistono delle
-limitazioni ulteriori. Per questo motivo, anche se si è proprietari del file,
+limitazioni ulteriori. Per questo motivo, anche se si è proprietari del file,
 non tutti i valori possibili di \param{mode} sono permessi o hanno effetto;
 in particolare accade che:
 \begin{enumerate}
-\item siccome solo l'amministratore può impostare lo \itindex{sticky~bit}
-  \textit{sticky bit}, se l'user-ID effettivo del processo non è zero esso
+\item siccome solo l'amministratore può impostare lo \itindex{sticky~bit}
+  \textit{sticky bit}, se l'user-ID effettivo del processo non è zero esso
   viene automaticamente cancellato (senza notifica di errore) qualora sia
   stato indicato in \param{mode}.
 \item per quanto detto in sez.~\ref{sec:file_ownership_management} riguardo la
-  creazione dei nuovi file, si può avere il caso in cui il file creato da un
-  processo è assegnato ad un gruppo per il quale il processo non ha privilegi.
+  creazione dei nuovi file, si può avere il caso in cui il file creato da un
+  processo è assegnato ad un gruppo per il quale il processo non ha privilegi.
   Per evitare che si possa assegnare il bit \itindex{sgid~bit} \acr{sgid} ad
   un file appartenente ad un gruppo per cui non si hanno diritti, questo viene
   automaticamente cancellato da \param{mode} (senza notifica di errore)
   qualora il gruppo del file non corrisponda a quelli associati al processo
-  (la cosa non avviene quando l'user-ID effettivo del processo è zero).
+  (la cosa non avviene quando l'user-ID effettivo del processo è zero).
 \end{enumerate}
 
-Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
-  \textsl{ext3}, \textsl{reiserfs}) supportano questa caratteristica, che è
-  mutuata da BSD.} è inoltre prevista un'ulteriore misura di sicurezza, volta
+Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
+  \textsl{ext3}, \textsl{reiserfs}) supportano questa caratteristica, che è
+  mutuata da BSD.} è inoltre prevista un'ulteriore misura di sicurezza, volta
 a scongiurare l'abuso dei \itindex{suid~bit} bit \acr{suid} e \acr{sgid}; essa
 consiste nel cancellare automaticamente questi bit dai permessi di un file
 qualora un processo che non appartenga all'amministratore\footnote{per la
-  precisione un processo che non dispone della \itindex{capabilities} capacità
+  precisione un processo che non dispone della \itindex{capabilities} capacità
   \const{CAP\_FSETID}, vedi sez.~\ref{sec:proc_capabilities}.} effettui una
 scrittura. In questo modo anche se un utente malizioso scopre un file
-\acr{suid} su cui può scrivere, un'eventuale modifica comporterà la perdita di
+\acr{suid} su cui può scrivere, un'eventuale modifica comporterà la perdita di
 questo privilegio.
 
 Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i
-permessi di un file, resta però il problema di quali sono i permessi assegnati
+permessi di un file, resta però il problema di quali sono i permessi assegnati
 quando il file viene creato. Le funzioni dell'interfaccia nativa di Unix, come
 vedremo in sez.~\ref{sec:file_open}, permettono di indicare esplicitamente i
-permessi di creazione di un file, ma questo non è possibile per le funzioni
+permessi di creazione di un file, ma questo non è possibile per le funzioni
 dell'interfaccia standard ANSI C che non prevede l'esistenza di utenti e
 gruppi, ed inoltre il problema si pone anche per l'interfaccia nativa quando i
 permessi non vengono indicati esplicitamente. 
@@ -2665,11 +2665,11 @@ permessi non vengono indicati esplicitamente.
 \itindbeg{umask} 
 
 Per le funzioni dell'interfaccia standard ANSI C l'unico riferimento possibile
-è quello della modalità di apertura del nuovo file (lettura/scrittura o sola
-lettura), che però può fornire un valore che è lo stesso per tutti e tre i
-permessi di sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e
+è quello della modalità di apertura del nuovo file (lettura/scrittura o sola
+lettura), che però può fornire un valore che è lo stesso per tutti e tre i
+permessi di sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e
 $222$ nel secondo). Per questo motivo il sistema associa ad ogni
-processo\footnote{è infatti contenuta nel campo \var{umask} della struttura
+processo\footnote{è infatti contenuta nel campo \var{umask} della struttura
   \struct{fs\_struct}, vedi fig.~\ref{fig:proc_task_struct}.}  una maschera di
 bit, la cosiddetta \textit{umask}, che viene utilizzata per impedire che
 alcuni permessi possano essere assegnati ai nuovi file in sede di creazione. I
@@ -2680,73 +2680,73 @@ nuovo file viene creato.\footnote{l'operazione viene fatta sempre: anche
   verranno tolti.}
 
 La funzione che permette di impostare il valore di questa maschera di
-controllo è \funcd{umask}, ed il suo prototipo è:
+controllo è \funcd{umask}, ed il suo prototipo è:
 \begin{prototype}{stat.h}
 {mode\_t umask(mode\_t mask)}
 
 Imposta la maschera dei permessi dei bit al valore specificato da \param{mask}
 (di cui vengono presi solo i 9 bit meno significativi).
   
-  \bodydesc{La funzione ritorna il precedente valore della maschera. È una
+  \bodydesc{La funzione ritorna il precedente valore della maschera. È una
     delle poche funzioni che non restituisce codici di errore.}
 \end{prototype}
 
 In genere si usa questa maschera per impostare un valore predefinito che
 escluda preventivamente alcuni permessi (usualmente quello di scrittura per il
 gruppo e gli altri, corrispondente ad un valore per \param{mask} pari a
-$022$).  In questo modo è possibile cancellare automaticamente i permessi non
+$022$).  In questo modo è possibile cancellare automaticamente i permessi non
 voluti.  Di norma questo valore viene impostato una volta per tutte al login a
 $022$, e gli utenti non hanno motivi per modificarlo.
 
 \itindend{umask} 
 
 
-\subsection{La gestione della titolarità dei file}
+\subsection{La gestione della titolarità dei file}
 \label{sec:file_ownership_management}
 
 Vedremo in sez.~\ref{sec:file_base_func} con quali funzioni si possono creare
-nuovi file, in tale occasione vedremo che è possibile specificare in sede di
-creazione quali permessi applicare ad un file, però non si può indicare a
+nuovi file, in tale occasione vedremo che è possibile specificare in sede di
+creazione quali permessi applicare ad un file, però non si può indicare a
 quale utente e gruppo esso deve appartenere.  Lo stesso problema si presenta
 per la creazione di nuove directory (procedimento descritto in
 sez.~\ref{sec:file_dir_creat_rem}).
 
 Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
 all'user-ID effettivo del processo che lo crea; per il \acr{gid} invece prevede
-due diverse possibilità:
+due diverse possibilità:
 \begin{itemize*}
 \item il \acr{gid} del file corrisponde al group-ID effettivo del processo.
 \item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
-  esso è creato.
+  esso è creato.
 \end{itemize*}
-in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
+in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
 semantica BSD. Linux invece segue quella che viene chiamata semantica SVr4; di
-norma cioè il nuovo file viene creato, seguendo la prima opzione, con il
-\acr{gid} del processo, se però la directory in cui viene creato il file ha il
+norma cioè il nuovo file viene creato, seguendo la prima opzione, con il
+\acr{gid} del processo, se però la directory in cui viene creato il file ha il
 bit \acr{sgid} impostato allora viene usata la seconda opzione.
 
 Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
 automaticamente propagato, restando coerente a quello della directory di
 partenza, in tutte le sotto-directory. 
 
-La semantica SVr4 offre la possibilità di scegliere, ma per ottenere lo stesso
+La semantica SVr4 offre la possibilità di scegliere, ma per ottenere lo stesso
 risultato di coerenza che si ha con BSD necessita che quando si creano nuove
-directory venga anche propagato anche il bit \acr{sgid}. Questo è il
-comportamento predefinito del comando \cmd{mkdir}, ed è in questo modo ad
+directory venga anche propagato anche il bit \acr{sgid}. Questo è il
+comportamento predefinito del comando \cmd{mkdir}, ed è in questo modo ad
 esempio che le varie distribuzioni assicurano che le sotto-directory create
 nella home di un utente restino sempre con il \acr{gid} del gruppo primario
 dello stesso.
 
-La presenza del bit \acr{sgid} è inoltre molto comoda quando si hanno
+La presenza del bit \acr{sgid} è inoltre molto comoda quando si hanno
 directory contenenti file condivisi all'intero di un gruppo in cui possono
 scrivere tutti i membri dello stesso, dato che assicura che i file che gli
 utenti vi creano appartengano sempre allo stesso gruppo. Questo non risolve
-però completamente i problemi di accesso da parte di altri utenti dello stesso
+però completamente i problemi di accesso da parte di altri utenti dello stesso
 gruppo, in quanto i permessi assegnati al gruppo potrebbero non essere
 sufficienti; in tal caso si deve aver cura di usare un valore di
 \itindex{umask} \textit{umask} che ne lasci di sufficienti.\footnote{in tal
-  caso si può assegnare agli utenti del gruppo una \textit{umask} di $002$,
-  anche se la soluzione migliore in questo caso è usare una ACL di default
+  caso si può assegnare agli utenti del gruppo una \textit{umask} di $002$,
+  anche se la soluzione migliore in questo caso è usare una ACL di default
   (vedi sez.~\ref{sec:file_ACL}).}
 
 Come avviene nel caso dei permessi il sistema fornisce anche delle funzioni,
@@ -2764,10 +2764,10 @@ l'utente che il gruppo a cui un file appartiene; i rispettivi prototipi sono:
   specificati dalle variabili \param{owner} e \param{group}. 
   
   \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un
-    errore, nel qual caso caso \var{errno} assumerà i valori:
+    errore, nel qual caso caso \var{errno} assumerà i valori:
   \begin{errlist}
   \item[\errcode{EPERM}] l'user-ID effettivo non corrisponde a quello del
-    proprietario del file o non è zero, o utente e gruppo non sono validi
+    proprietario del file o non è zero, o utente e gruppo non sono validi
   \end{errlist}
   Oltre a questi entrambe restituiscono gli errori \errval{EROFS} e
   \errval{EIO}; \func{chown} restituisce anche \errval{EFAULT},
@@ -2776,29 +2776,29 @@ l'utente che il gruppo a cui un file appartiene; i rispettivi prototipi sono:
 \end{functions}
 
 Con Linux solo l'amministratore\footnote{o in generale un processo con la
-  \itindex{capabilities} capacità \const{CAP\_CHOWN}, vedi
-  sez.~\ref{sec:proc_capabilities}.} può cambiare il proprietario di un file;
+  \itindex{capabilities} capacità \const{CAP\_CHOWN}, vedi
+  sez.~\ref{sec:proc_capabilities}.} può cambiare il proprietario di un file;
 in questo viene seguita la semantica usata da BSD che non consente agli utenti
 di assegnare i loro file ad altri utenti evitando eventuali aggiramenti delle
-quote.  L'amministratore può cambiare sempre il gruppo di un file, il
-proprietario può cambiare il gruppo solo dei file che gli appartengono e solo
-se il nuovo gruppo è il suo gruppo primario o uno dei gruppi di cui fa parte.
+quote.  L'amministratore può cambiare sempre il gruppo di un file, il
+proprietario può cambiare il gruppo solo dei file che gli appartengono e solo
+se il nuovo gruppo è il suo gruppo primario o uno dei gruppi di cui fa parte.
 
 La funzione \func{chown} segue i link simbolici, per operare direttamente su
 un link simbolico si deve usare la funzione \func{lchown}.\footnote{fino alla
   versione 2.1.81 in Linux \func{chown} non seguiva i link simbolici, da
-  allora questo comportamento è stato assegnato alla funzione \func{lchown},
-  introdotta per l'occasione, ed è stata creata una nuova system call per
+  allora questo comportamento è stato assegnato alla funzione \func{lchown},
+  introdotta per l'occasione, ed è stata creata una nuova system call per
   \func{chown} che seguisse i link simbolici.} La funzione \func{fchown} opera
-su un file aperto, essa è mutuata da BSD, ma non è nello standard POSIX.
-Un'altra estensione rispetto allo standard POSIX è che specificando -1 come
+su un file aperto, essa è mutuata da BSD, ma non è nello standard POSIX.
+Un'altra estensione rispetto allo standard POSIX è che specificando -1 come
 valore per \param{owner} e \param{group} i valori restano immutati.
 
 Quando queste funzioni sono chiamate con successo da un processo senza i
 privilegi di root entrambi i bit \itindex{suid~bit} \acr{suid} e
 \itindex{sgid~bit} \acr{sgid} vengono cancellati. Questo non avviene per il
 bit \acr{sgid} nel caso in cui esso sia usato (in assenza del corrispondente
-permesso di esecuzione) per indicare che per il file è attivo il
+permesso di esecuzione) per indicare che per il file è attivo il
 \itindex{mandatory~locking} \textit{mandatory locking} (vedi
 sez.~\ref{sec:file_mand_locking}).
 
@@ -2829,7 +2829,7 @@ fornire un quadro d'insieme.
    1&-&-&-&-&-&-&-&-&-&-&-&Se eseguito ha i permessi del proprietario.\\
    -&1&-&-&-&1&-&-&-&-&-&-&Se eseguito ha i permessi del gruppo proprietario.\\
    -&1&-&-&-&0&-&-&-&-&-&-&Il \itindex{mandatory~locking} 
-                           \textit{mandatory locking} è abilitato.\\
+                           \textit{mandatory locking} è abilitato.\\
    -&-&1&-&-&-&-&-&-&-&-&-&Non utilizzato.\\
    -&-&-&1&-&-&-&-&-&-&-&-&Permesso di lettura per il proprietario.\\
    -&-&-&-&1&-&-&-&-&-&-&-&Permesso di scrittura per il proprietario.\\
@@ -2875,7 +2875,7 @@ fornire un quadro d'insieme.
   \label{tab:file_fileperm_bits}
 \end{table}
 
-Nella parte superiore di tab.~\ref{tab:file_fileperm_bits} si è riassunto il
+Nella parte superiore di tab.~\ref{tab:file_fileperm_bits} si è riassunto il
 significato dei vari bit dei permessi per un file ordinario; per quanto
 riguarda l'applicazione dei permessi per proprietario, gruppo ed altri si
 ricordi quanto illustrato in sez.~\ref{sec:file_perm_overview}.  Per
@@ -2884,30 +2884,30 @@ compattezza, nella tabella si sono specificati i bit di \itindex{suid~bit}
 \itindex{sticky~bit} con la notazione illustrata anche in
 fig.~\ref{fig:file_perm_bit}.  Nella parte inferiore si sono invece riassunti
 i significati dei vari bit dei permessi per una directory; anche in questo
-caso si è riapplicato ai bit di \itindex{suid~bit} \textit{suid},
+caso si è riapplicato ai bit di \itindex{suid~bit} \textit{suid},
 \itindex{sgid~bit} \textit{sgid} e \textit{sticky} \itindex{sticky~bit} la
 notazione illustrata in fig.~\ref{fig:file_perm_bit}.
 
 Si ricordi infine che i permessi non hanno alcun significato per i link
 simbolici, mentre per i \index{file!di~dispositivo} file di dispositivo hanno
 senso soltanto i permessi di lettura e scrittura, che si riflettono sulla
-possibilità di compiere dette operazioni sul dispositivo stesso.
+possibilità di compiere dette operazioni sul dispositivo stesso.
 
-Nella tabella si è indicato con il carattere ``-'' il fatto che il valore del
-bit in questione non è influente rispetto a quanto indicato nella riga della
+Nella tabella si è indicato con il carattere ``-'' il fatto che il valore del
+bit in questione non è influente rispetto a quanto indicato nella riga della
 tabella; la descrizione del significato fa riferimento soltanto alla
-combinazione di bit per i quali è stato riportato esplicitamente un valore.
+combinazione di bit per i quali è stato riportato esplicitamente un valore.
 Si rammenti infine che il valore dei bit dei permessi non ha alcun effetto
 qualora il processo possieda i privilegi di amministratore.
 
 
-\section{Caratteristiche e funzionalità avanzate}
+\section{Caratteristiche e funzionalità avanzate}
 \label{sec:file_dir_advances}
 
-Tratteremo qui alcune caratteristiche e funzionalità avanzate della gestione
+Tratteremo qui alcune caratteristiche e funzionalità avanzate della gestione
 di file e directory, affrontando anche una serie di estensioni
 dell'interfaccia classica dei sistemi unix-like, principalmente utilizzate a
-scopi di sicurezza, che sono state introdotte nelle versioni più recenti di
+scopi di sicurezza, che sono state introdotte nelle versioni più recenti di
 Linux.
 
 
@@ -2925,8 +2925,8 @@ sistema,\footnote{come montare un filesystem in sola lettura per impedirne
   modifiche, o marcare un file come immutabile.} una volta che questa sia
 stata effettuata e si siano ottenuti i privilegi di amministratore, queste
 potranno essere comunque rimosse.\footnote{nei casi elencati nella precedente
-  nota si potrà sempre rimontare il sistema in lettura-scrittura, o togliere
-  la marcatura di immutabilità.}
+  nota si potrà sempre rimontare il sistema in lettura-scrittura, o togliere
+  la marcatura di immutabilità.}
 
 Il problema consiste nel fatto che nell'architettura tradizionale di un
 sistema unix-like i controlli di accesso sono basati su un solo livello di
@@ -2936,27 +2936,27 @@ per questo motivo non era previsto alcun modo per evitare che un processo con
 diritti di amministratore non potesse eseguire certe operazioni, o per cedere
 definitivamente alcuni privilegi da un certo momento in poi.
 
-Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato
+Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato
 introdotto un meccanismo, detto \textit{capabilities}, che consentisse di
 suddividere i vari privilegi tradizionalmente associati all'amministratore in
-un insieme di \textsl{capacità} distinte.  L'idea era che queste capacità
+un insieme di \textsl{capacità} distinte.  L'idea era che queste capacità
 potessero essere abilitate e disabilitate in maniera indipendente per ciascun
-processo con privilegi di amministratore, permettendo così una granularità
-molto più fine nella distribuzione degli stessi che evitasse la originaria
+processo con privilegi di amministratore, permettendo così una granularità
+molto più fine nella distribuzione degli stessi che evitasse la originaria
 situazione di ``\textsl{tutto o nulla}''.
 
 Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione
-  si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
-  poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai
-singoli file eseguibili, in modo da poter stabilire quali capacità possono
+  si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
+  poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai
+singoli file eseguibili, in modo da poter stabilire quali capacità possono
 essere utilizzate quando viene messo in esecuzione uno specifico programma; ma
-il supporto per questa funzionalità è stato introdotto soltanto a partire dal
+il supporto per questa funzionalità è stato introdotto soltanto a partire dal
 kernel 2.6.24; fino ad allora doveva essere il programma stesso ad eseguire
-una riduzione esplicita delle sue capacità, cosa che ha reso l'uso di questa
-funzionalità poco diffuso, vista la presenza di meccanismi alternativi come
+una riduzione esplicita delle sue capacità, cosa che ha reso l'uso di questa
+funzionalità poco diffuso, vista la presenza di meccanismi alternativi come
 \index{SELinux} SELinux.
 
-Per gestire questo meccanismo ciascun processo porta con sé tre distinti
+Per gestire questo meccanismo ciascun processo porta con sé tre distinti
 insiemi di \textit{capabilities}, che vengono denominati rispettivamente
 \textit{effective}, \textit{permitted} ed \textit{inherited}. Questi insiemi
 vengono mantenuti in forma di tre diverse maschere binarie,\footnote{il kernel
@@ -2964,26 +2964,26 @@ vengono mantenuti in forma di tre diverse maschere binarie,\footnote{il kernel
   all'interno della \struct{task\_struct} di ciascun processo (vedi
   fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
   \texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
-  \texttt{kernel\_cap\_t}; questo è attualmente definito come intero a 32 bit,
+  \texttt{kernel\_cap\_t}; questo è attualmente definito come intero a 32 bit,
   il che comporta un massimo di 32 \textit{capabilities} distinte.} in cui
-ciascun bit corrisponde ad una capacità diversa.
+ciascun bit corrisponde ad una capacità diversa.
 
 L'utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile
 per l'uso delle \textit{capabilities}, con scopi analoghi a quelli per cui
 sono mantenuti i diversi insiemi di identificatori di
-sez.~\ref{sec:proc_setuid}; il loro significato è il seguente:
+sez.~\ref{sec:proc_setuid}; il loro significato è il seguente:
 \begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
 \item[\textit{effective}] l'insieme delle \textit{capabilities}
-  ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal
+  ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal
   kernel quando deve eseguire il controllo di accesso per le varie operazioni
   compiute dal processo.
 \item[\textit{permitted}] l'insieme delle \textit{capabilities}
-  ``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo
-  \textsl{può} impostare come \textsl{effettive}. Se un processo cancella una
-  capacità da questo insieme non potrà più riassumerla (almeno che non esegua
-  un programma che è \acr{suid} di root).
+  ``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo
+  \textsl{può} impostare come \textsl{effettive}. Se un processo cancella una
+  capacità da questo insieme non potrà più riassumerla (almeno che non esegua
+  un programma che è \acr{suid} di root).
 \item[\textit{inherited}] l'insieme delle \textit{capabilities}
-  ``\textsl{ereditabili}'', cioè quelle che vengono trasmesse ad un nuovo
+  ``\textsl{ereditabili}'', cioè quelle che vengono trasmesse ad un nuovo
   programma eseguito attraverso una chiamata ad \func{exec} (con l'eccezione
   del caso che questo sia \acr{suid} di root).
 \label{sec:capabilities_set}
@@ -2995,22 +2995,22 @@ mantiene un insieme generale valido per tutto il sistema, chiamato
 volta che un programma viene posto in esecuzione con \func{exec} il contenuto
 degli insiemi \textit{effective} e \textit{permitted} vengono mascherati con
 un \textsl{AND} binario del contenuto corrente del \textit{capabilities
-  bounding set}, così che il nuovo processo potrà disporre soltanto delle
-capacità in esso elencate.
+  bounding set}, così che il nuovo processo potrà disporre soltanto delle
+capacità in esso elencate.
 
-Il \textit{capabilities bounding set} è un parametro di sistema, accessibile
+Il \textit{capabilities bounding set} è un parametro di sistema, accessibile
 attraverso il contenuto del file \procfile{/proc/sys/kernel/cap-bound}, che per
 questa sua caratteristica consente di impostare un limite generale alle
-capacità che possono essere accordate ai vari processi.  Questo valore può
+capacità che possono essere accordate ai vari processi.  Questo valore può
 essere impostato ad un valore arbitrario esclusivamente dal primo processo
-eseguito nel sistema (di norma cioè da \texttt{/sbin/init}), ogni processo
-eseguito successivamente (cioè con \textsl{pid} diverso da 1) anche se
-eseguito con privilegi di amministratore potrà soltanto rimuovere uno dei bit
-già presenti dell'insieme: questo significa che una volta rimossa una
-\textit{capability} dal \textit{capabilities bounding set} essa non sarà più
+eseguito nel sistema (di norma cioè da \texttt{/sbin/init}), ogni processo
+eseguito successivamente (cioè con \textsl{pid} diverso da 1) anche se
+eseguito con privilegi di amministratore potrà soltanto rimuovere uno dei bit
+già presenti dell'insieme: questo significa che una volta rimossa una
+\textit{capability} dal \textit{capabilities bounding set} essa non sarà più
 disponibile, neanche per l'amministratore, a meno di un riavvio.
 
-Quando un programma viene messo in esecuzione\footnote{cioè quando viene
+Quando un programma viene messo in esecuzione\footnote{cioè quando viene
   eseguita la \func{execve} con cui lo si lancia; in corrispondenza di una
   \func{fork} le \textit{capabilities} non vengono modificate.} esso eredita
 (nel senso che assume negli insiemi \textit{effective} e \textit{permitted})
@@ -3018,11 +3018,11 @@ le \textit{capabilities} mantenute nell'insieme \textit{inherited}, a meno che
 non sia eseguito un programma \acr{suid} di root o la \func{exec} sia stata
 eseguita da un programma con \textsl{uid} reale zero; in tal caso il programma
 ottiene tutte le \textit{capabilities} presenti nel \textit{capabilities
-  bounding set}. In questo modo si può far si che ad un processo eseguito in
+  bounding set}. In questo modo si può far si che ad un processo eseguito in
 un secondo tempo possano essere trasmesse solo un insieme limitato di
-capacità, impedendogli di recuperare quelle assenti nell'insieme
+capacità, impedendogli di recuperare quelle assenti nell'insieme
 \textit{inherited}. Si tenga presente invece che attraverso una \func{fork}
-vengono mantenute le stesse capacità del processo padre.
+vengono mantenute le stesse capacità del processo padre.
 
 
 % TODO verificare per process capability bounding set, vedi:
@@ -3035,69 +3035,69 @@ vengono mantenute le stesse capacit
 
 
 Un elenco delle delle \textit{capabilities} disponibili su Linux, con una
-breve descrizione ed il nome delle costanti che le identificano, è riportato
+breve descrizione ed il nome delle costanti che le identificano, è riportato
 in tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa
   tabella, ripreso dalla pagina di manuale (accessibile con \texttt{man
-    capabilities}) e dalle definizioni in \texttt{linux/capabilities.h}, è
-  aggiornato al kernel 2.6.26.} la tabella è divisa in due parti, la prima
+    capabilities}) e dalle definizioni in \texttt{linux/capabilities.h}, è
+  aggiornato al kernel 2.6.26.} la tabella è divisa in due parti, la prima
 riporta le \textit{capabilities} previste anche nella bozza dello standard
-POSIX1.e, la seconda quelle specifiche di Linux.  Come si può notare dalla
-tabella alcune \textit{capabilities} attengono a singole funzionalità e sono
+POSIX1.e, la seconda quelle specifiche di Linux.  Come si può notare dalla
+tabella alcune \textit{capabilities} attengono a singole funzionalità e sono
 molto specializzate, mentre altre hanno un campo di applicazione molto vasto,
-che è opportuno dettagliare maggiormente.
+che è opportuno dettagliare maggiormente.
 
 \begin{table}[!h!bt]
   \centering
   \footnotesize
   \begin{tabular}{|l|p{12cm}|}
     \hline
-    \textbf{Capacità}&\textbf{Descrizione}\\
+    \textbf{Capacità}&\textbf{Descrizione}\\
     \hline
     \hline
 %
 % POSIX-draft defined capabilities.
 %
-    \const{CAP\_AUDIT\_WRITE}&La capacità di scrivere dati nel giornale di
+    \const{CAP\_AUDIT\_WRITE}&La capacità di scrivere dati nel giornale di
                               auditing del kernel (dal kernel 2.6.11).\\ 
-    \const{CAP\_AUDIT\_CONTROL}& La capacità di abilitare e disabilitare il
+    \const{CAP\_AUDIT\_CONTROL}& La capacità di abilitare e disabilitare il
                               controllo dell'auditing (dal kernel 2.6.11).\\ 
     % TODO verificare questa roba dell'auditing
-    \const{CAP\_CHOWN}      & La capacità di cambiare proprietario e gruppo
+    \const{CAP\_CHOWN}      & La capacità di cambiare proprietario e gruppo
                               proprietario di un file (vedi
                               sez.~\ref{sec:file_ownership_management}).\\
-    \const{CAP\_DAC\_OVERRIDE}& La capacità di evitare il controllo dei
+    \const{CAP\_DAC\_OVERRIDE}& La capacità di evitare il controllo dei
                               permessi di lettura, scrittura ed esecuzione dei
                               file,\footnotemark (vedi
                               sez.~\ref{sec:file_access_control}).\\
-    \const{CAP\_DAC\_READ\_SEARCH}& La capacità di evitare il controllo dei
+    \const{CAP\_DAC\_READ\_SEARCH}& La capacità di evitare il controllo dei
                               permessi di lettura ed esecuzione per
                               le directory (vedi
                               sez.~\ref{sec:file_access_control}).\\
-    \const{CAP\_FOWNER}     & La capacità di evitare il controllo della
-                              proprietà di un file per tutte
+    \const{CAP\_FOWNER}     & La capacità di evitare il controllo della
+                              proprietà di un file per tutte
                               le operazioni privilegiate non coperte dalle
                               precedenti \const{CAP\_DAC\_OVERRIDE} e
                               \const{CAP\_DAC\_READ\_SEARCH}.\\
-    \const{CAP\_FSETID}     & La capacità di evitare la cancellazione
+    \const{CAP\_FSETID}     & La capacità di evitare la cancellazione
                               automatica dei bit \itindex{suid~bit} \acr{suid}
                               e \itindex{sgid~bit} \acr{sgid} quando un file
                               per i quali sono impostati viene modificato da
-                              un processo senza questa capacità e la capacità
+                              un processo senza questa capacità e la capacità
                               di impostare il bit \acr{sgid} su un file anche
-                              quando questo è relativo ad un gruppo cui non si
+                              quando questo è relativo ad un gruppo cui non si
                               appartiene (vedi
                               sez.~\ref{sec:file_perm_management}).\\ 
-    \const{CAP\_SETFCAP}    & La capacità di impostare le
+    \const{CAP\_SETFCAP}    & La capacità di impostare le
                               \textit{capabilities} di un file (dal kernel
                               2.6.24).\\  
-    \const{CAP\_KILL}       & La capacità di mandare segnali a qualunque
+    \const{CAP\_KILL}       & La capacità di mandare segnali a qualunque
                               processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
-    \const{CAP\_SETGID}     & La capacità di manipolare i group ID dei
+    \const{CAP\_SETGID}     & La capacità di manipolare i group ID dei
                               processi, sia il principale che i supplementari,
                               (vedi sez.~\ref{sec:proc_setgroups}) che quelli
                               trasmessi tramite i socket \textit{unix domain}
                               (vedi sez.~\ref{sec:unix_socket}).\\
-    \const{CAP\_SETUID}     & La capacità di manipolare gli user ID del
+    \const{CAP\_SETUID}     & La capacità di manipolare gli user ID del
                               processo (vedi sez.~\ref{sec:proc_setuid}) e di
                               trasmettere un user ID arbitrario nel passaggio
                               delle credenziali coi socket \textit{unix
@@ -3106,72 +3106,72 @@ che 
 % Linux specific capabilities
 %
 \hline
-    \const{CAP\_IPC\_LOCK}  & La capacità di effettuare il \textit{memory
+    \const{CAP\_IPC\_LOCK}  & La capacità di effettuare il \textit{memory
                               locking} \itindex{memory~locking} con le
                               funzioni \func{mlock}, \func{mlockall},
                               \func{shmctl}, \func{mmap} (vedi
                               sez.~\ref{sec:proc_mem_lock} e 
                               sez.~\ref{sec:file_memory_map}). \\  
-    \const{CAP\_IPC\_OWNER} & La capacità di evitare il controllo dei permessi
+    \const{CAP\_IPC\_OWNER} & La capacità di evitare il controllo dei permessi
                               per le operazioni sugli oggetti di
                               intercomunicazione fra processi (vedi
                               sez.~\ref{sec:ipc_sysv}).\\  
-    \const{CAP\_LEASE}      & La capacità di creare dei \textit{file lease}
+    \const{CAP\_LEASE}      & La capacità di creare dei \textit{file lease}
                               \index{file!lease} (vedi
                               sez.~\ref{sec:file_asyncronous_lease})
                               pur non essendo proprietari del file (dal kernel
                               2.4).\\ 
-    \const{CAP\_LINUX\_IMMUTABLE}& La capacità di impostare sui file gli
+    \const{CAP\_LINUX\_IMMUTABLE}& La capacità di impostare sui file gli
                               attributi \textit{immutable} e
                               \itindex{append~mode} \textit{append only} (se
                               supportati).\\
-    \const{CAP\_MKNOD}      & La capacità di creare
+    \const{CAP\_MKNOD}      & La capacità di creare
                               \index{file!di~dispositivo} file di dispositivo
                               con \func{mknod} (vedi
                               sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\ 
-    \const{CAP\_NET\_ADMIN} & La capacità di eseguire alcune operazioni
+    \const{CAP\_NET\_ADMIN} & La capacità di eseguire alcune operazioni
                               privilegiate sulla rete.\\
-    \const{CAP\_NET\_BIND\_SERVICE}& La capacità di porsi in ascolto
+    \const{CAP\_NET\_BIND\_SERVICE}& La capacità di porsi in ascolto
                               su porte riservate (vedi
                               sez.~\ref{sec:TCP_func_bind}).\\ 
-    \const{CAP\_NET\_BROADCAST}& La capacità di consentire l'uso di socket in
+    \const{CAP\_NET\_BROADCAST}& La capacità di consentire l'uso di socket in
                               \itindex{broadcast} \textit{broadcast} e
                               \itindex{multicast} \textit{multicast}.\\ 
-    \const{CAP\_NET\_RAW}   & La capacità di usare socket \texttt{RAW} e
+    \const{CAP\_NET\_RAW}   & La capacità di usare socket \texttt{RAW} e
                               \texttt{PACKET} (vedi sez.~\ref{sec:sock_type}).\\
-    \const{CAP\_SETPCAP}    & La capacità di impostare o rimuovere una
-                              capacità.\\ 
+    \const{CAP\_SETPCAP}    & La capacità di impostare o rimuovere una
+                              capacità.\\ 
     % TODO cambiata nel 2.4.24 rc1 ? 
-    \const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti
+    \const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti
                               amministrativi. \\
-    \const{CAP\_SYS\_BOOT}  & La capacità di fare eseguire un riavvio del
+    \const{CAP\_SYS\_BOOT}  & La capacità di fare eseguire un riavvio del
                               sistema.\\
 % TODO trattare reboot e kexec 
-    \const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione
+    \const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione
                               \func{chroot} (vedi
                               sez.~\ref{sec:file_chroot}).\\
-    \const{CAP\_MAC\_ADMIN} & La capacità amministrare il MAC di Smack (dal
+    \const{CAP\_MAC\_ADMIN} & La capacità amministrare il MAC di Smack (dal
                               kernel 2.6.25).\\  
-    \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il MAC di Smack (dal
+    \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il MAC di Smack (dal
                               kernel 2.6.25).\\  
-    \const{CAP\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del
+    \const{CAP\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del
                               kernel. \\ 
-    \const{CAP\_SYS\_NICE}  & La capacità di modificare le priorità dei
+    \const{CAP\_SYS\_NICE}  & La capacità di modificare le priorità dei
                               processi. \\ 
-    \const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di
+    \const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di
                               \textit{accounting} dei processi (vedi
                               sez.~\ref{sec:sys_bsd_accounting}).\\ 
-    \const{CAP\_SYS\_PTRACE}& La capacità  di tracciare qualunque processo con
+    \const{CAP\_SYS\_PTRACE}& La capacità  di tracciare qualunque processo con
                               \func{ptrace} (vedi 
                               sez.~\ref{sec:xxx_ptrace}).\\
-    \const{CAP\_SYS\_RAWIO} & La capacità di eseguire operazioni sulle porte
+    \const{CAP\_SYS\_RAWIO} & La capacità di eseguire operazioni sulle porte
                               di I/O con \func{ioperm} e \func{iopl} (vedi
                               sez.~\ref{sec:file_io_port}).\\
-    \const{CAP\_SYS\_RESOURCE}& La capacità di superare le limitazioni sulle
+    \const{CAP\_SYS\_RESOURCE}& La capacità di superare le limitazioni sulle
                               risorse.\\ 
-    \const{CAP\_SYS\_TIME}  & La capacità di modificare il tempo di sistema
+    \const{CAP\_SYS\_TIME}  & La capacità di modificare il tempo di sistema
                               (vedi sez.~\ref{sec:sys_time}).\\ 
-    \const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup}
+    \const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup}
                               della console, con la funzione
                               \func{vhangup}.\\
     \hline
@@ -3185,8 +3185,8 @@ che 
   controllo di accesso chiamato \itindex{Discrectionary~Access~Control~(DAC)}
   \textit{Discrectionary Access Control} (da cui il nome DAC).}
 
-La prima di queste capacità ``\textsl{ampie}'' è \const{CAP\_FOWNER}, che
-rimuove le restrizioni poste ad un processo che non ha la proprietà di un file
+La prima di queste capacità ``\textsl{ampie}'' è \const{CAP\_FOWNER}, che
+rimuove le restrizioni poste ad un processo che non ha la proprietà di un file
 in un vasto campo di operazioni;\footnote{vale a dire la richiesta che
   l'user-ID effettivo del processo (o meglio il \textit{filesystem user-ID},
   vedi sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.}
@@ -3195,18 +3195,18 @@ sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le
 impostazioni degli attributi estesi e delle ACL (vedi
 sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
 \itindex{sticky~bit} \textit{sticky bit} nella cancellazione dei file (vedi
-sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
+sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
 \const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi
 sez.~\ref{sec:file_open} e sez.~\ref{sec:file_fcntl}) senza restrizioni.
 
-Una seconda capacità che copre diverse operazioni, in questo caso riguardanti
-la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni
+Una seconda capacità che copre diverse operazioni, in questo caso riguardanti
+la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni
 privilegiate dei socket (vedi sez.~\ref{sec:sock_generic_options}), abilitare
 il \itindex{multicast} \textit{multicasting}, eseguire la configurazione delle
 interfacce di rete (vedi sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la
 tabella di instradamento.
 
-Una terza \textit{capability} con vasto campo di applicazione è
+Una terza \textit{capability} con vasto campo di applicazione è
 \const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative,
 come impostare le quote disco (vedi sez.\ref{sec:disk_quota}), attivare e
 disattivare la swap, montare, rimontare e smontare filesystem (vedi
@@ -3223,19 +3223,19 @@ sez.~\ref{sec:io_priority}), usare la funzione \func{lookup\_dcookie} (vedi
 sez.~\ref{sec:xxx_profiling}), usare \const{CLONE\_NEWNS} con \func{unshare},
 (vedi sez.~\ref{sec:process_clone}).
 
-Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
-aumentare le priorità di esecuzione dei processi, come la diminuzione del
+Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
+aumentare le priorità di esecuzione dei processi, come la diminuzione del
 valore di \textit{nice} (vedi sez.~\ref{sec:proc_sched_stand}), l'uso delle
-priorità \textit{real-time} (vedi sez.~\ref{sec:proc_real_time}), o
-l'impostazione delle affinità di processore (vedi
-sez.~\ref{sec:proc_sched_multiprocess}); ma con l'introduzione di priorità
+priorità \textit{real-time} (vedi sez.~\ref{sec:proc_real_time}), o
+l'impostazione delle affinità di processore (vedi
+sez.~\ref{sec:proc_sched_multiprocess}); ma con l'introduzione di priorità
 anche riguardo le operazioni di accesso al disco, e, nel caso di sistemi NUMA,
-alla memoria, essa viene a coprire anche la possibilità di assegnare priorità
+alla memoria, essa viene a coprire anche la possibilità di assegnare priorità
 arbitrarie nell'accesso a disco (vedi sez.~\ref{sec:io_priority}) e nelle
 politiche di allocazione delle pagine di memoria ai nodi di un sistema NUMA.
 
 Infine la \textit{capability} \const{CAP\_SYS\_RESOURCE} attiene alla
-possibilità di superare i limiti imposti sulle risorse di sistema, come usare
+possibilità di superare i limiti imposti sulle risorse di sistema, come usare
 lo spazio disco riservato all'amministratore sui filesystem che lo supportano,
 usare la funzione \func{ioctl} per controllare il \textit{journaling} sul
 filesystem \acr{ext3}, non subire le quote disco, aumentare i limiti sulle
@@ -3260,13 +3260,13 @@ loro rispettivi prototipi sono:
 
   
   \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 in caso
-    di errore, nel qual caso \var{errno} può assumere i valori:
+    di errore, nel qual caso \var{errno} può assumere i valori:
     \begin{errlist}
-    \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
-    \item[\errcode{EPERM}] si è tentato di aggiungere una capacità
+    \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
+    \item[\errcode{EPERM}] si è tentato di aggiungere una capacità
       nell'insieme delle \textit{capabilities} permesse, o di impostare una
-      capacità non presente nell'insieme di quelle permesse negli insieme
-      delle effettive o ereditate, o si è cercato di impostare una
+      capacità non presente nell'insieme di quelle permesse negli insieme
+      delle effettive o ereditate, o si è cercato di impostare una
       \textit{capability} di un altro processo senza avare
       \const{CAP\_SETPCAP}. 
   \end{errlist}
@@ -3279,18 +3279,18 @@ Queste due funzioni prendono come argomenti due tipi di dati dedicati,
 definiti come puntatori a due strutture specifiche di Linux, illustrate in
 fig.~\ref{fig:cap_kernel_struct}. Per poterle utilizzare occorre anche
 cancellare la macro \macro{\_POSIX\_SOURCE}.\footnote{per farlo occorre
-  utilizzare la direttiva di preprocessore \direct{undef}; si dovrà cioè
+  utilizzare la direttiva di preprocessore \direct{undef}; si dovrà cioè
   inserire una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
   \texttt{sys/capability.h}.} Si tenga presente che le strutture di
 fig.~\ref{fig:cap_kernel_struct}, come i prototipi delle due funzioni
 \func{capget} e \func{capset}, sono soggette ad essere modificate con il
 cambiamento del kernel (in particolare i tipi di dati delle strutture) ed
-anche se finora l'interfaccia è risultata stabile, non c'è nessuna
+anche se finora l'interfaccia è risultata stabile, non c'è nessuna
 assicurazione che questa venga mantenuta.\footnote{anzi, visto lo scarso
-  utilizzo di questa funzionalità ci sono state varie discussioni fra gli
+  utilizzo di questa funzionalità ci sono state varie discussioni fra gli
   sviluppatori del kernel relative all'eliminarla o al modificarla
   radicalmente.} Pertanto se si vogliono scrivere programmi portabili che
-possano essere eseguiti su qualunque versione del kernel è opportuno
+possano essere eseguiti su qualunque versione del kernel è opportuno
 utilizzare le interfacce di alto livello.
 
 \begin{figure}[!htb]
@@ -3314,17 +3314,17 @@ dalla costante \const{\_LINUX\_CAPABILITY\_VERSION} di
 fig.~\ref{fig:cap_kernel_struct}) altrimenti le funzioni ritorneranno con un
 errore di \errcode{EINVAL}, restituendo nel campo stesso il valore corretto
 della versione in uso.  La struttura a cui deve puntare l'argomento
-\param{datap} invece conterrà i valori letti o da impostare per i tre insiemi
-delle capacità del processo.
+\param{datap} invece conterrà i valori letti o da impostare per i tre insiemi
+delle capacità del processo.
 
 Dato che le precedenti funzioni, oltre ad essere specifiche di Linux, non
-garantiscono la stabilità nell'interfaccia, è sempre opportuno effettuare la
+garantiscono la stabilità nell'interfaccia, è sempre opportuno effettuare la
 gestione delle \textit{capabilities} utilizzando le funzioni di libreria a
 questo dedicate. Queste funzioni, che seguono quanto previsto nelle bozze
 dello standard POSIX.1e, non fanno parte delle \acr{glibc} e sono fornite in
-una libreria a parte,\footnote{la libreria è \texttt{libcap2}, nel caso di
-  Debian può essere installata con il pacchetto omonimo.} pertanto se un
-programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta
+una libreria a parte,\footnote{la libreria è \texttt{libcap2}, nel caso di
+  Debian può essere installata con il pacchetto omonimo.} pertanto se un
+programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta
 libreria attraverso l'opzione \texttt{-lcap} del compilatore.
 
 Le funzioni dell'interfaccia delle bozze di POSIX.1e prevedono l'uso di uno
@@ -3332,16 +3332,16 @@ tipo di dato opaco, \type{cap\_t}, come puntatore ai dati mantenuti nel
 cosiddetto \textit{capability state},\footnote{si tratta in sostanza di un
   puntatore ad una struttura interna utilizzata dalle librerie, i cui campi
   non devono mai essere acceduti direttamente.} in sono memorizzati tutti i
-dati delle \textit{capabilities}. In questo modo è possibile mascherare i
+dati delle \textit{capabilities}. In questo modo è possibile mascherare i
 dettagli della gestione di basso livello, che potranno essere modificati senza
 dover cambiare le funzioni dell'interfaccia, che faranno riferimento soltanto
 ad oggetti di questo tipo.  L'interfaccia pertanto non soltanto fornisce le
 funzioni per modificare e leggere le \textit{capabilities}, ma anche quelle
 per gestire i dati attraverso \type{cap\_t}.
 
-La prima funzione dell'interfaccia è quella che permette di inizializzare un
+La prima funzione dell'interfaccia è quella che permette di inizializzare un
 \textit{capability state}, allocando al contempo la memoria necessaria per i
-relativi dati. La funzione è \funcd{cap\_init} ed il suo prototipo è:
+relativi dati. La funzione è \funcd{cap\_init} ed il suo prototipo è:
 \begin{functions}
   \headdecl{sys/capability.h}
 
@@ -3349,19 +3349,19 @@ relativi dati. La funzione 
   Crea ed inizializza un \textit{capability state}.
   
   \bodydesc{La funzione ritorna un valore non nullo in caso di successo e
-    \macro{NULL} in caso di errore, nel qual caso \var{errno} assumerà il
+    \macro{NULL} in caso di errore, nel qual caso \var{errno} assumerà il
     valore \errval{ENOMEM}.
   }
 \end{functions}
 
 La funzione restituisce il puntatore \type{cap\_t} ad uno stato inizializzato
-con tutte le \textit{capabilities} azzerate. In caso di errore (cioè quando
-non c'è memoria sufficiente ad allocare i dati) viene restituito \macro{NULL}
+con tutte le \textit{capabilities} azzerate. In caso di errore (cioè quando
+non c'è memoria sufficiente ad allocare i dati) viene restituito \macro{NULL}
 ed \var{errno} viene impostata a \errval{ENOMEM}.  La memoria necessaria a
-mantenere i dati viene automaticamente allocata da \func{cap\_init}, ma dovrà
-essere disallocata esplicitamente quando non è più necessaria utilizzando, per
+mantenere i dati viene automaticamente allocata da \func{cap\_init}, ma dovrà
+essere disallocata esplicitamente quando non è più necessaria utilizzando, per
 questo l'interfaccia fornisce una apposita funzione, \funcd{cap\_free}, il cui
-prototipo è:
+prototipo è:
 \begin{functions}
   \headdecl{sys/capability.h}
 
@@ -3369,22 +3369,22 @@ prototipo 
   Disalloca la memoria allocata per i dati delle \textit{capabilities}.
   
   \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+    errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
   }
 \end{functions}
 
 La funzione permette di liberare la memoria allocata dalle altre funzioni
 della libreria sia per un \textit{capability state}, nel qual caso l'argomento
-dovrà essere un dato di tipo \type{cap\_t}, che per una descrizione testuale
-dello stesso,\footnote{cioè quanto ottenuto tramite la funzione
-  \func{cap\_to\_text}.} nel qual caso l'argomento dovrà essere un dato di
-tipo \texttt{char *}. Per questo l'argomento \param{obj\_d} è dichiarato come
+dovrà essere un dato di tipo \type{cap\_t}, che per una descrizione testuale
+dello stesso,\footnote{cioè quanto ottenuto tramite la funzione
+  \func{cap\_to\_text}.} nel qual caso l'argomento dovrà essere un dato di
+tipo \texttt{char *}. Per questo l'argomento \param{obj\_d} è dichiarato come
 \texttt{void *} e deve sempre corrispondere ad un puntatore ottenuto tramite
-le altre funzioni della libreria, altrimenti la funzione fallirà con un errore
+le altre funzioni della libreria, altrimenti la funzione fallirà con un errore
 di \errval{EINVAL}.
 
-Infine si può creare una copia di un \textit{capability state} ottenuto in
-precedenza tramite la funzione \funcd{cap\_dup}, il cui prototipo è:
+Infine si può creare una copia di un \textit{capability state} ottenuto in
+precedenza tramite la funzione \funcd{cap\_dup}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/capability.h}
 
@@ -3392,23 +3392,23 @@ precedenza tramite la funzione \funcd{cap\_dup}, il cui prototipo 
   Duplica un \textit{capability state} restituendone una copia.
   
   \bodydesc{La funzione ritorna un valore non nullo in caso di successo e
-    \macro{NULL} in caso di errore, nel qual caso \var{errno} potrà assumere i
+    \macro{NULL} in caso di errore, nel qual caso \var{errno} potrà assumere i
     valori \errval{ENOMEM} o \errval{EINVAL}.  
   }
 \end{functions}
 
 La funzione crea una copia del \textit{capability state} posto all'indirizzo
-\param{cap\_p} che si è passato come argomento, restituendo il puntatore alla
-copia, che conterrà gli stessi valori delle \textit{capabilities} presenti
+\param{cap\_p} che si è passato come argomento, restituendo il puntatore alla
+copia, che conterrà gli stessi valori delle \textit{capabilities} presenti
 nell'originale. La memoria necessaria viene allocata automaticamente dalla
 funzione. Una volta effettuata la copia i due \textit{capability state}
 potranno essere modificati in maniera completamente
-indipendente.\footnote{alla fine delle operazioni si ricordi però di
+indipendente.\footnote{alla fine delle operazioni si ricordi però di
   disallocare anche la copia, oltre all'originale. }
 
 Una seconda classe di funzioni di servizio previste dall'interfaccia sono
 quelle per la gestione dei dati contenuti all'interno di un \textit{capability
-  state}; la prima di queste è \funcd{cap\_clear}, il cui prototipo è:
+  state}; la prima di queste è \funcd{cap\_clear}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/capability.h}
 
@@ -3417,7 +3417,7 @@ quelle per la gestione dei dati contenuti all'interno di un \textit{capability
   \textit{capabilities}.
   
   \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+    errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
   }
 \end{functions}
 
@@ -3443,7 +3443,7 @@ rispettivamente di leggere o impostare il valore di un flag delle
   Imposta il valore di una \textit{capability}.
   
   \bodydesc{Le funzioni ritornano 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+    errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
 }
 \end{functions}
 
@@ -3451,8 +3451,8 @@ In entrambe le funzioni l'argomento \param{cap\_p} indica il puntatore al
 \textit{capability state} su cui operare, mentre l'argomento \param{flag}
 indica su quale dei tre insiemi illustrati a
 pag.~\pageref{sec:capabilities_set} si intende operare. Questi devono essere
-specificati con una variabile di tipo \type{cap\_flag\_t} che può assumere
-esclusivamente\footnote{si tratta in effetti di un tipo enumerato, come si può
+specificati con una variabile di tipo \type{cap\_flag\_t} che può assumere
+esclusivamente\footnote{si tratta in effetti di un tipo enumerato, come si può
   verificare dalla sua definizione che si trova in
   \texttt{/usr/include/sys/capability.h}.} uno dei valori illustrati in
 tab.~\ref{tab:cap_set_identifier}.
@@ -3465,9 +3465,9 @@ tab.~\ref{tab:cap_set_identifier}.
     \textbf{Valore} & \textbf{Significato} \\
     \hline
     \hline
-    \const{CAP\_EFFECTIVE}  & Capacità dell'insieme \textsl{effettivo}.\\
-    \const{CAP\_PERMITTED}  & Capacità dell'insieme \textsl{permesso}.\\ 
-    \const{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
+    \const{CAP\_EFFECTIVE}  & Capacità dell'insieme \textsl{effettivo}.\\
+    \const{CAP\_PERMITTED}  & Capacità dell'insieme \textsl{permesso}.\\ 
+    \const{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
     \hline
   \end{tabular}
   \caption{Valori possibili per il tipo di dato \type{cap\_flag\_t} che
@@ -3475,19 +3475,19 @@ tab.~\ref{tab:cap_set_identifier}.
   \label{tab:cap_set_identifier}
 \end{table}
 
-La capacità che si intende controllare o impostare invece deve essere
-specificata attraverso una variabile di tipo \type{cap\_value\_t}, che può
+La capacità che si intende controllare o impostare invece deve essere
+specificata attraverso una variabile di tipo \type{cap\_value\_t}, che può
 prendere come valore uno qualunque di quelli riportati in
-tab.~\ref{tab:proc_capabilities}, in questo caso però non è possibile
+tab.~\ref{tab:proc_capabilities}, in questo caso però non è possibile
 combinare diversi valori in una maschera binaria, una variabile di tipo
-\type{cap\_value\_t} deve indicare una sola capacità.\footnote{nel file di
-  header citato nella nota precedente il tipo \type{cap\_value\_t} è definito
+\type{cap\_value\_t} deve indicare una sola capacità.\footnote{nel file di
+  header citato nella nota precedente il tipo \type{cap\_value\_t} è definito
   come \ctyp{int}, ma i valori validi sono soltanto quelli di
   tab.~\ref{tab:proc_capabilities}.}  
 
-Infine lo stato di una capacità è descritto ad una variabile di tipo
-\type{cap\_flag\_value\_t}, che a sua volta può assumere soltanto
-uno\footnote{anche questo è un tipo enumerato.} dei valori di
+Infine lo stato di una capacità è descritto ad una variabile di tipo
+\type{cap\_flag\_value\_t}, che a sua volta può assumere soltanto
+uno\footnote{anche questo è un tipo enumerato.} dei valori di
 tab.~\ref{tab:cap_value_type}.
 
 \begin{table}[htb]
@@ -3498,30 +3498,30 @@ tab.~\ref{tab:cap_value_type}.
     \textbf{Valore} & \textbf{Significato} \\
     \hline
     \hline
-    \const{CAP\_CLEAR}& La capacità non è impostata.\\ 
-    \const{CAP\_SET}  & La capacità è impostata.\\
+    \const{CAP\_CLEAR}& La capacità non è impostata.\\ 
+    \const{CAP\_SET}  & La capacità è impostata.\\
     \hline
   \end{tabular}
   \caption{Valori possibili per il tipo di dato \type{cap\_flag\_value\_t} che
-    indica lo stato di una capacità.}
+    indica lo stato di una capacità.}
   \label{tab:cap_value_type}
 \end{table}
 
-La funzione \func{cap\_get\_flag} legge lo stato della capacità indicata
+La funzione \func{cap\_get\_flag} legge lo stato della capacità indicata
 dall'argomento \param{cap} all'interno dell'insieme indicato dall'argomento
 \param{flag} e ne restituisce il valore nella variabile posta all'indirizzo
-puntato dall'argomento \param{value\_p}; è possibile cioè leggere soltanto uno
-stato di una capacità alla volta.
+puntato dall'argomento \param{value\_p}; è possibile cioè leggere soltanto uno
+stato di una capacità alla volta.
 
-La funzione \func{cap\_set\_flag} può invece impostare in una sola chiamata
-più \textit{capabilities}, anche se solo all'interno dello stesso insieme. Per
+La funzione \func{cap\_set\_flag} può invece impostare in una sola chiamata
+più \textit{capabilities}, anche se solo all'interno dello stesso insieme. Per
 questo motivo essa prende un vettore di valori di tipo \type{cap\_value\_t}
 nell'argomento \param{caps}, la cui dimensione viene specificata dall'argomento
 \param{ncap}. Il tipo di impostazione da eseguire (cancellazione o
 impostazione) viene indicato dall'argomento \param{value}.
 
 Per la visualizzazione dello stato delle \textit{capabilities} l'interfaccia
-prevede una funzione apposita, \funcd{cap\_to\_text}, il cui prototipo è:
+prevede una funzione apposita, \funcd{cap\_to\_text}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/capability.h}
 
@@ -3531,7 +3531,7 @@ prevede una funzione apposita, \funcd{cap\_to\_text}, il cui prototipo 
   
   \bodydesc{La funzione ritorna un puntatore alla stringa con la descrizione
     delle \textit{capabilities} in caso di successo e \val{NULL} in caso di
-    errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL} o
+    errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL} o
     \errval{ENOMEM}.
   }
 \end{functions}
@@ -3541,13 +3541,13 @@ testuale del contenuto del \textit{capabilities state} \param{caps} passato
 come argomento, e, qualora l'argomento \param{length\_p} sia diverso da
 \val{NULL}, restituisce nella variabile intera da questo puntata la lunghezza
 della stringa. La stringa restituita viene allocata automaticamente dalla
-funzione e pertanto dovrà essere liberata con \func{cap\_free}.
+funzione e pertanto dovrà essere liberata con \func{cap\_free}.
 
 Fin quei abbiamo trattato solo le funzioni di servizio relative alla
 manipolazione dei \textit{capabilities state}; l'interfaccia di gestione
-prevede però anche le funzioni per la gestione delle \textit{capabilities}
-stesse. La prima di queste è \funcd{cap\_get\_proc} che consente la lettura
-delle \textit{capabilities} del processo corrente, il suo prototipo è:
+prevede però anche le funzioni per la gestione delle \textit{capabilities}
+stesse. La prima di queste è \funcd{cap\_get\_proc} che consente la lettura
+delle \textit{capabilities} del processo corrente, il suo prototipo è:
 \begin{functions}
   \headdecl{sys/capability.h}
 
@@ -3555,22 +3555,22 @@ delle \textit{capabilities} del processo corrente, il suo prototipo 
   Legge le \textit{capabilities} del processo corrente.
   
   \bodydesc{La funzione ritorna un valore diverso da \val{NULL} in caso di
-    successo e \val{NULL} in caso di errore, nel qual caso \var{errno} può
+    successo e \val{NULL} in caso di errore, nel qual caso \var{errno} può
     assumere i valori \errval{EINVAL}, \errval{EPERM} o \errval{ENOMEM}.  }
 \end{functions}
 
 La funzione legge il valore delle \textit{capabilities} associate al processo
 da cui viene invocata, restituendo il risultato tramite il puntatore ad un
 \textit{capabilities state} contenente tutti i dati che provvede ad allocare
-autonomamente e che di nuovo occorrerà liberare con \func{cap\_free} quando
-non sarà più utilizzato.
+autonomamente e che di nuovo occorrerà liberare con \func{cap\_free} quando
+non sarà più utilizzato.
 
 Se invece si vogliono leggere le \textit{capabilities} di un processo
 specifico occorre usare la funzione \funcd{capgetp}, il cui
-prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
+prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
   prototipo sbagliato, che prevede un valore di ritorno di tipo \type{cap\_t},
-  ma il valore di ritorno è intero, come si può verificare anche dalla
-  dichiarazione della stessa in \texttt{sys/capability.h}.} è:
+  ma il valore di ritorno è intero, come si può verificare anche dalla
+  dichiarazione della stessa in \texttt{sys/capability.h}.} è:
 \begin{functions}
   \headdecl{sys/capability.h}
 
@@ -3578,7 +3578,7 @@ prototipo\footnote{su alcune pagine di manuale la funzione 
   Legge le \textit{capabilities} del processo indicato da \param{pid}.
   
   \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
+    errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
     \errval{EPERM} o \errval{ENOMEM}.  
   }
 \end{functions}
@@ -3589,9 +3589,9 @@ con l'argomento \param{pid}, e restituisce il risultato nel
 \textit{capabilities state} posto all'indirizzo indicato con l'argomento
 \param{cap\_d}; a differenza della precedente in questo caso il
 \textit{capability state} deve essere stato creato in precedenza. Qualora il
-processo indicato non esista si avrà un errore di \errval{ESRCH}. Gli stessi
+processo indicato non esista si avrà un errore di \errval{ESRCH}. Gli stessi
 valori possono essere letti direttamente nel filesystem \textit{proc}, nei
-file \texttt{/proc/<pid>/status}; ad esempio per \texttt{init} si otterrà
+file \texttt{/proc/<pid>/status}; ad esempio per \texttt{init} si otterrà
 qualcosa del tipo:
 \begin{Verbatim}
 ...
@@ -3604,7 +3604,7 @@ CapEff: 00000000fffffeff
 Infine per impostare le \textit{capabilities} del processo corrente (non
 esiste una funzione che permetta di cambiare le \textit{capabilities} di un
 altro processo) si deve usare la funzione \funcd{cap\_set\_proc}, il cui
-prototipo è:
+prototipo è:
 \begin{functions}
   \headdecl{sys/capability.h}
 
@@ -3612,26 +3612,26 @@ prototipo 
   Imposta le \textit{capabilities} del processo corrente.
   
   \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
+    errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
     \errval{EPERM} o \errval{ENOMEM}.  
   }
 \end{functions}
 
 La funzione modifica le \textit{capabilities} del processo corrente secondo
 quanto specificato con l'argomento \param{cap\_p}, posto che questo sia
-possibile nei termini spiegati in precedenza (non sarà ad esempio possibile
-impostare capacità non presenti nell'insieme di quelle permesse). In caso di
+possibile nei termini spiegati in precedenza (non sarà ad esempio possibile
+impostare capacità non presenti nell'insieme di quelle permesse). In caso di
 successo i nuovi valori saranno effettivi al ritorno della funzione, in caso
-di fallimento invece lo stato delle capacità resterà invariato. Si tenga
-presente che \textsl{tutte} le capacità specificate tramite \param{cap\_p}
-devono essere permesse; se anche una sola non lo è la funzione fallirà, e per
-quanto appena detto, lo stato delle \textit{capabilities} non verrà modificato
+di fallimento invece lo stato delle capacità resterà invariato. Si tenga
+presente che \textsl{tutte} le capacità specificate tramite \param{cap\_p}
+devono essere permesse; se anche una sola non lo è la funzione fallirà, e per
+quanto appena detto, lo stato delle \textit{capabilities} non verrà modificato
 (neanche per le parti eventualmente permesse).
 
 Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida
-si è distribuito il programma \texttt{getcap.c}, che consente di leggere le
-\textit{capabilities} del processo corrente\footnote{vale a dire di sé stesso,
-  quando lo si lancia, il che può sembrare inutile, ma serve a mostrarci quali
+si è distribuito il programma \texttt{getcap.c}, che consente di leggere le
+\textit{capabilities} del processo corrente\footnote{vale a dire di sé stesso,
+  quando lo si lancia, il che può sembrare inutile, ma serve a mostrarci quali
   sono le \textit{capabilities} standard che ottiene un processo lanciato
   dalla riga di comando.} o tramite l'opzione \texttt{-p}, quelle di un
 processo qualunque il cui pid viene passato come parametro dell'opzione.
@@ -3646,18 +3646,18 @@ processo qualunque il cui pid viene passato come parametro dell'opzione.
   \label{fig:proc_getcap}
 \end{figure}
 
-La sezione principale del programma è riportata in fig.~\ref{fig:proc_getcap},
-e si basa su una condizione sulla variabile \var{pid} che se si è usato
-l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni,
-che si è tralasciata) al valore del \textsl{pid} del processo di cui si vuole
+La sezione principale del programma è riportata in fig.~\ref{fig:proc_getcap},
+e si basa su una condizione sulla variabile \var{pid} che se si è usato
+l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni,
+che si è tralasciata) al valore del \textsl{pid} del processo di cui si vuole
 leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso
 (\texttt{\small 1--6}) si utilizza direttamente (\texttt{\small 2})
-\func{cap\_get\_proc} per ottenere lo stato delle capacità del processo, nel
+\func{cap\_get\_proc} per ottenere lo stato delle capacità del processo, nel
 secondo (\texttt{\small 7--14}) prima si inizializza (\texttt{\small 8}) uno
-stato vuoto e poi (\texttt{\small 9}) si legge il valore delle capacità del
+stato vuoto e poi (\texttt{\small 9}) si legge il valore delle capacità del
 processo indicato.
 
-Il passo successivo è utilizzare (\texttt{\small 16}) \func{cap\_to\_text} per
+Il passo successivo è utilizzare (\texttt{\small 16}) \func{cap\_to\_text} per
 tradurre in una stringa lo stato, e poi (\texttt{\small 17}) stamparlo; infine
 (\texttt{\small 19--20}) si libera la memoria allocata dalle precedenti
 funzioni con \func{cap\_free} per poi ritornare dal ciclo principale della
@@ -3676,18 +3676,18 @@ funzione.
 
 Nelle sezioni precedenti abbiamo trattato in dettaglio le varie informazioni
 che il sistema mantiene negli \itindex{inode} \textit{inode}, e le varie
-funzioni che permettono di modificarle.  Si sarà notato come in realtà queste
-informazioni siano estremamente ridotte.  Questo è dovuto al fatto che Unix
+funzioni che permettono di modificarle.  Si sarà notato come in realtà queste
+informazioni siano estremamente ridotte.  Questo è dovuto al fatto che Unix
 origina negli anni '70, quando le risorse di calcolo e di spazio disco erano
-minime. Con il venir meno di queste restrizioni è incominciata ad emergere
+minime. Con il venir meno di queste restrizioni è incominciata ad emergere
 l'esigenza di poter associare ai file delle ulteriori informazioni astratte
-(quelli che vengono chiamati i \textsl{meta-dati}) che però non potevano
+(quelli che vengono chiamati i \textsl{meta-dati}) che però non potevano
 trovare spazio nei dati classici mantenuti negli \itindex{inode}
 \textit{inode}.
 
 Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche
 Linux) hanno introdotto un meccanismo generico che consenta di associare delle
-informazioni ai singoli file,\footnote{l'uso più comune è quello della ACL,
+informazioni ai singoli file,\footnote{l'uso più comune è quello della ACL,
   che tratteremo nella prossima sezione, ma si possono inserire anche altre
   informazioni.}  detto \textit{Extended Attributes}. Gli \textsl{attributi
   estesi} non sono altro che delle coppie nome/valore che sono associate
@@ -3699,12 +3699,12 @@ diverso in cui ad un file sono associati diversi flussi di dati, su cui
 possono essere mantenute ulteriori informazioni, che possono essere accedute
 con le normali operazioni di lettura e scrittura. Questi non vanno confusi con
 gli \textit{Extended Attributes} (anche se su Solaris hanno lo stesso nome),
-che sono un meccanismo molto più semplice, che pur essendo limitato (potendo
-contenere solo una quantità limitata di informazione) hanno il grande
-vantaggio di essere molto più semplici da realizzare, più
+che sono un meccanismo molto più semplice, che pur essendo limitato (potendo
+contenere solo una quantità limitata di informazione) hanno il grande
+vantaggio di essere molto più semplici da realizzare, più
 efficienti,\footnote{cosa molto importante, specie per le applicazioni che
   richiedono una gran numero di accessi, come le ACL.} e di garantire
-l'atomicità di tutte le operazioni.
+l'atomicità di tutte le operazioni.
 
 In Linux gli attributi estesi sono sempre associati al singolo \itindex{inode}
 \textit{inode} e l'accesso viene sempre eseguito in forma atomica, in lettura
@@ -3715,14 +3715,14 @@ Si tenga presente che non tutti i filesystem supportano gli \textit{Extended
   Attributes}, in particolare al momento della scrittura di queste dispense
 essi sono presenti solo su \textsl{ext2}, \textsl{ext3} e \textsl{XFS}.
 Inoltre a seconda della implementazione ci possono essere dei limiti sulla
-quantità di attributi che si possono utilizzare.\footnote{ad esempio nel caso
-  di \textsl{ext2} ed \textsl{ext3} è richiesto che essi siano contenuti
+quantità di attributi che si possono utilizzare.\footnote{ad esempio nel caso
+  di \textsl{ext2} ed \textsl{ext3} è richiesto che essi siano contenuti
   all'interno di un singolo blocco (pertanto con dimensioni massime pari a
   1024, 2048 o 4096 byte a seconda delle dimensioni di quest'ultimo impostate
   in fase di creazione del filesystem), mentre con \textsl{XFS} non ci sono
   limiti ed i dati vengono memorizzati in maniera diversa (nell'\textit{inode}
   stesso, in un blocco a parte, o in una struttura ad albero dedicata) per
-  mantenerne la scalabilità.} Infine lo spazio utilizzato per mantenere gli
+  mantenerne la scalabilità.} Infine lo spazio utilizzato per mantenere gli
 attributi estesi viene tenuto in conto per il calcolo delle quote di utente e
 gruppo proprietari del file.
 
@@ -3733,7 +3733,7 @@ fra loro.  Per poterli distinguere allora sono stati suddivisi in
 gestione. Per questo motivo il nome di un attributo deve essere sempre
 specificato nella forma \texttt{namespace.attribute}, dove \texttt{namespace}
 fa riferimento alla classe a cui l'attributo appartiene, mentre
-\texttt{attribute} è il nome ad esso assegnato. In tale forma il nome di un
+\texttt{attribute} è il nome ad esso assegnato. In tale forma il nome di un
 attributo esteso deve essere univoco. Al momento\footnote{della scrittura di
   questa sezione, kernel 2.6.23, ottobre 2007.} sono state definite le quattro
 classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}.
@@ -3776,7 +3776,7 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}.
 \end{table}
 
 
-Dato che uno degli usi degli \textit{Extended Attributes} è quello che li
+Dato che uno degli usi degli \textit{Extended Attributes} è quello che li
 impiega per realizzare delle estensioni (come le \itindex{Access~Control~List}
 ACL, \index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli
 di accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa
@@ -3791,8 +3791,8 @@ casi:
   \itindex{Linux~Security~Modules} \textit{Linux Security Modules} (ad esempio
   \index{SELinux} SELinux). Pertanto l'accesso in lettura o scrittura dipende
   dalle politiche di sicurezza implementate all'interno dal modulo di
-  sicurezza che si sta utilizzando al momento (ciascuno avrà le sue). Se non è
-  stato caricato nessun modulo di sicurezza l'accesso in lettura sarà
+  sicurezza che si sta utilizzando al momento (ciascuno avrà le sue). Se non è
+  stato caricato nessun modulo di sicurezza l'accesso in lettura sarà
   consentito a tutti i processi, mentre quello in scrittura solo ai processi
   con privilegi amministrativi dotati della \index{capabilities}
   \textit{capability} \const{CAP\_SYS\_ADMIN}.
@@ -3800,57 +3800,57 @@ casi:
 \item[\texttt{system}] Anche l'accesso agli \textit{extended system
     attributes} dipende dalle politiche di accesso che il kernel realizza
   anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso
-  delle \itindex{Access~Control~List} ACL l'accesso è consentito in lettura ai
-  processi che hanno la capacità di eseguire una ricerca sul file (cioè hanno
+  delle \itindex{Access~Control~List} ACL l'accesso è consentito in lettura ai
+  processi che hanno la capacità di eseguire una ricerca sul file (cioè hanno
   il permesso di lettura sulla directory che contiene il file) ed in scrittura
   al proprietario del file o ai processi dotati della \textit{capability}
   \index{capabilities} \const{CAP\_FOWNER}.\footnote{vale a dire una politica
     di accesso analoga a quella impiegata per gli ordinari permessi dei file.}
 
 \item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia
-  per la lettura che per la scrittura, è consentito soltanto ai processi con
+  per la lettura che per la scrittura, è consentito soltanto ai processi con
   privilegi amministrativi dotati della \index{capabilities}
   \textit{capability} \const{CAP\_SYS\_ADMIN}. In questo modo si possono
   utilizzare questi attributi per realizzare in user space dei meccanismi di
   controllo che accedono ad informazioni non disponibili ai processi ordinari.
 
-\item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
+\item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
   regolato dai normali permessi dei file: occorre avere il permesso di lettura
   per leggerli e quello di scrittura per scriverli o modificarli. Dato l'uso
-  di questi attributi si è scelto di applicare al loro accesso gli stessi
+  di questi attributi si è scelto di applicare al loro accesso gli stessi
   criteri che si usano per l'accesso al contenuto dei file (o delle directory)
-  cui essi fanno riferimento. Questa scelta vale però soltanto per i file e le
+  cui essi fanno riferimento. Questa scelta vale però soltanto per i file e le
   directory ordinarie, se valesse in generale infatti si avrebbe un serio
   problema di sicurezza dato che esistono diversi oggetti sul filesystem per i
-  quali è normale avere avere il permesso di scrittura consentito a tutti gli
+  quali è normale avere avere il permesso di scrittura consentito a tutti gli
   utenti, come i link simbolici, o alcuni \index{file!di~dispositivo} file di
   dispositivo come \texttt{/dev/null}. Se fosse possibile usare su di essi gli
   \textit{extended user attributes} un utente qualunque potrebbe inserirvi
-  dati a piacere.\footnote{la cosa è stata notata su XFS, dove questo
+  dati a piacere.\footnote{la cosa è stata notata su XFS, dove questo
     comportamento permetteva, non essendovi limiti sullo spazio occupabile
     dagli \textit{Extended Attributes}, di bloccare il sistema riempiendo il
     disco.}
 
   La semantica del controllo di accesso indicata inoltre non avrebbe alcun
   senso al di fuori di file e directory: i permessi di lettura e scrittura per
-  un \index{file!di~dispositivo} file di dispositivo attengono alle capacità
-  di accesso al dispositivo sottostante,\footnote{motivo per cui si può
-    formattare un disco anche se \texttt{/dev} è su un filesystem in sola
+  un \index{file!di~dispositivo} file di dispositivo attengono alle capacità
+  di accesso al dispositivo sottostante,\footnote{motivo per cui si può
+    formattare un disco anche se \texttt{/dev} è su un filesystem in sola
     lettura.} mentre per i link simbolici questi vengono semplicemente
   ignorati: in nessuno dei due casi hanno a che fare con il contenuto del
   file, e nella discussione relativa all'uso degli \textit{extended user
-    attributes} nessuno è mai stato capace di indicare una qualche forma
+    attributes} nessuno è mai stato capace di indicare una qualche forma
   sensata di utilizzo degli stessi per link simbolici o
   \index{file!di~dispositivo} file di dispositivo, e neanche per le fifo o i
   socket.  Per questo motivo essi sono stati completamente disabilitati per
-  tutto ciò che non sia un file regolare o una directory.\footnote{si può
+  tutto ciò che non sia un file regolare o una directory.\footnote{si può
     verificare la semantica adottata consultando il file \texttt{fs/xattr.c}
-    dei sorgenti del kernel.} Inoltre per le directory è stata introdotta una
+    dei sorgenti del kernel.} Inoltre per le directory è stata introdotta una
   ulteriore restrizione, dovuta di nuovo alla presenza ordinaria di permessi
   di scrittura completi su directory come \texttt{/tmp}. Per questo motivo,
   per evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit}
-  \textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended
-    user attributes} soltanto se si è proprietari della stessa, o si hanno i
+  \textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended
+    user attributes} soltanto se si è proprietari della stessa, o si hanno i
   privilegi amministrativi della capability \index{capabilities}
   \const{CAP\_FOWNER}.
 \end{basedescript}
@@ -3858,8 +3858,8 @@ casi:
 Le funzioni per la gestione degli attributi estesi, come altre funzioni di
 gestione avanzate specifiche di Linux, non fanno parte delle \acr{glibc}, e
 sono fornite da una apposita libreria, \texttt{libattr}, che deve essere
-installata a parte;\footnote{la versione corrente della libreria è
-  \texttt{libattr1}.}  pertanto se un programma le utilizza si dovrà indicare
+installata a parte;\footnote{la versione corrente della libreria è
+  \texttt{libattr1}.}  pertanto se un programma le utilizza si dovrà indicare
 esplicitamente l'uso della suddetta libreria invocando il compilatore con
 l'opzione \texttt{-lattr}.  
 
@@ -3884,11 +3884,11 @@ simbolico e ad un file descriptor; i rispettivi prototipi sono:
   
   \bodydesc{Le funzioni restituiscono un intero positivo che indica la
     dimensione dell'attributo richiesto in caso di successo, e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
   \item[\errcode{ENOATTR}] l'attributo richiesto non esiste.
   \item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
-    non è sufficiente per contenere il risultato.
+    non è sufficiente per contenere il risultato.
   \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
     filesystem o sono disabilitati.
   \end{errlist}
@@ -3898,7 +3898,7 @@ simbolico e ad un file descriptor; i rispettivi prototipi sono:
 
 Le funzioni \func{getxattr} e \func{lgetxattr} prendono come primo argomento
 un pathname che indica il file di cui si vuole richiedere un attributo, la
-sola differenza è che la seconda, se il pathname indica un link simbolico,
+sola differenza è che la seconda, se il pathname indica un link simbolico,
 restituisce gli attributi di quest'ultimo e non quelli del file a cui esso fa
 riferimento. La funzione \func{fgetxattr} prende invece come primo argomento
 un numero di file descriptor, e richiede gli attributi del file ad esso
@@ -3909,22 +3909,22 @@ il nome dell'attributo di cui si vuole ottenere il valore. Il nome deve essere
 indicato comprensivo di prefisso del \textit{namespace} cui appartiene (uno
 dei valori di tab.~\ref{tab:extended_attribute_class}) nella forma
 \texttt{namespace.attributename}, come stringa terminata da un carattere NUL.
-Il suo valore verrà restituito nel buffer puntato dall'argomento \param{value}
+Il suo valore verrà restituito nel buffer puntato dall'argomento \param{value}
 per una dimensione massima di \param{size} byte;\footnote{gli attributi estesi
   possono essere costituiti arbitrariamente da dati testuali o binari.}  se
-quest'ultima non è sufficiente si avrà un errore di \errcode{ERANGE}.
+quest'ultima non è sufficiente si avrà un errore di \errcode{ERANGE}.
 
 Per evitare di dover indovinare la dimensione di un attributo per tentativi si
-può eseguire una interrogazione utilizzando un valore nullo per \param{size};
-in questo caso non verrà letto nessun dato, ma verrà restituito come valore di
+può eseguire una interrogazione utilizzando un valore nullo per \param{size};
+in questo caso non verrà letto nessun dato, ma verrà restituito come valore di
 ritorno della funzione chiamata la dimensione totale dell'attributo esteso
-richiesto, che si potrà usare come stima per allocare un buffer di dimensioni
-sufficienti.\footnote{si parla di stima perché anche se le funzioni
+richiesto, che si potrà usare come stima per allocare un buffer di dimensioni
+sufficienti.\footnote{si parla di stima perché anche se le funzioni
   restituiscono la dimensione esatta dell'attributo al momento in cui sono
   eseguite, questa potrebbe essere modificata in qualunque momento da un
   successivo accesso eseguito da un altro processo.}
 
-Un secondo gruppo di funzioni è quello che consente di impostare il valore di
+Un secondo gruppo di funzioni è quello che consente di impostare il valore di
 un attributo esteso, queste sono \funcd{setxattr}, \funcd{lsetxattr} e
 \funcd{fsetxattr}, e consentono di operare rispettivamente su un file, su un
 link simbolico o specificando un file descriptor; i loro prototipi sono:
@@ -3944,12 +3944,12 @@ link simbolico o specificando un file descriptor; i loro prototipi sono:
   Impostano il valore di un attributo esteso.
   
   \bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
-  \item[\errcode{ENOATTR}] si è usato il flag \const{XATTR\_REPLACE} e
+  \item[\errcode{ENOATTR}] si è usato il flag \const{XATTR\_REPLACE} e
     l'attributo richiesto non esiste.
-  \item[\errcode{EEXIST}] si è usato il flag \const{XATTR\_CREATE} ma
-    l'attributo esiste già.
+  \item[\errcode{EEXIST}] si è usato il flag \const{XATTR\_CREATE} ma
+    l'attributo esiste già.
   \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
     filesystem o sono disabilitati.
   \end{errlist}
@@ -3966,16 +3966,16 @@ deve indicare, anche in questo caso con gli stessi criteri appena visti per le
 analoghe \func{getxattr}, \func{lgetxattr} e \func{fgetxattr}, il nome
 (completo di suffisso) dell'attributo su cui si vuole operare. 
 
-Il valore che verrà assegnato all'attributo dovrà essere preparato nel buffer
-puntato da \param{value}, e la sua dimensione totale (in byte) sarà indicata
+Il valore che verrà assegnato all'attributo dovrà essere preparato nel buffer
+puntato da \param{value}, e la sua dimensione totale (in byte) sarà indicata
 dall'argomento \param{size}. Infine l'argomento \param{flag} consente di
-controllare le modalità di sovrascrittura dell'attributo esteso, esso può
+controllare le modalità di sovrascrittura dell'attributo esteso, esso può
 prendere due valori: con \const{XATTR\_REPLACE} si richiede che l'attributo
-esista, nel qual caso verrà sovrascritto, altrimenti si avrà errore, mentre
+esista, nel qual caso verrà sovrascritto, altrimenti si avrà errore, mentre
 con \const{XATTR\_CREATE} si richiede che l'attributo non esista, nel qual
-caso verrà creato, altrimenti si avrà errore ed il valore attuale non sarà
-modificato.  Utilizzando per \param{flag} un valore nullo l'attributo verrà
-modificato se è già presente, o creato se non c'è.
+caso verrà creato, altrimenti si avrà errore ed il valore attuale non sarà
+modificato.  Utilizzando per \param{flag} un valore nullo l'attributo verrà
+modificato se è già presente, o creato se non c'è.
 
 Le funzioni finora illustrate permettono di leggere o scrivere gli attributi
 estesi, ma sarebbe altrettanto utile poter vedere quali sono gli attributi
@@ -3995,10 +3995,10 @@ presenti; a questo provvedono le funzioni \funcd{listxattr},
   
   \bodydesc{Le funzioni restituiscono un intero positivo che indica la
     dimensione della lista in caso di successo, e $-1$ in caso di errore, nel
-    qual caso \var{errno} assumerà i valori:
+    qual caso \var{errno} assumerà i valori:
   \begin{errlist}
   \item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
-    non è sufficiente per contenere il risultato.
+    non è sufficiente per contenere il risultato.
   \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
     filesystem o sono disabilitati.
   \end{errlist}
@@ -4016,12 +4016,12 @@ deve essere letta la lista e la dimensione \param{size} di quest'ultimo.
 
 La lista viene fornita come sequenza non ordinata dei nomi dei singoli
 attributi estesi (sempre comprensivi del prefisso della loro classe) ciascuno
-dei quali è terminato da un carattere nullo. I nomi sono inseriti nel buffer
+dei quali è terminato da un carattere nullo. I nomi sono inseriti nel buffer
 uno di seguito all'altro. Il valore di ritorno della funzione indica la
 dimensione totale della lista in byte.
 
 Come per le funzioni di lettura dei singoli attributi se le dimensioni del
-buffer non sono sufficienti si avrà un errore, ma è possibile ottenere dal
+buffer non sono sufficienti si avrà un errore, ma è possibile ottenere dal
 valore di ritorno della funzione una stima della dimensione totale della lista
 usando per \param{size} un valore nullo. 
 
@@ -4042,7 +4042,7 @@ un ultimo gruppo di funzioni: \funcd{removexattr}, \funcd{lremovexattr} e
   Rimuovono un attributo esteso di un file.
   
   \bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
   \item[\errcode{ENOATTR}] l'attributo richiesto non esiste.
   \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
@@ -4055,7 +4055,7 @@ un ultimo gruppo di funzioni: \funcd{removexattr}, \funcd{lremovexattr} e
 Le tre funzioni rimuovono l'attributo esteso indicato dall'argomento
 \param{name} rispettivamente di un file, un link simbolico o specificando un
 file descriptor, da specificare con il loro primo argomento.  Anche in questo
-caso l'argomento \param{name} deve essere specificato con le modalità già
+caso l'argomento \param{name} deve essere specificato con le modalità già
 illustrate in precedenza per le altre funzioni relative agli attributi estesi.
 
 \itindend{Extended~Attributes}
@@ -4064,36 +4064,36 @@ illustrate in precedenza per le altre funzioni relative agli attributi estesi.
 \subsection{Le \textit{Access  Control List}}
 \label{sec:file_ACL}
 
-% la documentazione di sistema è nei pacchetti libacl1-dev e acl 
+% la documentazione di sistema è nei pacchetti libacl1-dev e acl 
 % vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/
 
 \itindbeg{Access~Control~List}
 
 Il modello classico dei permessi di Unix, per quanto funzionale ed efficiente,
-è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni
-le esigenze più comuni con un meccanismo semplice e potente, non è in grado di
+è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni
+le esigenze più comuni con un meccanismo semplice e potente, non è in grado di
 rispondere in maniera adeguata a situazioni che richiedono una gestione
-complessa dei permessi di accesso.\footnote{già un requisito come quello di
+complessa dei permessi di accesso.\footnote{già un requisito come quello di
   dare accesso in scrittura ad alcune persone ed in sola lettura ad altre non
-  si può soddisfare in maniera semplice.}
+  si può soddisfare in maniera semplice.}
 
 Per questo motivo erano state progressivamente introdotte nelle varie versioni
-di Unix dei meccanismi di gestione dei permessi dei file più flessibili, nella
+di Unix dei meccanismi di gestione dei permessi dei file più flessibili, nella
 forma delle cosiddette \textit{Access Control List} (indicate usualmente con
-la sigla ACL).  Nello sforzo di standardizzare queste funzionalità era stato
+la sigla ACL).  Nello sforzo di standardizzare queste funzionalità era stato
 creato un gruppo di lavoro il cui scopo era estendere lo standard POSIX 1003
 attraverso due nuovi insiemi di specifiche, la POSIX 1003.1e per l'interfaccia
 di programmazione e la POSIX 1003.2c per i comandi di shell.
 
-Gli obiettivi erano però forse troppo ambizioni, e nel gennaio del 1998 i
+Gli obiettivi erano però forse troppo ambizioni, e nel gennaio del 1998 i
 finanziamenti vennero ritirati senza che si fosse arrivati alla definizione di
-uno standard, dato però che una parte della documentazione prodotta era di
-alta qualità venne deciso di rilasciare al pubblico la diciassettesima bozza
+uno standard, dato però che una parte della documentazione prodotta era di
+alta qualità venne deciso di rilasciare al pubblico la diciassettesima bozza
 del documento, quella che va sotto il nome di \textit{POSIX 1003.1e Draft 17},
-che è divenuta la base sulla quale si definiscono le cosiddette \textit{Posix
+che è divenuta la base sulla quale si definiscono le cosiddette \textit{Posix
   ACL}.
 
-A differenza di altri sistemi (ad esempio FreeBSD) nel caso di Linux si è
+A differenza di altri sistemi (ad esempio FreeBSD) nel caso di Linux si è
 scelto di realizzare le ACL attraverso l'uso degli
 \itindex{Extended~Attributes} \textit{Extended Attributes} (appena trattati in
 sez.~\ref{sec:file_xattr}), e fornire tutte le relative funzioni di gestione
@@ -4103,26 +4103,26 @@ standard POSIX 1003.1e.
 
 Anche in questo caso le funzioni di questa libreria non fanno parte delle
 \acr{glibc} e devono essere installate a parte;\footnote{la versione corrente
-  della libreria è \texttt{libacl1}, e nel caso si usi Debian la si può
+  della libreria è \texttt{libacl1}, e nel caso si usi Debian la si può
   installare con il pacchetto omonimo e con il collegato \texttt{libacl1-dev}
-  per i file di sviluppo.}  pertanto se un programma le utilizza si dovrà
+  per i file di sviluppo.}  pertanto se un programma le utilizza si dovrà
 indicare esplicitamente l'uso della libreria \texttt{libacl} invocando il
 compilatore con l'opzione \texttt{-lacl}. Si tenga presente inoltre che per
 poterle utilizzare le ACL devono essere attivate esplicitamente montando il
-filesystem\footnote{che deve supportarle, ma questo è ormai vero per
-  praticamente tutti i filesystem più comuni, con l'eccezione di NFS per il
-  quale esiste però un supporto sperimentale.} su cui le si vogliono
+filesystem\footnote{che deve supportarle, ma questo è ormai vero per
+  praticamente tutti i filesystem più comuni, con l'eccezione di NFS per il
+  quale esiste però un supporto sperimentale.} su cui le si vogliono
 utilizzare con l'opzione \texttt{acl} attiva. Dato che si tratta di una
-estensione è infatti opportuno utilizzarle soltanto laddove siano necessarie.
+estensione è infatti opportuno utilizzarle soltanto laddove siano necessarie.
 
-Una ACL è composta da un insieme di voci, e ciascuna voce è a sua volta
+Una ACL è composta da un insieme di voci, e ciascuna voce è a sua volta
 costituita da un \textsl{tipo}, da un eventuale
 \textsl{qualificatore},\footnote{deve essere presente soltanto per le voci di
   tipo \const{ACL\_USER} e \const{ACL\_GROUP}.} e da un insieme di permessi.
-Ad ogni oggetto sul filesystem si può associare una ACL che ne governa i
+Ad ogni oggetto sul filesystem si può associare una ACL che ne governa i
 permessi di accesso, detta \textit{access ACL}.  Inoltre per le directory si
-può impostare una ACL aggiuntiva, detta \textit{default ACL}, che serve ad
-indicare quale dovrà essere la ACL assegnata di default nella creazione di un
+può impostare una ACL aggiuntiva, detta \textit{default ACL}, che serve ad
+indicare quale dovrà essere la ACL assegnata di default nella creazione di un
 file all'interno della directory stessa. Come avviene per i permessi le ACL
 possono essere impostate solo del proprietario del file, o da un processo con
 la capability \index{capabilities} \const{CAP\_FOWNER}.
@@ -4158,30 +4158,30 @@ la capability \index{capabilities} \const{CAP\_FOWNER}.
 \end{table}
 
 L'elenco dei vari tipi di voci presenti in una ACL, con una breve descrizione
-del relativo significato, è riportato in tab.~\ref{tab:acl_tag_types}. Tre di
+del relativo significato, è riportato in tab.~\ref{tab:acl_tag_types}. Tre di
 questi tipi, \const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e
 \const{ACL\_OTHER}, corrispondono direttamente ai tre permessi ordinari dei
 file (proprietario, gruppo proprietario e tutti gli altri) e per questo una
 ACL valida deve sempre contenere una ed una sola voce per ciascuno di questi
 tipi.
 
-Una ACL può poi contenere un numero arbitrario di voci di tipo
-\const{ACL\_USER} e \const{ACL\_GROUP}, ciascuna delle quali indicherà i
+Una ACL può poi contenere un numero arbitrario di voci di tipo
+\const{ACL\_USER} e \const{ACL\_GROUP}, ciascuna delle quali indicherà i
 permessi assegnati all'utente e al gruppo indicato dal relativo qualificatore;
-ovviamente ciascuna di queste voci dovrà fare riferimento ad un utente o ad un
+ovviamente ciascuna di queste voci dovrà fare riferimento ad un utente o ad un
 gruppo diverso, e non corrispondenti a quelli proprietari del file. Inoltre se
-in una ACL esiste una voce di uno di questi due tipi è obbligatoria anche la
+in una ACL esiste una voce di uno di questi due tipi è obbligatoria anche la
 presenza di una ed una sola voce di tipo \const{ACL\_MASK}, che negli altri
-casi è opzionale.
+casi è opzionale.
 
 Quest'ultimo tipo di voce contiene la maschera dei permessi che possono essere
 assegnati tramite voci di tipo \const{ACL\_USER}, \const{ACL\_GROUP} e
 \const{ACL\_GROUP\_OBJ}; se in una di queste voci si fosse specificato un
 permesso non presente in \const{ACL\_MASK} questo verrebbe ignorato. L'uso di
-una ACL di tipo \const{ACL\_MASK} è di particolare utilità quando essa
+una ACL di tipo \const{ACL\_MASK} è di particolare utilità quando essa
 associata ad una \textit{default ACL} su una directory, in quanto i permessi
-così specificati verranno ereditati da tutti i file creati nella stessa
-directory. Si ottiene così una sorta di \itindex{umask} \textit{umask}
+così specificati verranno ereditati da tutti i file creati nella stessa
+directory. Si ottiene così una sorta di \itindex{umask} \textit{umask}
 associata ad un oggetto sul filesystem piuttosto che a un processo.
 
 Dato che le ACL vengono a costituire una estensione dei permessi ordinari, uno
@@ -4192,84 +4192,84 @@ ordinari vengono mappati le tre voci di tipo \const{ACL\_USER\_OBJ},
 qualunque ACL; un cambiamento ad una di queste voci viene automaticamente
 riflesso sui permessi ordinari dei file\footnote{per permessi ordinari si
   intende quelli mantenuti nell'\textit{inode}, che devono restare dato che un
-  filesystem può essere montato senza abilitare le ACL.} e viceversa. In
-realtà la mappatura è diretta solo per le voci \const{ACL\_USER\_OBJ} e
+  filesystem può essere montato senza abilitare le ACL.} e viceversa. In
+realtà la mappatura è diretta solo per le voci \const{ACL\_USER\_OBJ} e
 \const{ACL\_OTHER}, nel caso di \const{ACL\_GROUP\_OBJ} questo vale soltanto
-se non è presente una voce di tipo \const{ACL\_MASK}, se invece questa è
+se non è presente una voce di tipo \const{ACL\_MASK}, se invece questa è
 presente verranno tolti dai permessi di \const{ACL\_GROUP\_OBJ} tutti quelli
 non presenti in \const{ACL\_MASK}.\footnote{questo diverso comportamento a
-  seconda delle condizioni è stato introdotto dalla standardizzazione
+  seconda delle condizioni è stato introdotto dalla standardizzazione
   \textit{POSIX 1003.1e Draft 17} per mantenere il comportamento invariato sui
   sistemi dotati di ACL per tutte quelle applicazioni che sono conformi
   soltanto all'ordinario standard \textit{POSIX 1003.1}.}
 
-Un secondo aspetto dell'incidenza delle ACL sul comportamento del sistema è
+Un secondo aspetto dell'incidenza delle ACL sul comportamento del sistema è
 quello relativo alla creazione di nuovi file,\footnote{o oggetti sul
   filesystem, il comportamento discusso vale per le funzioni \func{open} e
   \func{creat} (vedi sez.~\ref{sec:file_open}), \func{mkdir} (vedi
   sez.~\ref{sec:file_dir_creat_rem}), \func{mknod} e \func{mkfifo} (vedi
-  sez.~\ref{sec:file_mknod}).} che come accennato può essere modificato dalla
+  sez.~\ref{sec:file_mknod}).} che come accennato può essere modificato dalla
 presenza di una \textit{default ACL} sulla directory che contiene quel file.
-Se questa non c'è valgono le regole usuali illustrate in
+Se questa non c'è valgono le regole usuali illustrate in
 sez.~\ref{sec:file_perm_management}, per cui essi sono determinati dalla
-\itindex{umask} \textit{umask} del processo, e la sola differenza è che i
+\itindex{umask} \textit{umask} del processo, e la sola differenza è che i
 permessi ordinari da esse risultanti vengono automaticamente rimappati anche
 su una ACL di accesso assegnata automaticamente al nuovo file, che contiene
 soltanto le tre corrispondenti voci di tipo \const{ACL\_USER\_OBJ},
 \const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER}.
 
-Se invece è presente una ACL di default sulla directory che contiene il nuovo
-file questa diventerà automaticamente la sua ACL di accesso, a meno di non
+Se invece è presente una ACL di default sulla directory che contiene il nuovo
+file questa diventerà automaticamente la sua ACL di accesso, a meno di non
 aver indicato, nelle funzioni di creazione che lo consentono, uno specifico
 valore per i permessi ordinari;\footnote{tutte le funzioni citate in
   precedenza supportano un argomento \var{mode} che indichi un insieme di
   permessi iniziale.} in tal caso saranno eliminati dalle voci corrispondenti
 nella ACL tutti quelli non presenti in tale indicazione.
 
-Dato che questa è la ragione che ha portato alla loro creazione, la principale
-modifica introdotta con la presenza della ACL è quella alle regole del
+Dato che questa è la ragione che ha portato alla loro creazione, la principale
+modifica introdotta con la presenza della ACL è quella alle regole del
 controllo di accesso ai file illustrate in sez.~\ref{sec:file_perm_overview}.
 Come nel caso ordinario per il controllo vengono sempre utilizzati gli
 identificatori del gruppo \textit{effective} del processo, ma in presenza di
 ACL i passi attraverso i quali viene stabilito se esso ha diritto di accesso
 sono i seguenti:
 \begin{enumerate*}
-\item Se l'user-ID del processo è nullo l'accesso è sempre garantito senza
+\item Se l'user-ID del processo è nullo l'accesso è sempre garantito senza
   nessun controllo.
 \item Se l'user-ID del processo corrisponde al proprietario del file allora:
   \begin{itemize*}
   \item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
-    l'accesso è consentito;
-  \item altrimenti l'accesso è negato.
+    l'accesso è consentito;
+  \item altrimenti l'accesso è negato.
   \end{itemize*}
 \item Se l'user-ID del processo corrisponde ad un qualunque qualificatore
   presente in una voce \const{ACL\_USER} allora:
   \begin{itemize*}
   \item se la voce \const{ACL\_USER} corrispondente e la voce
-    \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
+    \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
     consentito;
-  \item altrimenti l'accesso è negato.
+  \item altrimenti l'accesso è negato.
   \end{itemize*}
-\item Se è il group-ID del processo o uno dei group-ID supplementari
+\item Se è il group-ID del processo o uno dei group-ID supplementari
   corrisponde al gruppo proprietario del file allora: 
   \begin{itemize*}
   \item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce
     \const{ACL\_MASK} (se non vi sono voci di tipo \const{ACL\_GROUP} questa
-    può non essere presente) contengono entrambe il permesso richiesto,
-    l'accesso è consentito;
-  \item altrimenti l'accesso è negato.
+    può non essere presente) contengono entrambe il permesso richiesto,
+    l'accesso è consentito;
+  \item altrimenti l'accesso è negato.
   \end{itemize*}
-\item Se è il group-ID del processo o uno dei group-ID supplementari
+\item Se è il group-ID del processo o uno dei group-ID supplementari
   corrisponde ad un qualunque qualificatore presente in una voce
   \const{ACL\_GROUP} allora:
   \begin{itemize*}
   \item se la voce \const{ACL\_GROUP} corrispondente e la voce
-    \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
+    \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
     consentito;
-  \item altrimenti l'accesso è negato.
+  \item altrimenti l'accesso è negato.
   \end{itemize*}
 \item Se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
-  l'accesso è consentito, altrimenti l'accesso è negato.
+  l'accesso è consentito, altrimenti l'accesso è negato.
 \end{enumerate*}
 
 I passi di controllo vengono eseguiti esattamente in questa sequenza, e la
@@ -4285,8 +4285,8 @@ dedicati;\footnote{fino a definire un tipo di dato e delle costanti apposite
   per identificare i permessi standard di lettura, scrittura ed esecuzione.}
 tutte le operazioni devono essere effettuate attraverso tramite questi tipi di
 dati, che incapsulano tutte le informazioni contenute nelle ACL. La prima di
-queste funzioni che prendiamo in esame è \funcd{acl\_init}, il cui prototipo
-è:
+queste funzioni che prendiamo in esame è \funcd{acl\_init}, il cui prototipo
+è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
@@ -4297,28 +4297,28 @@ queste funzioni che prendiamo in esame 
   
   \bodydesc{La funzione restituisce un puntatore all'area di lavoro in caso di
     successo e \const{NULL} in caso di errore, nel qual caso \var{errno}
-    assumerà uno dei valori:
+    assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] il valore di \param{count} è negativo.
-  \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile.
+  \item[\errcode{EINVAL}] il valore di \param{count} è negativo.
+  \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile.
   \end{errlist}
 }
 \end{functions}
 
-La funzione alloca ed inizializza un'area di memoria che verrà usata per
+La funzione alloca ed inizializza un'area di memoria che verrà usata per
 mantenere i dati di una ACL contenente fino ad un massimo di \param{count}
 voci. La funzione ritorna un valore di tipo \type{acl\_t}, da usare in tutte
 le altre funzioni che operano sulla ACL. La funzione si limita alla
 allocazione iniziale e non inserisce nessun valore nella ACL che resta vuota.
 Si tenga presente che pur essendo \type{acl\_t} un tipo opaco che identifica
-``\textsl{l'oggetto}'' ACL, il valore restituito dalla funzione non è altro
+``\textsl{l'oggetto}'' ACL, il valore restituito dalla funzione non è altro
 che un puntatore all'area di memoria allocata per i dati richiesti; pertanto
-in caso di fallimento verrà restituito un puntatore nullo e si dovrà
+in caso di fallimento verrà restituito un puntatore nullo e si dovrà
 confrontare il valore di ritorno della funzione con ``\code{(acl\_t) NULL}''.
 
 Una volta che si siano completate le operazioni sui dati di una ACL la memoria
-allocata dovrà essere liberata esplicitamente attraverso una chiamata alla
-funzione \funcd{acl\_free}, il cui prototipo è:
+allocata dovrà essere liberata esplicitamente attraverso una chiamata alla
+funzione \funcd{acl\_free}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
@@ -4328,26 +4328,26 @@ funzione \funcd{acl\_free}, il cui prototipo 
   Disalloca la memoria riservata per i dati di una ACL.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ se
-    \param{obj\_p} non è un puntatore valido, nel qual caso \var{errno}
-    assumerà il valore \errcode{EINVAL} 
+    \param{obj\_p} non è un puntatore valido, nel qual caso \var{errno}
+    assumerà il valore \errcode{EINVAL} 
 }
 \end{functions}
 
 Si noti come la funzione richieda come argomento un puntatore di tipo
-``\ctyp{void *}'', essa infatti può essere usata non solo per liberare la
+``\ctyp{void *}'', essa infatti può essere usata non solo per liberare la
 memoria allocata per i dati di una ACL, ma anche per quella usata per creare
 le stringhe di descrizione testuale delle ACL o per ottenere i valori dei
-qualificatori di una voce; pertanto a seconda dei casi occorrerà eseguire un
+qualificatori di una voce; pertanto a seconda dei casi occorrerà eseguire un
 \textit{cast} a ``\ctyp{void *}'' del tipo di dato di cui si vuole eseguire la
 disallocazione.  Si tenga presente poi che oltre a \func{acl\_init} esistono
-molte altre funzioni che possono allocare memoria per i dati delle ACL, è
-pertanto opportuno tenere traccia di tutte queste funzioni perché alla fine
-delle operazioni tutta la memoria allocata dovrà essere liberata con
+molte altre funzioni che possono allocare memoria per i dati delle ACL, è
+pertanto opportuno tenere traccia di tutte queste funzioni perché alla fine
+delle operazioni tutta la memoria allocata dovrà essere liberata con
 \func{acl\_free}.
 
 Una volta che si abbiano a disposizione i dati di una ACL tramite il
 riferimento ad oggetto di tipo \type{acl\_t} questi potranno essere copiati
-con la funzione \funcd{acl\_dup}, il cui prototipo è:
+con la funzione \funcd{acl\_dup}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
@@ -4358,11 +4358,11 @@ con la funzione \funcd{acl\_dup}, il cui prototipo 
   
   \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
     di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
-    \var{errno} assumerà uno dei valori:
+    \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] l'argomento \param{acl} non è un puntatore valido
+  \item[\errcode{EINVAL}] l'argomento \param{acl} non è un puntatore valido
     per una ACL.
-  \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile per eseguire
+  \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile per eseguire
     la copia.
   \end{errlist}
 }
@@ -4372,14 +4372,14 @@ La funzione crea una copia dei dati della ACL indicata tramite l'argomento
 \param{acl}, allocando autonomamente tutto spazio necessario alla copia e
 restituendo un secondo oggetto di tipo \type{acl\_t} come riferimento a
 quest'ultima.  Valgono per questo le stesse considerazioni fatte per il valore
-di ritorno di \func{acl\_init}, ed in particolare il fatto che occorrerà
+di ritorno di \func{acl\_init}, ed in particolare il fatto che occorrerà
 prevedere una ulteriore chiamata esplicita a \func{acl\_free} per liberare la
 memoria occupata dalla copia.
 
-Se si deve creare una ACL manualmente l'uso di \func{acl\_init} è scomodo,
-dato che la funzione restituisce una ACL vuota, una alternativa allora è usare
+Se si deve creare una ACL manualmente l'uso di \func{acl\_init} è scomodo,
+dato che la funzione restituisce una ACL vuota, una alternativa allora è usare
 \funcd{acl\_from\_mode} che consente di creare una ACL a partire da un valore
-di permessi ordinari, il prototipo della funzione è:
+di permessi ordinari, il prototipo della funzione è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
@@ -4390,20 +4390,20 @@ di permessi ordinari, il prototipo della funzione 
   
   \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
     di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
-    \var{errno} assumerà il valore \errval{ENOMEM}.
+    \var{errno} assumerà il valore \errval{ENOMEM}.
 
 }
 \end{functions}
 
 La funzione restituisce una ACL inizializzata con le tre voci obbligatorie
-\const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} già
+\const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} già
 impostate secondo la corrispondenza ai valori dei permessi ordinari indicati
-dalla maschera passata nell'argomento \param{mode}. Questa funzione è una
-estensione usata dalle ACL di Linux e non è portabile, ma consente di
+dalla maschera passata nell'argomento \param{mode}. Questa funzione è una
+estensione usata dalle ACL di Linux e non è portabile, ma consente di
 semplificare l'inizializzazione in maniera molto comoda. 
 
-Altre due funzioni che consentono di creare una ACL già inizializzata sono
-\funcd{acl\_get\_fd} e \funcd{acl\_get\_file}, che però sono per lo più
+Altre due funzioni che consentono di creare una ACL già inizializzata sono
+\funcd{acl\_get\_fd} e \funcd{acl\_get\_file}, che però sono per lo più
 utilizzate per leggere la ACL corrente di un file; i rispettivi prototipi
 sono:
 \begin{functions}
@@ -4417,9 +4417,9 @@ sono:
   
   \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
     di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
-    \var{errno} assumerà uno dei valori:
+    \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
   \item[\errcode{ENOTSUP}] il filesystem cui fa riferimento il file non
     supporta le ACL.
   \end{errlist}
@@ -4431,12 +4431,12 @@ sono:
 \end{functions}
 
 Le due funzioni ritornano, con un oggetto di tipo \type{acl\_t}, il valore
-della ACL correntemente associata ad un file, che può essere identificato
+della ACL correntemente associata ad un file, che può essere identificato
 tramite un file descriptor usando \func{acl\_get\_fd} o con un pathname usando
-\func{acl\_get\_file}. Nel caso di quest'ultima funzione, che può richiedere
+\func{acl\_get\_file}. Nel caso di quest'ultima funzione, che può richiedere
 anche la ACL relativa ad una directory, il secondo argomento \param{type}
 consente di specificare se si vuole ottenere la ACL di default o quella di
-accesso. Questo argomento deve essere di tipo \type{acl\_type\_t} e può
+accesso. Questo argomento deve essere di tipo \type{acl\_type\_t} e può
 assumere solo i due valori riportati in tab.~\ref{tab:acl_type}.
 
 \begin{table}[htb]
@@ -4455,15 +4455,15 @@ assumere solo i due valori riportati in tab.~\ref{tab:acl_type}.
   \label{tab:acl_type}
 \end{table}
 
-Si tenga presente che nel caso di \func{acl\_get\_file} occorrerà che il
+Si tenga presente che nel caso di \func{acl\_get\_file} occorrerà che il
 processo chiamante abbia privilegi di accesso sufficienti a poter leggere gli
 attributi estesi dei file (come illustrati in sez.~\ref{sec:file_xattr});
-inoltre una ACL di tipo \const{ACL\_TYPE\_DEFAULT} potrà essere richiesta
-soltanto per una directory, e verrà restituita solo se presente, altrimenti
-verrà restituita una ACL vuota.
+inoltre una ACL di tipo \const{ACL\_TYPE\_DEFAULT} potrà essere richiesta
+soltanto per una directory, e verrà restituita solo se presente, altrimenti
+verrà restituita una ACL vuota.
 
-Infine si potrà creare una ACL direttamente dalla sua rappresentazione
-testuale con la funzione  \funcd{acl\_from\_text}, il cui prototipo è:
+Infine si potrà creare una ACL direttamente dalla sua rappresentazione
+testuale con la funzione  \funcd{acl\_from\_text}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
@@ -4474,24 +4474,24 @@ testuale con la funzione  \funcd{acl\_from\_text}, il cui prototipo 
   
   \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
     di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
-    \var{errno} assumerà uno dei valori:
+    \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
   \item[\errcode{EINVAL}] la rappresentazione testuale all'indirizzo
-    \param{buf\_p} non è valida.
+    \param{buf\_p} non è valida.
   \end{errlist}
 
 }
 \end{functions}
 
-La funzione prende come argomento il puntatore ad un buffer dove si è inserita
+La funzione prende come argomento il puntatore ad un buffer dove si è inserita
 la rappresentazione testuale della ACL che si vuole creare, la memoria
 necessaria viene automaticamente allocata ed in caso di successo viene
 restituito come valore di ritorno un oggetto di tipo \type{acl\_t} con il
-contenuto della stessa, che come per le precedenti funzioni, dovrà essere
+contenuto della stessa, che come per le precedenti funzioni, dovrà essere
 disallocato esplicitamente al termine del suo utilizzo.
 
-La rappresentazione testuale di una ACL è quella usata anche dai comandi
+La rappresentazione testuale di una ACL è quella usata anche dai comandi
 ordinari per la gestione delle ACL (\texttt{getfacl} e \texttt{setfacl}), che
 prevede due diverse forme, estesa e breve, entrambe supportate da
 \func{acl\_from\_text}. La forma estesa prevede che sia specificata una voce
@@ -4499,8 +4499,8 @@ per riga, nella forma:
 \begin{Verbatim}
   tipo:qualificatore:permessi
 \end{Verbatim}
-dove il tipo può essere uno fra \texttt{user}, \texttt{group}, \texttt{other}
-e \texttt{mask}. Il qualificatore è presente solo per \texttt{user} e
+dove il tipo può essere uno fra \texttt{user}, \texttt{group}, \texttt{other}
+e \texttt{mask}. Il qualificatore è presente solo per \texttt{user} e
 \texttt{group} e indica l'utente o il gruppo a cui la voce si riferisce; i
 permessi sono espressi con una tripletta di lettere analoga a quella usata per
 i permessi dei file.\footnote{vale a dire \texttt{r} per il permesso di
@@ -4510,24 +4510,24 @@ i permessi dei file.\footnote{vale a dire \texttt{r} per il permesso di
 
 Va precisato che i due tipi \texttt{user} e \texttt{group} sono usati
 rispettivamente per indicare delle voci relative ad utenti e
-gruppi,\footnote{cioè per voci di tipo \const{ACL\_USER\_OBJ} e
+gruppi,\footnote{cioè per voci di tipo \const{ACL\_USER\_OBJ} e
   \const{ACL\_USER} per \texttt{user} e \const{ACL\_GROUP\_OBJ} e
   \const{ACL\_GROUP} per \texttt{group}.} applicate sia a quelli proprietari
 del file che a quelli generici; quelle dei proprietari si riconoscono per
 l'assenza di un qualificatore, ed in genere si scrivono per prima delle altre.
-Il significato delle voci di tipo \texttt{mask} e \texttt{mark} è evidente. In
+Il significato delle voci di tipo \texttt{mask} e \texttt{mark} è evidente. In
 questa forma si possono anche inserire dei commenti precedendoli con il
 carattere ``\texttt{\#}''.
 
 La forma breve prevede invece la scrittura delle singole voci su una riga,
 separate da virgole; come specificatori del tipo di voce si possono usare le
-iniziali dei valori usati nella forma estesa (cioè ``\texttt{u}'',
+iniziali dei valori usati nella forma estesa (cioè ``\texttt{u}'',
 ``\texttt{g}'', ``\texttt{o}'' e ``\texttt{m}''), mentre le altri parte della
 voce sono le stesse. In questo caso non sono consentiti permessi.
 
 Per la conversione inversa, che consente di ottenere la rappresentazione
 testuale di una ACL, sono invece disponibili due funzioni, la prima delle due,
-di uso più immediato, è \funcd{acl\_to\_text}, il cui prototipo è:
+di uso più immediato, è \funcd{acl\_to\_text}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
@@ -4538,11 +4538,11 @@ di uso pi
   
   \bodydesc{La funzione restituisce il puntatore ad una stringa con la
     rappresentazione testuale della ACL in caso di successo e
-    \code(acl\_t){NULL} in caso di errore, nel qual caso \var{errno} assumerà
+    \code(acl\_t){NULL} in caso di errore, nel qual caso \var{errno} assumerà
     uno dei valori:
   \begin{errlist}
-  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
-  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
+  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
   \end{errlist}
 
 }
@@ -4550,15 +4550,15 @@ di uso pi
 
 La funzione restituisce il puntatore ad una stringa terminata da NUL
 contenente la rappresentazione in forma estesa della ACL passata come
-argomento, ed alloca automaticamente la memoria necessaria. Questa dovrà poi
-essere liberata, quando non più necessaria, con \func{acl\_free}. Se
+argomento, ed alloca automaticamente la memoria necessaria. Questa dovrà poi
+essere liberata, quando non più necessaria, con \func{acl\_free}. Se
 nell'argomento \param{len\_p} si passa un valore puntatore ad una variabile
-intera in questa verrà restituita la dimensione della stringa con la
+intera in questa verrà restituita la dimensione della stringa con la
 rappresentazione testuale (non comprendente il carattere nullo finale). 
 
 La seconda funzione, \funcd{acl\_to\_any\_text}, permette di controllare con
 dovizia di dettagli la generazione della stringa contenente la
-rappresentazione testuale della ACL, il suo prototipo è:
+rappresentazione testuale della ACL, il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
@@ -4570,10 +4570,10 @@ rappresentazione testuale della ACL, il suo prototipo 
 
   \bodydesc{La funzione restituisce il puntatore ad una stringa con la
     rappresentazione testuale della ACL in caso di successo e \code{NULL} in
-    caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+    caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
-  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
+  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
   \end{errlist}
 
 }
@@ -4581,14 +4581,14 @@ rappresentazione testuale della ACL, il suo prototipo 
 
 La funzione converte in formato testo la ACL indicata dall'argomento
 \param{acl}, usando il carattere \param{separator} come separatore delle
-singole voci; se l'argomento \param{prefix} non è nullo la stringa da esso
+singole voci; se l'argomento \param{prefix} non è nullo la stringa da esso
 indicata viene utilizzata come prefisso per le singole voci. 
 
-L'ultimo argomento, \param{options}, consente di controllare la modalità con
+L'ultimo argomento, \param{options}, consente di controllare la modalità con
 cui viene generata la rappresentazione testuale. Un valore nullo fa si che
 vengano usati gli identificatori standard \texttt{user}, \texttt{group},
 \texttt{other} e \texttt{mask} con i nomi di utenti e gruppi risolti rispetto
-ai loro valori numerici. Altrimenti si può specificare un valore in forma di
+ai loro valori numerici. Altrimenti si può specificare un valore in forma di
 maschera binaria, da ottenere con un OR aritmetico dei valori riportati in
 tab.~\ref{tab:acl_to_text_options}.
 
@@ -4606,13 +4606,13 @@ tab.~\ref{tab:acl_to_text_options}.
     \const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che
                                    vengono eliminati dalla \const{ACL\_MASK}
                                    viene generato un commento con i permessi 
-                                   effettivamente risultanti; il commento è
+                                   effettivamente risultanti; il commento è
                                    separato con un tabulatore.\\
     \const{TEXT\_ALL\_EFFECTIVE} & viene generato un commento con i permessi
                                    effettivi per ciascuna voce che contiene
                                    permessi citati nella \const{ACL\_MASK},
                                    anche quando questi non vengono modificati
-                                   da essa; il commento è separato con un
+                                   da essa; il commento è separato con un
                                    tabulatore.\\
     \const{TEXT\_SMART\_INDENT}  & da usare in combinazione con le precedenti
                                    \const{TEXT\_SOME\_EFFECTIVE} e
@@ -4629,23 +4629,23 @@ tab.~\ref{tab:acl_to_text_options}.
 
 Come per \func{acl\_to\_text} anche in questo caso il buffer contenente la
 rappresentazione testuale dell'ACL, di cui la funzione restituisce
-l'indirizzo, viene allocato automaticamente, e dovrà essere esplicitamente
+l'indirizzo, viene allocato automaticamente, e dovrà essere esplicitamente
 disallocato con una chiamata ad \func{acl\_free}. Si tenga presente infine che
-questa funzione è una estensione specifica di Linux, e non è presente nella
+questa funzione è una estensione specifica di Linux, e non è presente nella
 bozza dello standard POSIX.1e.
 
 Per quanto utile per la visualizzazione o l'impostazione da comando delle ACL,
-la forma testuale non è la più efficiente per poter memorizzare i dati
+la forma testuale non è la più efficiente per poter memorizzare i dati
 relativi ad una ACL, ad esempio quando si vuole eseguirne una copia a scopo di
-archiviazione. Per questo è stata prevista la possibilità di utilizzare una
+archiviazione. Per questo è stata prevista la possibilità di utilizzare una
 rappresentazione delle ACL in una apposita forma binaria contigua e
-persistente. È così possibile copiare il valore di una ACL in un buffer e da
+persistente. È così possibile copiare il valore di una ACL in un buffer e da
 questa rappresentazione tornare indietro e generare una ACL. 
 
-Lo standard POSIX.1e prevede a tale scopo tre funzioni, la prima e più
-semplice è \funcd{acl\_size}, che consente di ottenere la dimensione che avrà
+Lo standard POSIX.1e prevede a tale scopo tre funzioni, la prima e più
+semplice è \funcd{acl\_size}, che consente di ottenere la dimensione che avrà
 la citata rappresentazione binaria, in modo da poter allocare per essa un
-buffer di dimensione sufficiente, il suo prototipo è:
+buffer di dimensione sufficiente, il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
@@ -4656,23 +4656,23 @@ buffer di dimensione sufficiente, il suo prototipo 
 
   \bodydesc{La funzione restituisce in caso di successo la dimensione in byte
     della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
-    caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+    caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
+  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
   \end{errlist}
 
 }
 \end{functions}
 
-Prima di effettuare la lettura della rappresentazione binaria è sempre
+Prima di effettuare la lettura della rappresentazione binaria è sempre
 necessario allocare un buffer di dimensione sufficiente a contenerla, pertanto
-prima si dovrà far ricorso a \funcd{acl\_size} per ottenere tale dimensione e
+prima si dovrà far ricorso a \funcd{acl\_size} per ottenere tale dimensione e
 poi allocare il buffer con una delle funzioni di
 sez.~\ref{sec:proc_mem_alloc}. Una volta terminato l'uso della
-rappresentazione binaria, il buffer dovrà essere esplicitamente disallocato.
+rappresentazione binaria, il buffer dovrà essere esplicitamente disallocato.
 
-La funzione che consente di leggere la rappresentazione binaria di una ACL è
-\funcd{acl\_copy\_ext}, il cui prototipo è:
+La funzione che consente di leggere la rappresentazione binaria di una ACL è
+\funcd{acl\_copy\_ext}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
@@ -4683,27 +4683,27 @@ La funzione che consente di leggere la rappresentazione binaria di una ACL 
 
   \bodydesc{La funzione restituisce in caso di successo la dimensione in byte
     della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
-    caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+    caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida o
-    \param{size} è negativo o nullo.
-  \item[\errcode{ERANGE}] il valore di \param{size} è più piccolo della
+  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida o
+    \param{size} è negativo o nullo.
+  \item[\errcode{ERANGE}] il valore di \param{size} è più piccolo della
     dimensione della rappresentazione della ACL.
   \end{errlist}
 
 }
 \end{functions}
 
-La funzione salverà la rappresentazione binaria della ACL indicata da
+La funzione salverà la rappresentazione binaria della ACL indicata da
 \param{acl} sul buffer posto all'indirizzo \param{buf\_p} e lungo \param{size}
 byte, restituendo la dimensione della stessa come valore di ritorno. Qualora
 la dimensione della rappresentazione ecceda il valore di \param{size} la
-funzione fallirà con un errore di \errcode{ERANGE}. La funzione non ha nessun
+funzione fallirà con un errore di \errcode{ERANGE}. La funzione non ha nessun
 effetto sulla ACL indicata da \param{acl}.
 
 Viceversa se si vuole ripristinare una ACL a partire dalla rappresentazione
-binaria della stessa disponibile in un buffer si potrà usare la funzione 
-\funcd{acl\_copy\_int}, il cui prototipo è:
+binaria della stessa disponibile in un buffer si potrà usare la funzione 
+\funcd{acl\_copy\_int}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
@@ -4714,11 +4714,11 @@ binaria della stessa disponibile in un buffer si potr
 
   \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
     di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
-    \var{errno} assumerà uno dei valori:
+    \var{errno} assumerà uno dei valori:
   \begin{errlist}
   \item[\errcode{EINVAL}] il buffer all'indirizzo \param{buf\_p} non contiene
     una rappresentazione corretta di una ACL.
-  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare un oggetto
+  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare un oggetto
     \type{acl\_t} per la ACL richiesta.
   \end{errlist}
 
@@ -4729,13 +4729,13 @@ La funzione in caso di successo alloca autonomamente un oggetto di tipo
 \type{acl\_t} che viene restituito come valore di ritorno con il contenuto
 della ACL rappresentata dai dati contenuti nel buffer puntato da
 \param{buf\_p}. Si ricordi che come per le precedenti funzioni l'oggetto
-\type{acl\_t} dovrà essere disallocato esplicitamente al termine del suo
+\type{acl\_t} dovrà essere disallocato esplicitamente al termine del suo
 utilizzo.
 
-Una volta che si disponga della ACL desiderata, questa potrà essere impostata
+Una volta che si disponga della ACL desiderata, questa potrà essere impostata
 su un file o una directory. Per impostare una ACL sono disponibili due
-funzioni; la prima è \funcd{acl\_set\_file}, che opera sia su file che su
-directory, ed il cui prototipo è:
+funzioni; la prima è \funcd{acl\_set\_file}, che opera sia su file che su
+directory, ed il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
@@ -4746,16 +4746,16 @@ directory, ed il cui prototipo 
   Imposta una ACL su un file o una directory.
 
   \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
   \item[\errcode{EACCES}] o un generico errore di accesso a \param{path} o il
-    valore di \param{type} specifica una ACL il cui tipo non può essere
+    valore di \param{type} specifica una ACL il cui tipo non può essere
     assegnato a \param{path}.
-  \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
+  \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
     ha in valore non corretto.
-  \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
+  \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
     dati aggiuntivi della ACL.
-  \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
+  \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
     contenuto in un filesystem che non supporta le ACL.
   \end{errlist}
   ed inoltre \errval{ENOENT}, \errval{ENOTDIR}, \errval{ENAMETOOLONG},
@@ -4767,16 +4767,16 @@ La funzione consente di assegnare la ACL contenuta in \param{acl} al file o
 alla directory indicate dal pathname \param{path}, mentre con \param{type} si
 indica il tipo di ACL utilizzando le costanti di tab.~\ref{tab:acl_type}, ma
 si tenga presente che le ACL di default possono essere solo impostate
-qualora \param{path} indichi una directory. Inoltre perché la funzione abbia
-successo la ACL dovrà essere valida, e contenere tutti le voci necessarie,
-unica eccezione è quella in cui si specifica una ACL vuota per cancellare la
-ACL di default associata a \func{path}.\footnote{questo però è una estensione
+qualora \param{path} indichi una directory. Inoltre perché la funzione abbia
+successo la ACL dovrà essere valida, e contenere tutti le voci necessarie,
+unica eccezione è quella in cui si specifica una ACL vuota per cancellare la
+ACL di default associata a \func{path}.\footnote{questo però è una estensione
   della implementazione delle ACL di Linux, la bozza di standard POSIX.1e
   prevedeva l'uso della apposita funzione \funcd{acl\_delete\_def\_file}, che
   prende come unico argomento il pathname della directory di cui si vuole
   cancellare l'ACL di default, per i dettagli si ricorra alla pagina di
-  manuale.}  La seconda funzione che consente di impostare una ACL è
-\funcd{acl\_set\_fd}, ed il suo prototipo è:
+  manuale.}  La seconda funzione che consente di impostare una ACL è
+\funcd{acl\_set\_fd}, ed il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
@@ -4786,35 +4786,35 @@ ACL di default associata a \func{path}.\footnote{questo per
   Imposta una ACL su un file descriptor.
 
   \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
   \item[\errcode{EBADF}].
-  \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
+  \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
     ha in valore non corretto.
-  \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
+  \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
     dati aggiuntivi della ACL.
-  \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
+  \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
     contenuto in un filesystem che non supporta le ACL.
   \end{errlist}
   ed inoltre \errval{EBADF}, \errval{EROFS}, \errval{EPERM}.
 }
 \end{functions}
 
-La funzione è del tutto è analoga a \funcd{acl\_set\_file} ma opera
+La funzione è del tutto è analoga a \funcd{acl\_set\_file} ma opera
 esclusivamente sui file identificati tramite un file descriptor. Non dovendo
-avere a che fare con directory (e con la conseguente possibilità di avere una
+avere a che fare con directory (e con la conseguente possibilità di avere una
 ACL di default) la funzione non necessita che si specifichi il tipo di ACL,
-che sarà sempre di accesso, e prende come unico argomento, a parte il file
+che sarà sempre di accesso, e prende come unico argomento, a parte il file
 descriptor, la ACL da impostare.
 
 Le funzioni viste finora operano a livello di una intera ACL, eseguendo in una
 sola volta tutte le operazioni relative a tutte le voci in essa contenuta. In
-generale è possibile modificare un singolo valore all'interno di una singola
+generale è possibile modificare un singolo valore all'interno di una singola
 voce direttamente con le funzioni previste dallo standard POSIX.1e.  Queste
-funzioni però sono alquanto macchinose da utilizzare per cui è molto più
-semplice operare direttamente sulla rappresentazione testuale. Questo è il
+funzioni però sono alquanto macchinose da utilizzare per cui è molto più
+semplice operare direttamente sulla rappresentazione testuale. Questo è il
 motivo per non tratteremo nei dettagli dette funzioni, fornendone solo una
-descrizione sommaria; chi fosse interessato potrà ricorrere alle pagina di
+descrizione sommaria; chi fosse interessato potrà ricorrere alle pagina di
 manuale.
 
 Se si vuole operare direttamente sui contenuti di un oggetto di tipo
@@ -4822,10 +4822,10 @@ Se si vuole operare direttamente sui contenuti di un oggetto di tipo
 opportuni puntatori di tipo \type{acl\_entry\_t}, che possono essere ottenuti
 dalla funzione \funcd{acl\_get\_entry} (per una voce esistente) o dalla
 funzione \funcd{acl\_create\_entry} per una voce da aggiungere. Nel caso della
-prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle
+prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle
 singole voci successive alla prima.
 
-Una volta ottenuti detti puntatori si potrà operare sui contenuti delle singole
+Una volta ottenuti detti puntatori si potrà operare sui contenuti delle singole
 voci; con le funzioni \funcd{acl\_get\_tag\_type}, \funcd{acl\_get\_qualifier},
 \funcd{acl\_get\_permset} si potranno leggere rispettivamente tipo,
 qualificatore e permessi mentre con le corrispondente funzioni
@@ -4843,11 +4843,11 @@ ad un altra con \funcd{acl\_copy\_entry} o eliminare una voce da una ACL con
 \subsection{La funzione \func{chroot}}
 \label{sec:file_chroot}
 
-% TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
+% TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
 % dentro chroot SELinux e AppArmor ???
 
-Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
-\func{chroot} viene usata spesso per restringere le capacità di accesso di un
+Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
+\func{chroot} viene usata spesso per restringere le capacità di accesso di un
 programma ad una sezione limitata del filesystem, per cui ne parleremo in
 questa sezione.
 
@@ -4859,12 +4859,12 @@ di norma corrispondente alla radice dell'albero di file e directory come visto
 dal kernel (ed illustrato in sez.~\ref{sec:file_organization}), ha per il
 processo il significato specifico di directory rispetto alla quale vengono
 risolti i \itindsub{pathname}{assoluto}\textit{pathname}
-assoluti.\footnote{cioè quando un processo chiede la risoluzione di un
+assoluti.\footnote{cioè quando un processo chiede la risoluzione di un
   \textit{pathname}, il kernel usa sempre questa directory come punto di
   partenza.} Il fatto che questo valore sia specificato per ogni processo apre
-allora la possibilità di modificare le modalità di risoluzione dei
+allora la possibilità di modificare le modalità di risoluzione dei
 \textit{pathname} assoluti da parte di un processo cambiando questa directory,
-così come si fa coi \itindsub{pathname}{relativo}\textit{pathname} relativi
+così come si fa coi \itindsub{pathname}{relativo}\textit{pathname} relativi
 cambiando la directory di lavoro.
 
 Normalmente la directory radice di un processo coincide anche con la radice
@@ -4873,57 +4873,57 @@ padre da ogni processo figlio, in generale i processi risolvono i
 \itindsub{pathname}{assoluto} \textit{pathname} assoluti a partire sempre
 dalla stessa directory, che corrisponde alla radice del sistema.
 
-In certe situazioni però è utile poter impedire che un processo possa accedere
-a tutto il filesystem; per far questo si può cambiare la sua directory radice
-con la funzione \funcd{chroot}, il cui prototipo è:
+In certe situazioni però è utile poter impedire che un processo possa accedere
+a tutto il filesystem; per far questo si può cambiare la sua directory radice
+con la funzione \funcd{chroot}, il cui prototipo è:
 \begin{prototype}{unistd.h}{int chroot(const char *path)}
   Cambia la directory radice del processo a quella specificata da
   \param{path}.
   
 \bodydesc{La funzione restituisce zero in caso di successo e -1 per
-    un errore, in caso di errore \var{errno} può assumere i valori:
+    un errore, in caso di errore \var{errno} può assumere i valori:
   \begin{errlist}
-  \item[\errcode{EPERM}] l'user-ID effettivo del processo non è zero.
+  \item[\errcode{EPERM}] l'user-ID effettivo del processo non è zero.
   \end{errlist}
   ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
   \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP};
   \errval{EROFS} e \errval{EIO}.}
 \end{prototype}
-\noindent in questo modo la directory radice del processo diventerà
+\noindent in questo modo la directory radice del processo diventerà
 \param{path} (che ovviamente deve esistere) ed ogni
 \itindsub{pathname}{assoluto}\textit{pathname} assoluto usato dalle funzioni
-chiamate nel processo sarà risolto a partire da essa, rendendo impossibile
-accedere alla parte di albero sovrastante.  Si ha così quella che viene
-chiamata una \textit{chroot jail}, in quanto il processo non può più accedere
-a file al di fuori della sezione di albero in cui è stato
+chiamate nel processo sarà risolto a partire da essa, rendendo impossibile
+accedere alla parte di albero sovrastante.  Si ha così quella che viene
+chiamata una \textit{chroot jail}, in quanto il processo non può più accedere
+a file al di fuori della sezione di albero in cui è stato
 \textsl{imprigionato}. 
 
-Solo un processo con i privilegi di amministratore può usare questa funzione,
-e la nuova radice, per quanto detto in sez.~\ref{sec:proc_fork}, sarà ereditata
-da tutti i suoi processi figli. Si tenga presente però che la funzione non
+Solo un processo con i privilegi di amministratore può usare questa funzione,
+e la nuova radice, per quanto detto in sez.~\ref{sec:proc_fork}, sarà ereditata
+da tutti i suoi processi figli. Si tenga presente però che la funzione non
 cambia la directory di lavoro, che potrebbe restare fuori dalla \textit{chroot
   jail}.
 
-Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita
+Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita
 si cedono i privilegi di root. Infatti se per un qualche motivo il processo
-resta con la directory di lavoro fuori dalla \textit{chroot jail}, potrà
+resta con la directory di lavoro fuori dalla \textit{chroot jail}, potrà
 comunque accedere a tutto il resto del filesystem usando
 \itindsub{pathname}{relativo}\textit{pathname} relativi, i quali, partendo
-dalla directory di lavoro che è fuori della \textit{chroot jail}, potranno
+dalla directory di lavoro che è fuori della \textit{chroot jail}, potranno
 (con l'uso di ``\texttt{..}'') risalire fino alla radice effettiva del
 filesystem.
 
-Ma se ad un processo restano i privilegi di amministratore esso potrà comunque
+Ma se ad un processo restano i privilegi di amministratore esso potrà comunque
 portare la sua directory di lavoro fuori dalla \textit{chroot jail} in cui si
 trova. Basta infatti creare una nuova \textit{chroot jail} con l'uso di
 \func{chroot} su una qualunque directory contenuta nell'attuale directory di
 lavoro.  Per questo motivo l'uso di questa funzione non ha molto senso quando
 un processo necessita dei privilegi di root per le sue normali operazioni.
 
-Un caso tipico di uso di \func{chroot} è quello di un server FTP anonimo, in
+Un caso tipico di uso di \func{chroot} è quello di un server FTP anonimo, in
 questo caso infatti si vuole che il server veda solo i file che deve
 trasferire, per cui in genere si esegue una \func{chroot} sulla directory che
-contiene i file.  Si tenga presente però che in questo caso occorrerà
+contiene i file.  Si tenga presente però che in questo caso occorrerà
 replicare all'interno della \textit{chroot jail} tutti i file (in genere
 programmi e librerie) di cui il server potrebbe avere bisogno.
 
diff --git a/fileintro.tex b/fileintro.tex
index e001acb..a195c7a 100644
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -12,13 +12,13 @@
 \chapter{L'architettura dei file}
 \label{cha:file_intro}
 
-Uno dei concetti fondamentali dell'architettura di un sistema Unix è il
-cosiddetto \textit{everything is a file}, cioè il fatto che l'accesso ai vari
+Uno dei concetti fondamentali dell'architettura di un sistema Unix è il
+cosiddetto \textit{everything is a file}, cioè il fatto che l'accesso ai vari
 dispositivi di input/output del computer viene effettuato attraverso
 un'interfaccia astratta che tratta le periferiche allo stesso modo dei normali
 file di dati.
 
-Questo significa che si può accedere a qualunque periferica del computer,
+Questo significa che si può accedere a qualunque periferica del computer,
 dalla seriale, alla parallela, alla console, e agli stessi dischi attraverso i
 cosiddetti \index{file!di~dispositivo} file di dispositivo (i cosiddetti
 \textit{device file}). Questi sono dei file speciali agendo sui quali i
@@ -29,8 +29,8 @@ dati.
 In questo capitolo forniremo una descrizione dell'architettura dei file in
 Linux, iniziando da una panoramica sulle caratteristiche principali delle
 interfacce con cui i processi accedono ai file (che tratteremo in dettaglio
-nei capitoli seguenti), per poi passare ad una descrizione più dettagliata
-delle modalità con cui detto accesso viene realizzato dal sistema.
+nei capitoli seguenti), per poi passare ad una descrizione più dettagliata
+delle modalità con cui detto accesso viene realizzato dal sistema.
 
 
 
@@ -39,7 +39,7 @@ delle modalit
 
 Per poter accedere ai file, il kernel deve mettere a disposizione dei
 programmi le opportune interfacce che consentano di leggerne il contenuto; il
-sistema cioè deve provvedere ad organizzare e rendere accessibile in maniera
+sistema cioè deve provvedere ad organizzare e rendere accessibile in maniera
 opportuna l'informazione tenuta sullo spazio grezzo disponibile sui dischi.
 Questo viene fatto strutturando l'informazione sul disco attraverso quello che
 si chiama un \textit{filesystem} (vedi sez.~\ref{sec:file_arch_func}), essa
@@ -60,20 +60,20 @@ file vengono tenuti all'interno di un unico albero la cui radice (quella che
 viene chiamata \textit{root directory}) viene montata all'avvio.  Un file
 viene identificato dall'utente usando quello che viene chiamato
 \textit{pathname}\footnote{il manuale della \acr{glibc} depreca questa
-  nomenclatura, che genererebbe confusione poiché \textit{path} indica anche
+  nomenclatura, che genererebbe confusione poiché \textit{path} indica anche
   un insieme di directory su cui effettuare una ricerca (come quello in cui si
   cercano i comandi). Al suo posto viene proposto l'uso di \textit{filename} e
   di componente per il nome del file all'interno della directory. Non
-  seguiremo questa scelta dato che l'uso della parola \textit{pathname} è
-  ormai così comune che mantenerne l'uso è senz'altro più chiaro
-  dell'alternativa proposta.}, cioè il percorso che si deve fare per accedere
-al file a partire dalla \textit{root directory}, che è composto da una serie
+  seguiremo questa scelta dato che l'uso della parola \textit{pathname} è
+  ormai così comune che mantenerne l'uso è senz'altro più chiaro
+  dell'alternativa proposta.}, cioè il percorso che si deve fare per accedere
+al file a partire dalla \textit{root directory}, che è composto da una serie
 di nomi separati da una ``\file{/}''.
 
 All'avvio del sistema, completata la fase di inizializzazione, il kernel
 riceve dal bootloader l'indicazione di quale dispositivo contiene il
 filesystem da usare come punto di partenza e questo viene montato come radice
-dell'albero (cioè nella directory \file{/}); tutti gli ulteriori filesystem
+dell'albero (cioè nella directory \file{/}); tutti gli ulteriori filesystem
 che possono essere su altri dispositivi dovranno poi essere inseriti
 nell'albero montandoli su opportune directory del filesystem montato come
 radice.
@@ -83,17 +83,17 @@ alcune strutture interne del kernel) sono generati automaticamente dal kernel
 stesso, ma anche essi devono essere montati all'interno dell'albero dei file.
 
 Una directory, come vedremo in maggior dettaglio in
-sez.~\ref{sec:file_vfs_work}, è anch'essa un file, solo che è un file
-particolare che il kernel riconosce come tale. Il suo scopo è quello di
+sez.~\ref{sec:file_vfs_work}, è anch'essa un file, solo che è un file
+particolare che il kernel riconosce come tale. Il suo scopo è quello di
 contenere una lista di nomi di file e le informazioni che associano ciascun
 nome al contenuto. Dato che questi nomi possono corrispondere ad un qualunque
 oggetto del filesystem, compresa un'altra directory, si ottiene naturalmente
 un'organizzazione ad albero inserendo nomi di directory in altre directory.
 
-Un file può essere indicato rispetto alla directory corrente semplicemente
+Un file può essere indicato rispetto alla directory corrente semplicemente
 specificandone il nome\footnote{il manuale delle \acr{glibc} chiama i nomi
   contenuti nelle directory \textsl{componenti} (in inglese \textit{file name
-    components}), noi li chiameremo più semplicemente \textsl{nomi} o
+    components}), noi li chiameremo più semplicemente \textsl{nomi} o
   \textsl{voci}.}  da essa contenuto.  All'interno dello stesso albero si
 potranno poi inserire anche tutti gli altri oggetti visti attraverso
 l'interfaccia che manipola i file come le fifo, i link, i socket e gli stessi
@@ -101,32 +101,32 @@ l'interfaccia che manipola i file come le fifo, i link, i socket e gli stessi
 convenzione, sono inseriti nella directory \file{/dev}).
 
 Il nome completo di un file viene chiamato \textit{pathname} ed il
-procedimento con cui si individua il file a cui esso fa riferimento è chiamato
+procedimento con cui si individua il file a cui esso fa riferimento è chiamato
 risoluzione del nome (\textit{filename resolution} o \textit{pathname
   resolution}).  La risoluzione viene fatta esaminando il \textit{pathname} da
 sinistra a destra e localizzando ogni nome nella directory indicata dal nome
 precedente usando il carattere ``\texttt{/}'' come separatore\footnote{nel
   caso di nome vuoto, il costrutto \file{//} viene considerato equivalente a
-  \file{/}.}: ovviamente, perché il procedimento funzioni, occorre che i nomi
+  \file{/}.}: ovviamente, perché il procedimento funzioni, occorre che i nomi
 indicati come directory esistano e siano effettivamente directory, inoltre i
 permessi (si veda sez.~\ref{sec:file_access_control}) devono consentire
 l'accesso all'intero \textit{pathname}.
 
 Se il \textit{pathname} comincia con il carattere ``\texttt{/}'' la ricerca
 parte dalla directory radice del processo; questa, a meno di un \func{chroot}
-(su cui torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i
+(su cui torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i
 processi ed equivale alla directory radice dell'albero dei file: in questo
 caso si parla di un \textsl{pathname assoluto} \itindsub{pathname}{assoluto}.
 Altrimenti la ricerca parte dalla directory corrente (su cui torneremo in
-sez.~\ref{sec:file_work_dir}) ed il pathname è detto
+sez.~\ref{sec:file_work_dir}) ed il pathname è detto
 \itindsub{pathname}{relativo} \textsl{pathname relativo}.
 
 I nomi ``\file{.}'' e ``\file{..}'' hanno un significato speciale e vengono
 inseriti in ogni directory: il primo fa riferimento alla directory corrente e
 il secondo alla directory \textsl{genitrice} (o \textit{parent directory})
-cioè la directory che contiene il riferimento alla directory corrente; nel
+cioè la directory che contiene il riferimento alla directory corrente; nel
 caso la directory corrente coincida con la directory radice, allora il
-riferimento è a se stessa.  
+riferimento è a se stessa.  
 
 \itindend{pathname}
 
@@ -138,24 +138,24 @@ Come detto in precedenza, in Unix esistono vari tipi di file; in Linux questi
 sono implementati come oggetti del \textit{Virtual File System} (vedi
 sez.~\ref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal
-\itindex{Virtual~File~System} \textit{Virtual File System} è riportato in
+\itindex{Virtual~File~System} \textit{Virtual File System} è riportato in
 tab.~\ref{tab:file_file_types}.
 
 Si tenga ben presente che questa classificazione non ha nulla a che fare con
 la classificazione dei file (che in questo caso sono sempre file di dati) in
 base al loro contenuto, o tipo di accesso. Essa riguarda invece il tipo di
-oggetti; in particolare è da notare la presenza dei cosiddetti file speciali.
+oggetti; in particolare è da notare la presenza dei cosiddetti file speciali.
 Alcuni di essi, come le \textit{fifo} (che tratteremo in
 sez.~\ref{sec:ipc_named_pipe}) ed i \textit{socket} (che tratteremo in
 cap.~\ref{cha:socket_intro}) non sono altro che dei riferimenti per utilizzare
-delle funzionalità di comunicazione fornite dal kernel. Gli altri sono i
+delle funzionalità di comunicazione fornite dal kernel. Gli altri sono i
 \index{file!di~dispositivo} \textsl{file di dispositivo} (o \textit{device
   file}) che costituiscono una interfaccia diretta per leggere e scrivere sui
 dispositivi fisici; essi vengono suddivisi in due grandi categorie, \textsl{a
-  blocchi} e \textsl{a caratteri} a seconda delle modalità in cui il
+  blocchi} e \textsl{a caratteri} a seconda delle modalità in cui il
 dispositivo sottostante effettua le operazioni di I/O.\footnote{in sostanza i
   dispositivi a blocchi (ad esempio i dischi) corrispondono a periferiche per
-  le quali è richiesto che l'I/O venga effettuato per blocchi di dati di
+  le quali è richiesto che l'I/O venga effettuato per blocchi di dati di
   dimensioni fissate (ad esempio le dimensioni di un settore), mentre nei
   dispositivi a caratteri l'I/O viene effettuato senza nessuna particolare
   struttura.}
@@ -192,85 +192,85 @@ dispositivo sottostante effettua le operazioni di I/O.\footnote{in sostanza i
 \end{table}
 
 Una delle differenze principali con altri sistemi operativi (come il VMS o
-Windows) è che per Unix tutti i file di dati sono identici e contengono un
-flusso continuo di byte. Non esiste cioè differenza per come vengono visti dal
+Windows) è che per Unix tutti i file di dati sono identici e contengono un
+flusso continuo di byte. Non esiste cioè differenza per come vengono visti dal
 sistema file di diverso contenuto o formato (come nel caso di quella fra file
-di testo e binari che c'è in Windows) né c'è una strutturazione a record per
+di testo e binari che c'è in Windows) né c'è una strutturazione a record per
 il cosiddetto ``\textsl{accesso diretto}'' come nel caso del
 VMS.\footnote{questo vale anche per i dispositivi a blocchi: la strutturazione
   dell'I/O in blocchi di dimensione fissa avviene solo all'interno del kernel,
-  ed è completamente trasparente all'utente. Inoltre talvolta si parla di
-  \textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che
-  fare con tutto ciò, di effettuare, attraverso degli appositi
+  ed è completamente trasparente all'utente. Inoltre talvolta si parla di
+  \textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che
+  fare con tutto ciò, di effettuare, attraverso degli appositi
   \index{file!di~dispositivo} file di dispositivo, operazioni di I/O
   direttamente sui dischi senza passare attraverso un filesystem, il
   cosiddetto \textit{raw access}, introdotto coi kernel della serie 2.4.x ed
   in sostanziale disuso.}
 
-Una seconda differenza è nel formato dei file di testo: in Unix la fine riga è
+Una seconda differenza è nel formato dei file di testo: in Unix la fine riga è
 codificata in maniera diversa da Windows o dal vecchio MacOS, in particolare
-il fine riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR}
+il fine riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR}
 (\verb|\r|) del vecchio MacOS e del \texttt{CR LF} di Windows.\footnote{per
   questo esistono in Linux dei programmi come \cmd{unix2dos} e \cmd{dos2unix}
-  che effettuano una conversione fra questi due formati di testo.} Questo può
+  che effettuano una conversione fra questi due formati di testo.} Questo può
 causare alcuni problemi qualora nei programmi si facciano assunzioni sul
 terminatore della riga.
 
 Si ricordi infine che un kernel Unix non fornisce nessun supporto per la
-tipizzazione dei file di dati e che non c'è nessun supporto del sistema per le
-estensioni come parte del filesystem.\footnote{non è così ad esempio nel
+tipizzazione dei file di dati e che non c'è nessun supporto del sistema per le
+estensioni come parte del filesystem.\footnote{non è così ad esempio nel
   filesystem HFS dei Mac, che supporta delle risorse associate ad ogni file,
   che specificano fra l'altro il contenuto ed il programma da usare per
-  leggerlo. In realtà per alcuni filesystem esiste la possibilità di
+  leggerlo. In realtà per alcuni filesystem esiste la possibilità di
   associare delle risorse ai file con gli \textit{extended attributes} (vedi
-  sez.~\ref{sec:file_xattr}), ma è una caratteristica tutt'ora poco
+  sez.~\ref{sec:file_xattr}), ma è una caratteristica tutt'ora poco
   utilizzata, dato che non corrisponde al modello classico dei file in un
-  sistema Unix.} Ciò nonostante molti programmi adottano delle convenzioni per
+  sistema Unix.} Ciò nonostante molti programmi adottano delle convenzioni per
 i nomi dei file, ad esempio il codice C normalmente si mette in file con
-l'estensione \file{.c}; un'altra tecnica molto usata è quella di utilizzare i
+l'estensione \file{.c}; un'altra tecnica molto usata è quella di utilizzare i
 primi 4 byte del file per memorizzare un \textit{magic number} che classifichi
 il contenuto; entrambe queste tecniche, per quanto usate ed accettate in
-maniera diffusa, restano solo delle convenzioni il cui rispetto è demandato
+maniera diffusa, restano solo delle convenzioni il cui rispetto è demandato
 alle applicazioni stesse.
 
 
 \subsection{Le due interfacce ai file}
 \label{sec:file_io_api}
 
-In Linux le modalità di accesso ai file e le relative interfacce di
-programmazione sono due, basate su due diversi meccanismi con cui è possibile
+In Linux le modalità di accesso ai file e le relative interfacce di
+programmazione sono due, basate su due diversi meccanismi con cui è possibile
 accedere al loro contenuto.
 
-La prima è l'interfaccia standard di Unix, quella che il manuale delle
+La prima è l'interfaccia standard di Unix, quella che il manuale delle
 \textsl{glibc} chiama interfaccia dei descrittori di file (o \textit{file
-  descriptor}).  È un'interfaccia specifica dei sistemi unix-like e fornisce
+  descriptor}).  È un'interfaccia specifica dei sistemi unix-like e fornisce
 un accesso non bufferizzato; la tratteremo in dettaglio in
 cap.~\ref{cha:file_unix_interface}.
 
-L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
+L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
 bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
-direttamente le system call del kernel (in realtà il kernel effettua al suo
+direttamente le system call del kernel (in realtà il kernel effettua al suo
 interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
 dispositivi); i \index{file!descriptor} \textit{file descriptor} sono
-rappresentati da numeri interi (cioè semplici variabili di tipo \ctyp{int}).
-L'interfaccia è definita nell'header \file{unistd.h}.
+rappresentati da numeri interi (cioè semplici variabili di tipo \ctyp{int}).
+L'interfaccia è definita nell'header \file{unistd.h}.
 
-La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
-\index{file!stream} \textit{stream}.\footnote{in realtà una interfaccia con lo
-  stesso nome è stata introdotta a livello di kernel negli Unix derivati da
+La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
+\index{file!stream} \textit{stream}.\footnote{in realtà una interfaccia con lo
+  stesso nome è stata introdotta a livello di kernel negli Unix derivati da
   \textit{System V}, come strato di astrazione per file e socket; in Linux
   questa interfaccia, che comunque ha avuto poco successo, non esiste, per cui
   facendo riferimento agli \index{file!stream} \textit{stream} useremo il
   significato adottato dal manuale delle \acr{glibc}.} Essa fornisce funzioni
-più evolute e un accesso bufferizzato (controllato dalla implementazione fatta
+più evolute e un accesso bufferizzato (controllato dalla implementazione fatta
 dalle \acr{glibc}), la tratteremo in dettaglio nel
 cap.~\ref{cha:files_std_interface}.
 
-Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
+Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
 anche su tutti i sistemi non Unix. Gli \index{file!stream} \textit{stream}
 sono oggetti complessi e sono rappresentati da puntatori ad un opportuna
 struttura definita dalle librerie del C; si accede ad essi sempre in maniera
-indiretta utilizzando il tipo \ctyp{FILE *}.  L'interfaccia è definita
+indiretta utilizzando il tipo \ctyp{FILE *}.  L'interfaccia è definita
 nell'header \file{stdio.h}.
 
 Entrambe le interfacce possono essere usate per l'accesso ai file come agli
@@ -280,13 +280,13 @@ controllo (descritte in sez.~\ref{sec:file_fcntl} e sez.~\ref{sec:file_ioctl})
 su un qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard
 di Unix con i \textit{file descriptor}. Allo stesso modo devono essere usati i
 \index{file!descriptor} \textit{file descriptor} se si vuole ricorrere a
-modalità speciali di I/O come il \index{file!locking} \textit{file locking} o
+modalità speciali di I/O come il \index{file!locking} \textit{file locking} o
 l'I/O non-bloccante (vedi cap.~\ref{cha:file_advanced}).
 
 Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
 quella dei \textit{file descriptor}, che permette di poter scegliere tra
 diversi stili di bufferizzazione.  Il maggior vantaggio degli \textit{stream}
-è che l'interfaccia per le operazioni di input/output è enormemente più ricca
+è che l'interfaccia per le operazioni di input/output è enormemente più ricca
 di quella dei \textit{file descriptor}, che forniscono solo funzioni
 elementari per la lettura/scrittura diretta di blocchi di byte.  In
 particolare gli \index{file!stream} \textit{stream} dispongono di tutte le
@@ -294,17 +294,17 @@ funzioni di formattazione per l'input e l'output adatte per manipolare anche i
 dati in forma di linee o singoli caratteri.
 
 In ogni caso, dato che gli stream sono implementati sopra l'interfaccia
-standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da
+standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da
 uno stream ed eseguirvi operazioni di basso livello, o associare in un secondo
 tempo uno \index{file!stream} \textit{stream} ad un \index{file!descriptor}
 \textit{file descriptor}.
 
-In generale, se non necessitano specificatamente le funzionalità di basso
-livello, è opportuno usare sempre gli \index{file!stream} \textit{stream} per
-la loro maggiore portabilità, essendo questi ultimi definiti nello standard
+In generale, se non necessitano specificatamente le funzionalità di basso
+livello, è opportuno usare sempre gli \index{file!stream} \textit{stream} per
+la loro maggiore portabilità, essendo questi ultimi definiti nello standard
 ANSI C; l'interfaccia con i \index{file!descriptor} \textit{file descriptor}
-infatti segue solo lo standard POSIX.1 dei sistemi Unix, ed è pertanto di
-portabilità più limitata.
+infatti segue solo lo standard POSIX.1 dei sistemi Unix, ed è pertanto di
+portabilità più limitata.
 
 
 
@@ -312,9 +312,9 @@ portabilit
 \label{sec:file_arch_func}
 
 In questa sezione esamineremo come viene implementato l'accesso ai file in
-Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
+Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
 prima le caratteristiche generali di un filesystem di un sistema unix-like,
-per poi trattare in maniera un po' più dettagliata il filesystem più usato con
+per poi trattare in maniera un po' più dettagliata il filesystem più usato con
 Linux, l'\acr{ext2} (e derivati).
 
 
@@ -326,9 +326,9 @@ Linux, l'\acr{ext2} (e derivati).
 
 \itindbeg{Virtual~File~System}
 
-In Linux il concetto di \textit{everything is a file} è stato implementato
-attraverso il \textit{Virtual File System} (da qui in avanti VFS) che è uno
-strato intermedio che il kernel usa per accedere ai più svariati filesystem
+In Linux il concetto di \textit{everything is a file} è stato implementato
+attraverso il \textit{Virtual File System} (da qui in avanti VFS) che è uno
+strato intermedio che il kernel usa per accedere ai più svariati filesystem
 mantenendo la stessa interfaccia per i programmi in user space. Esso fornisce
 un livello di indirezione che permette di collegare le operazioni di
 manipolazione sui file alle operazioni di I/O, e gestisce l'organizzazione di
@@ -337,10 +337,10 @@ permettendo la coesistenza di filesystem differenti all'interno dello stesso
 albero delle directory.
 
 Quando un processo esegue una system call che opera su un file, il kernel
-chiama sempre una funzione implementata nel VFS; la funzione eseguirà le
-manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alle
+chiama sempre una funzione implementata nel VFS; la funzione eseguirà le
+manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alle
 opportune funzioni del filesystem specifico a cui si fa riferimento. Saranno
-queste a chiamare le funzioni di più basso livello che eseguono le operazioni
+queste a chiamare le funzioni di più basso livello che eseguono le operazioni
 di I/O sul dispositivo fisico, secondo lo schema riportato in
 fig.~\ref{fig:file_VFS_scheme}.
 
@@ -359,41 +359,41 @@ strutture definite nel kernel.
 
 Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun
 filesystem supportato: quando si vuole inserire il supporto di un nuovo
-filesystem tutto quello che occorre è chiamare la funzione
+filesystem tutto quello che occorre è chiamare la funzione
 \code{register\_filesystem} passandole un'apposita struttura
 \code{file\_system\_type} che contiene i dettagli per il riferimento
-all'implementazione del medesimo, che sarà aggiunta alla citata tabella.
+all'implementazione del medesimo, che sarà aggiunta alla citata tabella.
 
 In questo modo quando viene effettuata la richiesta di montare un nuovo disco
-(o qualunque altro \textit{block device} che può contenere un filesystem), il
-VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare
-nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco
+(o qualunque altro \textit{block device} che può contenere un filesystem), il
+VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare
+nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco
 il superblock (vedi sez.~\ref{sec:file_ext2}), inizializzare tutte le variabili
 interne e restituire uno speciale descrittore dei filesystem montati al VFS;
 attraverso quest'ultimo diventa possibile accedere alle funzioni specifiche per
 l'uso di quel filesystem.
 
-Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
+Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
 una apposita struttura che contiene vari dati come le informazioni comuni ad
 ogni filesystem, i dati privati relativi a quel filesystem specifico, e i
-puntatori alle funzioni del kernel relative al filesystem. Il VFS può così
+puntatori alle funzioni del kernel relative al filesystem. Il VFS può così
 usare le funzioni contenute nel \textit{filesystem descriptor} per accedere
 alle funzioni specifiche di quel filesystem.
 
 Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
-su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni
+su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni
 relative al file in uso, insieme ai puntatori alle funzioni dello specifico
 filesystem usate per l'accesso dal VFS; in particolare il descrittore
 \index{inode} dell'inode contiene i puntatori alle funzioni che possono essere
 usate su qualunque file (come \func{link}, \func{stat} e \func{open}), mentre
 il descrittore di file contiene i puntatori alle funzioni che vengono usate
-sui file già aperti.
+sui file già aperti.
 
 
 \subsection{Il funzionamento del \textit{Virtual File System}}
 \label{sec:file_vfs_work}
 
-La funzione più importante implementata dal VFS è la system call \func{open}
+La funzione più importante implementata dal VFS è la system call \func{open}
 che permette di aprire un file. Dato un \itindex{pathname} \textit{pathname}
 viene eseguita una ricerca dentro la \textit{directory entry cache} (in breve
 \textit{dcache}), una tabella che contiene tutte le \textit{directory entry}
@@ -401,28 +401,28 @@ viene eseguita una ricerca dentro la \textit{directory entry cache} (in breve
 efficiente il \textit{pathname} a una specifica \textit{dentry}.
 
 Una singola \textit{dentry} contiene in genere il puntatore ad un
-\index{inode} \textit{inode}; quest'ultimo è la struttura base che sta sul
+\index{inode} \textit{inode}; quest'ultimo è la struttura base che sta sul
 disco e che identifica un singolo oggetto del VFS sia esso un file ordinario,
 una directory, un link simbolico, una FIFO, un file di
 \index{file!di~dispositivo} dispositivo, o una qualsiasi altra cosa che possa
 essere rappresentata dal VFS (i tipi di file riportati in
-tab.~\ref{tab:file_file_types}). A ciascuno di essi è associata pure una
+tab.~\ref{tab:file_file_types}). A ciascuno di essi è associata pure una
 struttura che sta in memoria, e che, oltre alle informazioni sullo specifico
 file, contiene anche il riferimento alle funzioni (i \textsl{metodi} del VFS)
 da usare per poterlo manipolare.
 
 Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,
-vengono usate per motivi di velocità, gli \index{inode} \textit{inode} invece
+vengono usate per motivi di velocità, gli \index{inode} \textit{inode} invece
 stanno su disco e vengono copiati in memoria quando serve, ed ogni cambiamento
 viene copiato all'indietro sul disco (aggiornando i cosiddetti
 \textsl{metadati} del file), gli \index{inode} inode che stanno in memoria
-sono \index{inode} inode del VFS ed è ad essi che puntano le singole
+sono \index{inode} inode del VFS ed è ad essi che puntano le singole
 \textit{dentry}.
 
-La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
-l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è
-parziale (la \textit{dcache} cioè contiene solo le \textit{dentry} per i file
-per i quali è stato richiesto l'accesso), quando si vuole risolvere un nuovo
+La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
+l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è
+parziale (la \textit{dcache} cioè contiene solo le \textit{dentry} per i file
+per i quali è stato richiesto l'accesso), quando si vuole risolvere un nuovo
 \itindex{pathname} \textit{pathname} il VFS deve creare una nuova
 \textit{dentry} e caricare \index{inode} l'inode corrispondente in memoria.
 
@@ -443,7 +443,7 @@ metodi che implementano le operazioni disponibili sul file. In questo modo i
 processi in user space possono accedere alle operazioni attraverso detti
 metodi, che saranno diversi a seconda del tipo di file (o dispositivo) aperto
 (su questo torneremo in dettaglio in sez.~\ref{sec:file_fd}). Un elenco delle
-operazioni previste dal kernel è riportato in
+operazioni previste dal kernel è riportato in
 tab.~\ref{tab:file_file_operations}.
 
 \begin{table}[htb]
@@ -469,7 +469,7 @@ tab.~\ref{tab:file_file_operations}.
     \textsl{\code{mmap}}   & Mappa il file in memoria (vedi 
                              sez.~\ref{sec:file_memory_map}).\\
     \textsl{\code{release}}& Chiamata quando l'ultimo riferimento a un file 
-                             aperto è chiuso.\\
+                             aperto è chiuso.\\
     \textsl{\code{fsync}}  & Sincronizza il contenuto del file (vedi
                              sez.~\ref{sec:file_sync}).\\
     \textsl{\code{fasync}} & Abilita l'I/O asincrono (vedi
@@ -481,15 +481,15 @@ tab.~\ref{tab:file_file_operations}.
 \end{table}
 
 In questo modo per ciascun file diventano possibili una serie di operazioni
-(non è detto che tutte siano disponibili), che costituiscono l'interfaccia
-astratta del VFS.  Qualora se ne voglia eseguire una, il kernel andrà ad
+(non è detto che tutte siano disponibili), che costituiscono l'interfaccia
+astratta del VFS.  Qualora se ne voglia eseguire una, il kernel andrà ad
 utilizzare l'opportuna funzione dichiarata in \struct{f\_ops} appropriata al
 tipo di file in questione.
 
-Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un
+Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un
 normale file di dati; ovviamente certe operazioni (nel caso della seriale ad
-esempio la \code{seek}) non saranno disponibili, però con questo sistema
-l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOS) è
+esempio la \code{seek}) non saranno disponibili, però con questo sistema
+l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOS) è
 immediato e (relativamente) trasparente per l'utente ed il programmatore.
 \itindend{Virtual~File~System}
 
@@ -497,22 +497,22 @@ immediato e (relativamente) trasparente per l'utente ed il programmatore.
 \subsection{Il funzionamento di un filesystem Unix}
 \label{sec:file_filesystem}
 
-Come già accennato in sez.~\ref{sec:file_organization} Linux (ed ogni sistema
+Come già accennato in sez.~\ref{sec:file_organization} Linux (ed ogni sistema
 unix-like) organizza i dati che tiene su disco attraverso l'uso di un
-filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
-quella di poter supportare, grazie al VFS, una enorme quantità di filesystem
-diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
+filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
+quella di poter supportare, grazie al VFS, una enorme quantità di filesystem
+diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
 proprie.  Per questo per il momento non entreremo nei dettagli di un
 filesystem specifico, ma daremo una descrizione a grandi linee che si adatta
 alle caratteristiche comuni di qualunque filesystem di sistema unix-like.
 
 Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
-partizione può contenere un filesystem. La strutturazione tipica
-dell'informazione su un disco è riportata in fig.~\ref{fig:file_disk_filesys};
+partizione può contenere un filesystem. La strutturazione tipica
+dell'informazione su un disco è riportata in fig.~\ref{fig:file_disk_filesys};
 in essa si fa riferimento alla struttura del filesystem \acr{ext2}, che
 prevede una separazione dei dati in \textit{block group} che replicano il
 superblock (ma sulle caratteristiche di \acr{ext2} e derivati torneremo in
-sez.~\ref{sec:file_ext2}). È comunque caratteristica comune di tutti i
+sez.~\ref{sec:file_ext2}). È comunque caratteristica comune di tutti i
 filesystem per Unix, indipendentemente da come poi viene strutturata nei
 dettagli questa informazione, prevedere una divisione fra la lista degli
 \index{inode} inode e lo spazio a disposizione per i dati e le directory.
@@ -540,36 +540,36 @@ fig.~\ref{fig:file_filesys_detail}.
 \end{figure}
 
 Da fig.~\ref{fig:file_filesys_detail} si evidenziano alcune delle
-caratteristiche di base di un filesystem, sulle quali è bene porre attenzione
+caratteristiche di base di un filesystem, sulle quali è bene porre attenzione
 visto che sono fondamentali per capire il funzionamento delle funzioni che
 manipolano i file e le directory che tratteremo nel prossimo capitolo; in
-particolare è opportuno ricordare sempre che:
+particolare è opportuno ricordare sempre che:
 
 \begin{enumerate}
   
 \item L'\textit{inode} \index{inode} contiene tutte le informazioni (i
   cosiddetti \textsl{metadati}) riguardanti il file: il tipo di file, i
   permessi di accesso, le dimensioni, i puntatori ai blocchi fisici che
-  contengono i dati e così via. Le informazioni che la funzione \func{stat}
-  fornisce provengono dall'\textit{inode}; dentro una directory si troverà
+  contengono i dati e così via. Le informazioni che la funzione \func{stat}
+  fornisce provengono dall'\textit{inode}; dentro una directory si troverà
   solo il nome del file e il numero \index{inode} dell'\textit{inode} ad esso
-  associato, cioè quella che da qui in poi chiameremo una \textsl{voce} (come
+  associato, cioè quella che da qui in poi chiameremo una \textsl{voce} (come
   traduzione dell'inglese \textit{directory entry}, che non useremo anche per
   evitare confusione con le \textit{dentry} del kernel di cui si parlava in
   sez.~\ref{sec:file_vfs}).
   
-\item Come mostrato in fig.~\ref{fig:file_filesys_detail} si possono avere più
+\item Come mostrato in fig.~\ref{fig:file_filesys_detail} si possono avere più
   voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un
   contatore che contiene il numero di riferimenti che sono stati fatti ad esso
   (il cosiddetto \textit{link count}); solo quando questo contatore si annulla
   i dati del file vengono effettivamente rimossi dal disco. Per questo la
-  funzione per cancellare un file si chiama \func{unlink}, ed in realtà non
+  funzione per cancellare un file si chiama \func{unlink}, ed in realtà non
   cancella affatto i dati del file, ma si limita ad eliminare la relativa voce
   da una directory e decrementare il numero di riferimenti \index{inode}
   nell'\textit{inode}.
   
 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
-  nello stesso filesystem e non ci può essere una directory che contiene
+  nello stesso filesystem e non ci può essere una directory che contiene
   riferimenti ad \index{inode} \textit{inode} relativi ad altri filesystem.
   Questo limita l'uso del comando \cmd{ln} (che crea una nuova voce per un
   file esistente con la funzione \func{link}) al filesystem corrente.
@@ -577,16 +577,16 @@ particolare 
 \item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto
   del file non viene spostato fisicamente, viene semplicemente creata una
   nuova voce per \index{inode} l'\textit{inode} in questione e rimossa la
-  vecchia (questa è la modalità in cui opera normalmente il comando \cmd{mv}
+  vecchia (questa è la modalità in cui opera normalmente il comando \cmd{mv}
   attraverso la funzione \func{rename}). Questa operazione non modifica
   minimamente neanche l'\textit{inode} del file dato che non si opera su
   questo ma sulla directory che lo contiene.
 
 \item Gli \textit{inode} dei file, che contengono i \textsl{metadati} ed i
   blocchi di spazio disco, che contengono i dati, sono risorse indipendenti ed
-  in genere vengono gestite come tali anche dai diversi filesystem; è pertanto
-  possibile sia esaurire lo spazio disco (caso più comune) che lo spazio per
-  gli \textit{inode}, nel primo caso non sarà possibile allocare ulteriore
+  in genere vengono gestite come tali anche dai diversi filesystem; è pertanto
+  possibile sia esaurire lo spazio disco (caso più comune) che lo spazio per
+  gli \textit{inode}, nel primo caso non sarà possibile allocare ulteriore
   spazio, ma si potranno creare file (vuoti), nel secondo non si potranno
   creare nuovi file, ma si potranno estendere quelli che ci sono.
 
@@ -606,32 +606,32 @@ di \index{inode} inode.
   \label{fig:file_dirs_link}
 \end{figure}
 
-La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
-è referenziata dalla directory da cui si era partiti (in cui è inserita la
+La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
+è referenziata dalla directory da cui si era partiti (in cui è inserita la
 nuova voce che fa riferimento a \texttt{img}) e dalla voce ``\texttt{.}''  che
-è sempre inserita in ogni directory; questo vale sempre per ogni directory che
+è sempre inserita in ogni directory; questo vale sempre per ogni directory che
 non contenga a sua volta altre directory. Al contempo, la directory da cui si
-era partiti avrà un numero di riferimenti di almeno tre, in quanto adesso sarà
+era partiti avrà un numero di riferimenti di almeno tre, in quanto adesso sarà
 referenziata anche dalla voce ``\texttt{..}'' di \texttt{img}.
 
 
 \subsection{I filesystem di uso comune}
 \label{sec:file_ext2}
 
-Il filesystem standard più usato con Linux è il cosiddetto \textit{third
+Il filesystem standard più usato con Linux è il cosiddetto \textit{third
   extended filesystem}, identificato dalla sigla \acr{ext3}.\footnote{si fa
   riferimento al momento della stesura di questo paragrafo, l'inizio del
   2010.} Esso nasce come evoluzione del precedente \textit{second extended
   filesystem}, o \acr{ext2}, di cui eredita gran parte delle caratteristiche
 di base, per questo motivo parleremo anzitutto di questo, dato che molto di
-quanto diremo si applica anche ad \acr{ext3}. A partire dal kernel 2.6.XX è
+quanto diremo si applica anche ad \acr{ext3}. A partire dal kernel 2.6.XX è
 stato dichiarato stabile il nuovo filsesystem \textit{ext4}, ulteriore
 evoluzione di \textit{ext3} dotato di molte caratteristiche avanzate, che sta
 iniziando a sostituirlo gradualmente.
 
 Il filesystem \acr{ext2} nasce come filesystem nativo di Linux a partire dalle
 prime versioni del kernel e supporta tutte le caratteristiche di un filesystem
-standard Unix: è in grado di gestire nomi di file lunghi (256 caratteri,
+standard Unix: è in grado di gestire nomi di file lunghi (256 caratteri,
 estensibili a 1012) e supporta una dimensione massima dei file fino a 4~Tb. I
 successivi filesystem \acr{ext3} ed \acr{ext4} sono evoluzioni di questo
 filesystem, e sia pure con molti miglioramenti ed estensioni significative ne
@@ -653,13 +653,13 @@ le seguenti:
   di \acr{sgid} impostato (per una descrizione dettagliata del significato di
   questi termini si veda sez.~\ref{sec:file_access_control}), nel qual caso
   file e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
-\item l'amministratore può scegliere la dimensione dei blocchi del filesystem
-  in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
-  permettono un accesso più veloce, ma sprecano più spazio disco).
+\item l'amministratore può scegliere la dimensione dei blocchi del filesystem
+  in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
+  permettono un accesso più veloce, ma sprecano più spazio disco).
 \item il filesystem implementa link simbolici veloci, in cui il nome del file
-  non è salvato su un blocco, ma tenuto all'interno \index{inode} dell'inode
-  (evitando letture multiple e spreco di spazio), non tutti i nomi però
-  possono essere gestiti così per limiti di spazio (il limite è 60 caratteri).
+  non è salvato su un blocco, ma tenuto all'interno \index{inode} dell'inode
+  (evitando letture multiple e spreco di spazio), non tutti i nomi però
+  possono essere gestiti così per limiti di spazio (il limite è 60 caratteri).
 \item vengono supportati i file immutabili (che possono solo essere letti) per
   la protezione di file di configurazione sensibili, o file
   \textit{append-only} che possono essere aperti in scrittura solo per
@@ -667,9 +667,9 @@ le seguenti:
   log).
 \end{itemize}
 
-La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD: un
-filesystem è composto da un insieme di blocchi, la struttura generale è quella
-riportata in fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa
+La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD: un
+filesystem è composto da un insieme di blocchi, la struttura generale è quella
+riportata in fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa
 in gruppi di blocchi.\footnote{non si confonda questa definizione con
   quella riportata in fig.~\ref{fig:file_dirent_struct}; in quel caso si fa
   riferimento alla struttura usata in user space per riportare i dati
@@ -680,7 +680,7 @@ in gruppi di blocchi.\footnote{non si confonda questa definizione con
 
 Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
 filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
-una maggiore affidabilità e possibilità di recupero in caso di corruzione del
+una maggiore affidabilità e possibilità di recupero in caso di corruzione del
 superblock principale. L'utilizzo di raggruppamenti di blocchi ha inoltre
 degli effetti positivi nelle prestazioni dato che viene ridotta la distanza
 fra i dati e la tabella degli \index{inode} inode.
@@ -696,25 +696,25 @@ Le directory sono implementate come una \itindex{linked~list} \textit{linked
   list} con voci di dimensione variabile. Ciascuna voce della lista contiene
 il numero di inode \index{inode}, la sua lunghezza, il nome del file e la sua
 lunghezza, secondo lo schema in fig.~\ref{fig:file_ext2_dirs}; in questo modo
-è possibile implementare nomi per i file anche molto lunghi (fino a 1024
+è possibile implementare nomi per i file anche molto lunghi (fino a 1024
 caratteri) senza sprecare spazio disco.
 
 Con l'introduzione del filesystem \textit{ext3} sono state introdotte anche
-alcune modifiche strutturali, la principale di queste è quella che
-\textit{ext3} è un filesystem \textit{jounrnaled}, è cioè in grado di eseguire
+alcune modifiche strutturali, la principale di queste è quella che
+\textit{ext3} è un filesystem \textit{jounrnaled}, è cioè in grado di eseguire
 una registrazione delle operazioni di scrittura su un giornale (uno speciale
 file interno) in modo da poter garantire il ripristino della coerenza dei dati
-del filesystem\footnote{si noti bene che si è parlato di dati \textsl{del}
+del filesystem\footnote{si noti bene che si è parlato di dati \textsl{del}
   filesystem, non di dati \textsl{nel} filesystem, quello di cui viene
-  garantito un veloce ripristino è relativo ai dati della struttura interna
+  garantito un veloce ripristino è relativo ai dati della struttura interna
   del filesystem, non di eventuali dati contenuti nei file che potrebbero
   essere stati persi.} in brevissimo tempo in caso di interruzione improvvisa
 della corrente o di crollo del sistema che abbia causato una interruzione
 della scrittura dei dati sul disco.
 
 Oltre a questo \textit{ext3} introduce ulteriori modifiche volte a migliorare
-sia le prestazioni che la semplicità di gestione del filesystem, in
-particolare per le directory si è passato all'uso di alberi binari con
+sia le prestazioni che la semplicità di gestione del filesystem, in
+particolare per le directory si è passato all'uso di alberi binari con
 indicizzazione tramite hash al posto delle \textit{linked list}, ottenendo un
 forte guadagno di prestazioni in caso di directory contenenti un gran numero
 di file. 
diff --git a/filestd.tex b/filestd.tex
index 0232bc8..ce45b85 100644
--- a/filestd.tex
+++ b/filestd.tex
@@ -15,7 +15,7 @@
 Esamineremo in questo capitolo l'interfaccia standard ANSI C per i file,
 quella che viene comunemente detta interfaccia degli \textit{stream}.  Dopo
 una breve sezione introduttiva tratteremo le funzioni base per la gestione
-dell'input/output, mentre tratteremo le caratteristiche più avanzate
+dell'input/output, mentre tratteremo le caratteristiche più avanzate
 dell'interfaccia nell'ultima sezione.
 
 
@@ -26,7 +26,7 @@ Come visto in cap.~\ref{cha:file_unix_interface} le operazioni di I/O sui file
 sono gestibili a basso livello con l'interfaccia standard unix, che ricorre
 direttamente alle system call messe a disposizione dal kernel.
 
-Questa interfaccia però non provvede le funzionalità previste dallo standard
+Questa interfaccia però non provvede le funzionalità previste dallo standard
 ANSI C, che invece sono realizzate attraverso opportune funzioni di libreria,
 queste, insieme alle altre funzioni definite dallo standard, vengono a
 costituire il nucleo\footnote{queste funzioni sono state implementate la prima
@@ -39,7 +39,7 @@ costituire il nucleo\footnote{queste funzioni sono state implementate la prima
 
 \index{file!stream|(}
 
-Come più volte ribadito, l'interfaccia dei file descriptor è un'interfaccia di
+Come più volte ribadito, l'interfaccia dei file descriptor è un'interfaccia di
 basso livello, che non provvede nessuna forma di formattazione dei dati e
 nessuna forma di bufferizzazione per ottimizzare le operazioni di I/O.
 
@@ -49,20 +49,20 @@ dimensioni del blocco di dati (l'argomento \param{buf} di \func{read} e
 evidenziando come le prestazioni ottimali si ottengano a partire da dimensioni
 del buffer dei dati pari a quelle dei blocchi del filesystem (il valore dato
 dal campo \var{st\_blksize} di \struct{stat}), che di norma corrispondono alle
-dimensioni dei settori fisici in cui è suddiviso il disco.
+dimensioni dei settori fisici in cui è suddiviso il disco.
 
 Se il programmatore non si cura di effettuare le operazioni in blocchi di
 dimensioni adeguate, le prestazioni sono inferiori.  La caratteristica
-principale dell'interfaccia degli stream è che essa provvede da sola alla
+principale dell'interfaccia degli stream è che essa provvede da sola alla
 gestione dei dettagli della bufferizzazione e all'esecuzione delle operazioni
 di lettura e scrittura in blocchi di dimensioni appropriate all'ottenimento
 della massima efficienza.
 
 Per questo motivo l'interfaccia viene chiamata anche interfaccia dei
-\textit{file stream}, dato che non è più necessario doversi preoccupare
+\textit{file stream}, dato che non è più necessario doversi preoccupare
 dei dettagli della comunicazione con il tipo di hardware sottostante
 (come nel caso della dimensione dei blocchi del filesystem), ed un file
-può essere sempre considerato come composto da un flusso continuo (da
+può essere sempre considerato come composto da un flusso continuo (da
 cui il nome \textit{stream}) di dati.
 
 A parte i dettagli legati alla gestione delle operazioni di lettura e
@@ -79,7 +79,7 @@ sez.~\ref{sec:file_access_control} per il controllo di accesso.
 \label{sec:file_FILE}
 
 
-Per ragioni storiche la struttura di dati che rappresenta uno stream è stata
+Per ragioni storiche la struttura di dati che rappresenta uno stream è stata
 chiamata \type{FILE}, questi oggetti sono creati dalle funzioni di libreria e
 contengono tutte le informazioni necessarie a gestire le operazioni sugli
 stream, come la posizione corrente, lo stato del buffer e degli indicatori di
@@ -88,7 +88,7 @@ stato e di fine del file.
 Per questo motivo gli utenti non devono mai utilizzare direttamente o allocare
 queste strutture (che sono dei \index{tipo!opaco} \textsl{tipi opachi}) ma
 usare sempre puntatori del tipo \texttt{FILE *} ottenuti dalla libreria stessa
-(tanto che in certi casi il termine di puntatore a file è diventato sinonimo
+(tanto che in certi casi il termine di puntatore a file è diventato sinonimo
 di stream).  Tutte le funzioni della libreria che operano sui file accettano
 come argomenti solo variabili di questo tipo, che diventa accessibile
 includendo l'header file \file{stdio.h}.
@@ -104,36 +104,36 @@ questi tre stream sono identificabili attraverso dei nomi simbolici
 definiti nell'header \file{stdio.h} che sono:
 
 \begin{basedescript}{\desclabelwidth{3.0cm}}
-\item[\var{FILE *stdin}] Lo \textit{standard input} cioè lo stream da
+\item[\var{FILE *stdin}] Lo \textit{standard input} cioè lo stream da
   cui il processo riceve ordinariamente i dati in ingresso. Normalmente
-  è associato dalla shell all'input del terminale e prende i caratteri
+  è associato dalla shell all'input del terminale e prende i caratteri
   dalla tastiera.
-\item[\var{FILE *stdout}] Lo \textit{standard output} cioè lo stream su
-  cui il processo invia ordinariamente i dati in uscita. Normalmente è
+\item[\var{FILE *stdout}] Lo \textit{standard output} cioè lo stream su
+  cui il processo invia ordinariamente i dati in uscita. Normalmente è
   associato dalla shell all'output del terminale e scrive sullo schermo.
-\item[\var{FILE *stderr}] Lo \textit{standard error} cioè lo stream su
-  cui il processo è supposto inviare i messaggi di errore. Normalmente
-  anch'esso è associato dalla shell all'output del terminale e scrive
+\item[\var{FILE *stderr}] Lo \textit{standard error} cioè lo stream su
+  cui il processo è supposto inviare i messaggi di errore. Normalmente
+  anch'esso è associato dalla shell all'output del terminale e scrive
   sullo schermo.
 \end{basedescript}
 
 Nelle \acr{glibc} \var{stdin}, \var{stdout} e \var{stderr} sono effettivamente
 tre variabili di tipo \type{FILE}\texttt{ *} che possono essere usate come
-tutte le altre, ad esempio si può effettuare una redirezione dell'output di un
+tutte le altre, ad esempio si può effettuare una redirezione dell'output di un
 programma con il semplice codice: \includecodesnip{listati/redir_stdout.c} ma
 in altri sistemi queste variabili possono essere definite da macro, e se si
-hanno problemi di portabilità e si vuole essere sicuri, diventa opportuno
+hanno problemi di portabilità e si vuole essere sicuri, diventa opportuno
 usare la funzione \func{freopen}.
 
 
-\subsection{Le modalità di bufferizzazione}
+\subsection{Le modalità di bufferizzazione}
 \label{sec:file_buffering}
 
-La bufferizzazione è una delle caratteristiche principali dell'interfaccia
-degli stream; lo scopo è quello di ridurre al minimo il numero di system call
+La bufferizzazione è una delle caratteristiche principali dell'interfaccia
+degli stream; lo scopo è quello di ridurre al minimo il numero di system call
 (\func{read} o \func{write}) eseguite nelle operazioni di input/output. Questa
-funzionalità è assicurata automaticamente dalla libreria, ma costituisce anche
-uno degli aspetti più comunemente fraintesi, in particolare per quello che
+funzionalità è assicurata automaticamente dalla libreria, ma costituisce anche
+uno degli aspetti più comunemente fraintesi, in particolare per quello che
 riguarda l'aspetto della scrittura dei dati sul file.
 
 I caratteri che vengono scritti su di uno stream normalmente vengono
@@ -141,26 +141,26 @@ accumulati in un buffer e poi trasmessi in blocco\footnote{questa operazione
   viene usualmente chiamata \textsl{scaricamento} dei dati, dal termine
   inglese \textit{flush}.} tutte le volte che il buffer viene riempito, in
 maniera asincrona rispetto alla scrittura. Un comportamento analogo avviene
-anche in lettura (cioè dal file viene letto un blocco di dati, anche se ne
-sono richiesti una quantità inferiore), ma la cosa ovviamente ha rilevanza
+anche in lettura (cioè dal file viene letto un blocco di dati, anche se ne
+sono richiesti una quantità inferiore), ma la cosa ovviamente ha rilevanza
 inferiore, dato che i dati letti sono sempre gli stessi. In caso di scrittura
 invece, quando si ha un accesso contemporaneo allo stesso file (ad esempio da
 parte di un altro processo) si potranno vedere solo le parti effettivamente
 scritte, e non quelle ancora presenti nel buffer.
 
 Per lo stesso motivo, in tutte le situazioni in cui si sta facendo
-dell'input/output interattivo, bisognerà tenere presente le caratteristiche
-delle operazioni di scaricamento dei dati, poiché non è detto che ad una
+dell'input/output interattivo, bisognerà tenere presente le caratteristiche
+delle operazioni di scaricamento dei dati, poiché non è detto che ad una
 scrittura sullo stream corrisponda una immediata scrittura sul dispositivo (la
-cosa è particolarmente evidente quando con le operazioni di input/output su
+cosa è particolarmente evidente quando con le operazioni di input/output su
 terminale).
 
 Per rispondere ad esigenze diverse, lo standard definisce tre distinte
-modalità in cui può essere eseguita la bufferizzazione, delle quali
+modalità in cui può essere eseguita la bufferizzazione, delle quali
 occorre essere ben consapevoli, specie in caso di lettura e scrittura da
 dispositivi interattivi:
 \begin{itemize}
-\item \textit{unbuffered}: in questo caso non c'è bufferizzazione ed i
+\item \textit{unbuffered}: in questo caso non c'è bufferizzazione ed i
   caratteri vengono trasmessi direttamente al file non appena possibile
   (effettuando immediatamente una \func{write}).
 \item \textit{line buffered}: in questo caso i caratteri vengono
@@ -172,39 +172,39 @@ dispositivi interattivi:
 \end{itemize}
 
 Lo standard ANSI C specifica inoltre che lo standard output e lo
-standard input siano aperti in modalità \textit{fully buffered} quando
+standard input siano aperti in modalità \textit{fully buffered} quando
 non fanno riferimento ad un dispositivo interattivo, e che lo standard
-error non sia mai aperto in modalità \textit{fully buffered}.
+error non sia mai aperto in modalità \textit{fully buffered}.
 
 Linux, come BSD e SVr4, specifica il comportamento predefinito in maniera
-ancora più precisa, e cioè impone che lo standard error sia sempre
-\textit{unbuffered} (in modo che i messaggi di errore siano mostrati il più
+ancora più precisa, e cioè impone che lo standard error sia sempre
+\textit{unbuffered} (in modo che i messaggi di errore siano mostrati il più
 rapidamente possibile) e che standard input e standard output siano aperti in
-modalità \textit{line buffered} quando sono associati ad un terminale (od
-altro dispositivo interattivo) ed in modalità \textit{fully buffered}
+modalità \textit{line buffered} quando sono associati ad un terminale (od
+altro dispositivo interattivo) ed in modalità \textit{fully buffered}
 altrimenti.
 
 Il comportamento specificato per standard input e standard output vale anche
 per tutti i nuovi stream aperti da un processo; la selezione comunque avviene
-automaticamente, e la libreria apre lo stream nella modalità più opportuna a
+automaticamente, e la libreria apre lo stream nella modalità più opportuna a
 seconda del file o del dispositivo scelto.
 
-La modalità \textit{line buffered} è quella che necessita di maggiori
-chiarimenti e attenzioni per quel che concerne il suo funzionamento. Come già
+La modalità \textit{line buffered} è quella che necessita di maggiori
+chiarimenti e attenzioni per quel che concerne il suo funzionamento. Come già
 accennato nella descrizione, \emph{di norma} i dati vengono inviati al kernel
 alla ricezione di un carattere di \textsl{a capo} (\textit{newline}); questo
-non è vero in tutti i casi, infatti, dato che le dimensioni del buffer usato
-dalle librerie sono fisse, se le si eccedono si può avere uno scarico dei dati
+non è vero in tutti i casi, infatti, dato che le dimensioni del buffer usato
+dalle librerie sono fisse, se le si eccedono si può avere uno scarico dei dati
 anche prima che sia stato inviato un carattere di \textit{newline}.
 
 Un secondo punto da tenere presente, particolarmente quando si ha a che fare
-con I/O interattivo, è che quando si effettua una lettura da uno stream che
+con I/O interattivo, è che quando si effettua una lettura da uno stream che
 comporta l'accesso al kernel\footnote{questo vuol dire che lo stream da cui si
-  legge è in modalità \textit{unbuffered}.} viene anche eseguito lo scarico di
+  legge è in modalità \textit{unbuffered}.} viene anche eseguito lo scarico di
 tutti i buffer degli stream in scrittura.
 
 In sez.~\ref{sec:file_buffering_ctrl} vedremo come la libreria definisca delle
-opportune funzioni per controllare le modalità di bufferizzazione e lo scarico
+opportune funzioni per controllare le modalità di bufferizzazione e lo scarico
 dei dati.
 
 
@@ -223,7 +223,7 @@ corrente in uno stream.
 
 Le funzioni che si possono usare per aprire uno stream sono solo tre:
 \funcd{fopen}, \funcd{fdopen} e \funcd{freopen},\footnote{\func{fopen} e
-  \func{freopen} fanno parte dello standard ANSI C, \func{fdopen} è parte
+  \func{freopen} fanno parte dello standard ANSI C, \func{fdopen} è parte
   dello standard POSIX.1.} i loro prototipi sono:
 \begin{functions}
   \headdecl{stdio.h}
@@ -233,11 +233,11 @@ Le funzioni che si possono usare per aprire uno stream sono solo tre:
   Associa uno stream al file descriptor \param{fildes}.
   \funcdecl{FILE *freopen(const char *path, const char *mode, FILE *stream)}
   Apre il file specificato da \param{path} associandolo allo stream
-  specificato da \param{stream}, se questo è già aperto prima lo chiude.
+  specificato da \param{stream}, se questo è già aperto prima lo chiude.
   
   \bodydesc{Le funzioni ritornano un puntatore valido in caso di successo e
-    \val{NULL} in caso di errore, in tal caso \var{errno} assumerà il valore
-    ricevuto dalla funzione sottostante di cui è fallita l'esecuzione.
+    \val{NULL} in caso di errore, in tal caso \var{errno} assumerà il valore
+    ricevuto dalla funzione sottostante di cui è fallita l'esecuzione.
   
     Gli errori pertanto possono essere quelli di \func{malloc} per tutte
     e tre le funzioni, quelli \func{open} per \func{fopen}, quelli di
@@ -245,15 +245,15 @@ Le funzioni che si possono usare per aprire uno stream sono solo tre:
     \func{fclose} e \func{fflush} per \func{freopen}.}
 \end{functions}
 
-Normalmente la funzione che si usa per aprire uno stream è \func{fopen},
-essa apre il file specificato nella modalità specificata da
-\param{mode}, che è una stringa che deve iniziare con almeno uno dei
+Normalmente la funzione che si usa per aprire uno stream è \func{fopen},
+essa apre il file specificato nella modalità specificata da
+\param{mode}, che è una stringa che deve iniziare con almeno uno dei
 valori indicati in tab.~\ref{tab:file_fopen_mode} (sono possibili varie
 estensioni che vedremo in seguito).
 
-L'uso più comune di \func{freopen} è per redirigere uno dei tre file
+L'uso più comune di \func{freopen} è per redirigere uno dei tre file
 standard (vedi sez.~\ref{sec:file_std_stream}): il file \param{path} viene
-associato a \param{stream} e se questo è uno stream già aperto viene
+associato a \param{stream} e se questo è uno stream già aperto viene
 preventivamente chiuso.
 
 Infine \func{fdopen} viene usata per associare uno stream ad un file
@@ -271,16 +271,16 @@ aperti con le funzioni delle librerie standard del C.
     \hline
     \hline
     \texttt{r} & Il file viene aperto, l'accesso viene posto in sola
-                 lettura, lo stream è posizionato all'inizio del file.\\
+                 lettura, lo stream è posizionato all'inizio del file.\\
     \texttt{r+}& Il file viene aperto, l'accesso viene posto in lettura e
-                 scrittura, lo stream è posizionato all'inizio del file.\\
+                 scrittura, lo stream è posizionato all'inizio del file.\\
 %    \hline
     \texttt{w} & Il file viene aperto e troncato a lunghezza nulla (o
                  creato se non esiste), l'accesso viene posto in sola
-                 scrittura, lo  stream è posizionato all'inizio del file.\\
+                 scrittura, lo  stream è posizionato all'inizio del file.\\
     \texttt{w+}& Il file viene aperto e troncato a lunghezza nulla (o
                  creato se non esiste), l'accesso viene posto in scrittura e
-                 lettura, lo stream è posizionato all'inizio del file.\\
+                 lettura, lo stream è posizionato all'inizio del file.\\
 %    \hline
     \texttt{a} & Il file viene aperto (o creato se non esiste) in
                  \itindex{append~mode} \textit{append mode}, l'accesso viene
@@ -289,44 +289,44 @@ aperti con le funzioni delle librerie standard del C.
                  \itindex{append~mode} \textit{append mode}, l'accesso viene
                  posto in lettura e scrittura.\\
     \hline
-    \texttt{b} & Specifica che il file è binario, non ha alcun effetto. \\
-    \texttt{x} & L'apertura fallisce se il file esiste già. \\
+    \texttt{b} & Specifica che il file è binario, non ha alcun effetto. \\
+    \texttt{x} & L'apertura fallisce se il file esiste già. \\
     \hline
   \end{tabular}
-  \caption{Modalità di apertura di uno stream dello standard ANSI C che
+  \caption{Modalità di apertura di uno stream dello standard ANSI C che
     sono sempre presenti in qualunque sistema POSIX.}
   \label{tab:file_fopen_mode}
 \end{table}
 
-In realtà lo standard ANSI C prevede un totale di 15 possibili valori
+In realtà lo standard ANSI C prevede un totale di 15 possibili valori
 diversi per \param{mode}, ma in tab.~\ref{tab:file_fopen_mode} si sono
-riportati solo i sei valori effettivi, ad essi può essere aggiunto pure
+riportati solo i sei valori effettivi, ad essi può essere aggiunto pure
 il carattere \texttt{b} (come ultimo carattere o nel mezzo agli altri per
 le stringhe di due caratteri) che in altri sistemi operativi serve a
 distinguere i file binari dai file di testo; in un sistema POSIX questa
 distinzione non esiste e il valore viene accettato solo per
-compatibilità, ma non ha alcun effetto.
+compatibilità, ma non ha alcun effetto.
 
 Le \acr{glibc} supportano alcune estensioni, queste devono essere sempre
 indicate dopo aver specificato il \param{mode} con uno dei valori di
 tab.~\ref{tab:file_fopen_mode}. L'uso del carattere \texttt{x} serve per
-evitare di sovrascrivere un file già esistente (è analoga all'uso
-dell'opzione \const{O\_EXCL} in \func{open}), se il file specificato già
+evitare di sovrascrivere un file già esistente (è analoga all'uso
+dell'opzione \const{O\_EXCL} in \func{open}), se il file specificato già
 esiste e si aggiunge questo carattere a \param{mode} la \func{fopen}
 fallisce. 
 
 Un'altra estensione serve a supportare la localizzazione, quando si
 aggiunge a \param{mode} una stringa della forma \verb|",ccs=STRING"| il
-valore \verb|STRING| è considerato il nome di una codifica dei caratteri
+valore \verb|STRING| è considerato il nome di una codifica dei caratteri
 e \func{fopen} marca il file per l'uso dei caratteri estesi e abilita le
 opportune funzioni di conversione in lettura e scrittura.
 
 Nel caso si usi \func{fdopen} i valori specificati da \param{mode} devono
-essere compatibili con quelli con cui il file descriptor è stato aperto.
+essere compatibili con quelli con cui il file descriptor è stato aperto.
 Inoltre i modi \cmd{w} e \cmd{w+} non troncano il file. La posizione nello
 stream viene impostata a quella corrente nel file descriptor, e le variabili
 di errore e di fine del file (vedi sez.~\ref{sec:file_io}) sono cancellate. Il
-file non viene duplicato e verrà chiuso alla chiusura dello stream.
+file non viene duplicato e verrà chiuso alla chiusura dello stream.
 
 I nuovi file saranno creati secondo quanto visto in
 sez.~\ref{sec:file_ownership_management} ed avranno i permessi di accesso
@@ -335,54 +335,54 @@ impostati al valore
 \val{0666}) modificato secondo il valore di \itindex{umask} \textit{umask} per
 il processo (si veda sez.~\ref{sec:file_perm_management}).
 
-In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è
+In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è
 di mezzo una bufferizzazione; per questo motivo lo standard ANSI C
 richiede che ci sia un'operazione di posizionamento fra un'operazione
 di output ed una di input o viceversa (eccetto il caso in cui l'input ha
-incontrato la fine del file), altrimenti una lettura può ritornare anche
+incontrato la fine del file), altrimenti una lettura può ritornare anche
 il risultato di scritture precedenti l'ultima effettuata. 
 
-Per questo motivo è una buona pratica (e talvolta necessario) far seguire ad
+Per questo motivo è una buona pratica (e talvolta necessario) far seguire ad
 una scrittura una delle funzioni \func{fflush}, \func{fseek}, \func{fsetpos} o
 \func{rewind} prima di eseguire una rilettura; viceversa nel caso in cui si
 voglia fare una scrittura subito dopo aver eseguito una lettura occorre prima
 usare una delle funzioni \func{fseek}, \func{fsetpos} o \func{rewind}. Anche
-un'operazione nominalmente nulla come \code{fseek(file, 0, SEEK\_CUR)} è
+un'operazione nominalmente nulla come \code{fseek(file, 0, SEEK\_CUR)} è
 sufficiente a garantire la sincronizzazione.
 
-Una volta aperto lo stream, si può cambiare la modalità di bufferizzazione
-(si veda sez.~\ref{sec:file_buffering_ctrl}) fintanto che non si è effettuato
+Una volta aperto lo stream, si può cambiare la modalità di bufferizzazione
+(si veda sez.~\ref{sec:file_buffering_ctrl}) fintanto che non si è effettuato
 alcuna operazione di I/O sul file.
 
-Uno stream viene chiuso con la funzione \funcd{fclose} il cui prototipo è:
+Uno stream viene chiuso con la funzione \funcd{fclose} il cui prototipo è:
 \begin{prototype}{stdio.h}{int fclose(FILE *stream)}
   Chiude lo stream \param{stream}. 
   
   \bodydesc{Restituisce 0 in caso di successo e \val{EOF} in caso di errore,
     nel qual caso imposta \var{errno} a \errval{EBADF} se il file descriptor
-    indicato da \param{stream} non è valido, o uno dei valori specificati
-    dalla sottostante funzione che è fallita (\func{close}, \func{write} o
+    indicato da \param{stream} non è valido, o uno dei valori specificati
+    dalla sottostante funzione che è fallita (\func{close}, \func{write} o
     \func{fflush}).}
 \end{prototype}
 
 La funzione effettua lo scarico di tutti i dati presenti nei buffer di uscita
 e scarta tutti i dati in ingresso; se era stato allocato un buffer per lo
-stream questo verrà rilasciato. La funzione effettua lo scarico solo per i
+stream questo verrà rilasciato. La funzione effettua lo scarico solo per i
 dati presenti nei buffer in user space usati dalle \acr{glibc}; se si vuole
-essere sicuri che il kernel forzi la scrittura su disco occorrerà effettuare
+essere sicuri che il kernel forzi la scrittura su disco occorrerà effettuare
 una \func{sync} (vedi sez.~\ref{sec:file_sync}).
 
 Linux supporta anche una altra funzione, \funcd{fcloseall}, come estensione
 GNU implementata dalle \acr{glibc}, accessibile avendo definito
-\macro{\_GNU\_SOURCE}, il suo prototipo è:
+\macro{\_GNU\_SOURCE}, il suo prototipo è:
 \begin{prototype}{stdio.h}{int fcloseall(void)}
   Chiude tutti gli stream. 
   
   \bodydesc{Restituisce 0 se non ci sono errori ed \val{EOF} altrimenti.}
 \end{prototype}
 \noindent la funzione esegue lo scarico dei dati bufferizzati in uscita
-e scarta quelli in ingresso, chiudendo tutti i file. Questa funzione è
-provvista solo per i casi di emergenza, quando si è verificato un errore
+e scarta quelli in ingresso, chiudendo tutti i file. Questa funzione è
+provvista solo per i casi di emergenza, quando si è verificato un errore
 ed il programma deve essere abortito, ma si vuole compiere qualche altra
 operazione dopo aver chiuso i file e prima di uscire (si ricordi quanto
 visto in sez.~\ref{sec:proc_exit}).
@@ -391,10 +391,10 @@ visto in sez.~\ref{sec:proc_exit}).
 \subsection{Lettura e scrittura su uno stream}
 \label{sec:file_io}
 
-Una delle caratteristiche più utili dell'interfaccia degli stream è la
+Una delle caratteristiche più utili dell'interfaccia degli stream è la
 ricchezza delle funzioni disponibili per le operazioni di lettura e
-scrittura sui file. Sono infatti previste ben tre diverse modalità
-modalità di input/output non formattato:
+scrittura sui file. Sono infatti previste ben tre diverse modalità
+modalità di input/output non formattato:
 \begin{enumerate*}
 \item\textsl{binario} in cui legge/scrive un blocco di dati alla
   volta, vedi sez.~\ref{sec:file_binary_io}.
@@ -404,10 +404,10 @@ modalit
 \item\textsl{di linea} in cui si legge/scrive una linea alla volta (terminata
   dal carattere di newline \verb|'\n'|), vedi sez.~\ref{sec:file_line_io}.
 \end{enumerate*}
-ed inoltre la modalità di input/output formattato.
+ed inoltre la modalità di input/output formattato.
 
 A differenza dell'interfaccia dei file descriptor, con gli stream il
-raggiungimento della fine del file è considerato un errore, e viene
+raggiungimento della fine del file è considerato un errore, e viene
 notificato come tale dai valori di uscita delle varie funzioni. Nella
 maggior parte dei casi questo avviene con la restituzione del valore
 intero (di tipo \ctyp{int}) \val{EOF}\footnote{la costante deve essere
@@ -419,7 +419,7 @@ che si appoggiano a delle system call, esse non impostano direttamente la
 variabile \var{errno}, che mantiene il valore impostato dalla system call che
 ha riportato l'errore.
 
-Siccome la condizione di end-of-file è anch'essa segnalata come errore, nasce
+Siccome la condizione di end-of-file è anch'essa segnalata come errore, nasce
 il problema di come distinguerla da un errore effettivo; basarsi solo sul
 valore di ritorno della funzione e controllare il valore di \var{errno}
 infatti non basta, dato che quest'ultimo potrebbe essere stato impostato in
@@ -428,7 +428,7 @@ funzionamento di \var{errno}).
 
 Per questo motivo tutte le implementazioni delle librerie standard
 mantengono per ogni stream almeno due flag all'interno dell'oggetto
-\type{FILE}, il flag di \textit{end-of-file}, che segnala che si è
+\type{FILE}, il flag di \textit{end-of-file}, che segnala che si è
 raggiunta la fine del file in lettura, e quello di errore, che segnala
 la presenza di un qualche errore nelle operazioni di input/output;
 questi due flag possono essere riletti dalle funzioni \funcd{feof} e
@@ -444,17 +444,17 @@ questi due flag possono essere riletti dalle funzioni \funcd{feof} e
     i relativi flag sono impostati.}
 \end{functions}
 \noindent si tenga presente comunque che la lettura di questi flag segnala
-soltanto che c'è stato un errore, o che si è raggiunta la fine del file in una
+soltanto che c'è stato un errore, o che si è raggiunta la fine del file in una
 qualunque operazione sullo stream, il controllo quindi deve essere effettuato
 ogni volta che si chiama una funzione di libreria.
 
 Entrambi i flag (di errore e di end-of-file) possono essere cancellati usando
-la funzione \funcd{clearerr}, il cui prototipo è:
+la funzione \funcd{clearerr}, il cui prototipo è:
 \begin{prototype}{stdio.h}{void clearerr(FILE *stream)}
   Cancella i flag di errore ed end-of-file di \param{stream}. 
 \end{prototype}
 \noindent in genere si usa questa funzione una volta che si sia identificata e
-corretta la causa di un errore per evitare di mantenere i flag attivi, così da
+corretta la causa di un errore per evitare di mantenere i flag attivi, così da
 poter rilevare una successiva ulteriore condizione di errore. Di questa
 funzione esiste una analoga \func{clearerr\_unlocked} che non esegue il blocco
 dello stream (vedi sez.~\ref{sec:file_stream_thread}).
@@ -463,10 +463,10 @@ dello stream (vedi sez.~\ref{sec:file_stream_thread}).
 \subsection{Input/output binario}
 \label{sec:file_binary_io}
 
-La prima modalità di input/output non formattato ricalca quella della
+La prima modalità di input/output non formattato ricalca quella della
 interfaccia dei file descriptor, e provvede semplicemente la scrittura e la
-lettura dei dati da un buffer verso un file e viceversa. In generale questa è
-la modalità che si usa quando si ha a che fare con dati non formattati. Le due
+lettura dei dati da un buffer verso un file e viceversa. In generale questa è
+la modalità che si usa quando si ha a che fare con dati non formattati. Le due
 funzioni che si usano per l'I/O binario sono \funcd{fread} ed \funcd{fwrite};
 i loro prototipi sono:
 \begin{functions}
@@ -488,36 +488,36 @@ i loro prototipi sono:
 
 In genere si usano queste funzioni quando si devono trasferire su file
 blocchi di dati binari in maniera compatta e veloce; un primo caso di uso
-tipico è quello in cui si salva un vettore (o un certo numero dei suoi
+tipico è quello in cui si salva un vettore (o un certo numero dei suoi
 elementi) con una chiamata del tipo:
 \includecodesnip{listati/WriteVect.c}
 in questo caso devono essere specificate le dimensioni di ciascun
 elemento ed il numero di quelli che si vogliono scrivere. Un secondo
-caso è invece quello in cui si vuole trasferire su file una struttura;
-si avrà allora una chiamata tipo:
+caso è invece quello in cui si vuole trasferire su file una struttura;
+si avrà allora una chiamata tipo:
 \includecodesnip{listati/WriteStruct.c}
 in cui si specifica la dimensione dell'intera struttura ed un solo
 elemento. 
 
-In realtà quello che conta nel trasferimento dei dati sono le dimensioni
+In realtà quello che conta nel trasferimento dei dati sono le dimensioni
 totali, che sono sempre pari al prodotto \code{size * nelem}; la sola
-differenza è che le funzioni non ritornano il numero di byte scritti,
+differenza è che le funzioni non ritornano il numero di byte scritti,
 ma il numero di elementi.
 
 La funzione \func{fread} legge sempre un numero intero di elementi, se
 incontra la fine del file l'oggetto letto parzialmente viene scartato
 (lo stesso avviene in caso di errore). In questo caso la posizione dello
 stream viene impostata alla fine del file (e non a quella corrispondente
-alla quantità di dati letti).
+alla quantità di dati letti).
 
 In caso di errore (o fine del file per \func{fread}) entrambe le
 funzioni restituiscono il numero di oggetti effettivamente letti o
-scritti, che sarà inferiore a quello richiesto. Contrariamente a quanto
+scritti, che sarà inferiore a quello richiesto. Contrariamente a quanto
 avviene per i file descriptor, questo segnala una condizione di errore e
-occorrerà usare \func{feof} e \func{ferror} per stabilire la natura del
+occorrerà usare \func{feof} e \func{ferror} per stabilire la natura del
 problema.
 
-Benché queste funzioni assicurino la massima efficienza per il
+Benché queste funzioni assicurino la massima efficienza per il
 salvataggio dei dati, i dati memorizzati attraverso di esse presentano
 lo svantaggio di dipendere strettamente dalla piattaforma di sviluppo
 usata ed in genere possono essere riletti senza problemi solo dallo
@@ -525,15 +525,15 @@ stesso programma che li ha prodotti.
 
 Infatti diversi compilatori possono eseguire ottimizzazioni diverse delle
 strutture dati e alcuni compilatori (come il \cmd{gcc}) possono anche
-scegliere se ottimizzare l'occupazione di spazio, impacchettando più
-strettamente i dati, o la velocità inserendo opportuni \textit{padding} per
+scegliere se ottimizzare l'occupazione di spazio, impacchettando più
+strettamente i dati, o la velocità inserendo opportuni \textit{padding} per
 l'allineamento dei medesimi generando quindi output binari diversi. Inoltre
-altre incompatibilità si possono presentare quando entrano in gioco differenze
-di architettura hardware, come la dimensione del bus o la modalità di
+altre incompatibilità si possono presentare quando entrano in gioco differenze
+di architettura hardware, come la dimensione del bus o la modalità di
 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
+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
 eventuali differenze.
@@ -562,7 +562,7 @@ sez.~\ref{sec:file_stream_thread} per i dettagli), i loro prototipi sono:
 \subsection{Input/output a caratteri}
 \label{sec:file_char_io}
 
-La seconda modalità di input/output è quella a caratteri, in cui si
+La seconda modalità di input/output è quella a caratteri, in cui si
 trasferisce un carattere alla volta.  Le funzioni per la lettura a
 caratteri sono tre, \funcd{fgetc}, \funcd{getc} e \funcd{getchar}, i
 rispettivi prototipi sono:
@@ -570,57 +570,57 @@ rispettivi prototipi sono:
   \headdecl{stdio.h} 
 
   \funcdecl{int getc(FILE *stream)} Legge un byte da \param{stream} e lo
-  restituisce come intero. In genere è implementata come una macro. 
+  restituisce come intero. In genere è implementata come una macro. 
   
   \funcdecl{int fgetc(FILE *stream)} Legge un byte da \param{stream} e lo
-  restituisce come intero. È sempre una funzione.
+  restituisce come intero. È sempre una funzione.
   
   \funcdecl{int getchar(void)} Equivalente a \code{getc(stdin)}.
   
   \bodydesc{Tutte queste funzioni leggono un byte alla volta, che viene
     restituito come intero; in caso di errore o fine del file il valore
-    di ritorno è \val{EOF}.}
+    di ritorno è \val{EOF}.}
 \end{functions}
 
 A parte \func{getchar}, che si usa in genere per leggere un carattere da
 tastiera, le altre due funzioni sono sostanzialmente equivalenti. La
-differenza è che \func{getc} è ottimizzata al massimo e normalmente
+differenza è che \func{getc} è ottimizzata al massimo e normalmente
 viene implementata con una macro, per cui occorre stare attenti a cosa
-le si passa come argomento, infatti \param{stream} può essere valutato
-più volte nell'esecuzione, e non viene passato in copia con il
+le si passa come argomento, infatti \param{stream} può essere valutato
+più volte nell'esecuzione, e non viene passato in copia con il
 meccanismo visto in sez.~\ref{sec:proc_var_passing}; per questo motivo se
 si passa un'espressione si possono avere effetti indesiderati.
 
-Invece \func{fgetc} è assicurata essere sempre una funzione, per questo motivo
-la sua esecuzione normalmente è più lenta per via dell'overhead della
-chiamata, ma è altresì possibile ricavarne l'indirizzo, che può essere passato
+Invece \func{fgetc} è assicurata essere sempre una funzione, per questo motivo
+la sua esecuzione normalmente è più lenta per via dell'overhead della
+chiamata, ma è altresì possibile ricavarne l'indirizzo, che può essere passato
 come argomento ad un altra funzione (e non si hanno i problemi accennati in
 precedenza nel tipo di argomento).
 
 Le tre funzioni restituiscono tutte un \ctyp{unsigned char} convertito
 ad \ctyp{int} (si usa \ctyp{unsigned char} in modo da evitare
-l'espansione del segno). In questo modo il valore di ritorno è sempre
+l'espansione del segno). In questo modo il valore di ritorno è sempre
 positivo, tranne in caso di errore o fine del file.
 
 Nelle estensioni GNU che provvedono la localizzazione sono definite tre
 funzioni equivalenti alle precedenti, \funcd{getwc}, \funcd{fgetwc} e
 \funcd{getwchar}, che invece di un carattere di un byte restituiscono un
-carattere in formato esteso (cioè di tipo \ctyp{wint\_t}), il loro prototipo
-è:
+carattere in formato esteso (cioè di tipo \ctyp{wint\_t}), il loro prototipo
+è:
 \begin{functions}
   \headdecl{stdio.h} 
   \headdecl{wchar.h} 
   
   \funcdecl{wint\_t getwc(FILE *stream)} Legge un carattere esteso da
-  \param{stream}. In genere è implementata come una macro.
+  \param{stream}. In genere è implementata come una macro.
   
   \funcdecl{wint\_t fgetwc(FILE *stream)} Legge un carattere esteso da
-  \param{stream}. È una sempre una funzione.
+  \param{stream}. È una sempre una funzione.
   
   \funcdecl{wint\_t getwchar(void)} Equivalente a \code{getwc(stdin)}.
   
   \bodydesc{Tutte queste funzioni leggono un carattere alla volta, in
-    caso di errore o fine del file il valore di ritorno è \const{WEOF}.}
+    caso di errore o fine del file il valore di ritorno è \const{WEOF}.}
 \end{functions}
 
 Per scrivere un carattere si possono usare tre funzioni, analoghe alle
@@ -630,32 +630,32 @@ loro prototipi sono:
   \headdecl{stdio.h} 
   
   \funcdecl{int putc(int c, FILE *stream)} Scrive il carattere \param{c}
-  su \param{stream}. In genere è implementata come una macro.
+  su \param{stream}. In genere è implementata come una macro.
   
   \funcdecl{int fputc(int c, FILE *stream)} Scrive il carattere \param{c} su
-  \param{stream}. È una sempre una funzione.
+  \param{stream}. È una sempre una funzione.
   
   \funcdecl{int putchar(int c)} Equivalente a \code{putc(stdout)}.
   
   \bodydesc{Le funzioni scrivono sempre un carattere alla volta, il cui
     valore viene restituito in caso di successo; in caso di errore o
-    fine del file il valore di ritorno è \val{EOF}.}
+    fine del file il valore di ritorno è \val{EOF}.}
 \end{functions}
 
 Tutte queste funzioni scrivono sempre un byte alla volta, anche se prendono
 come argomento un \ctyp{int} (che pertanto deve essere ottenuto con un cast da
-un \ctyp{unsigned char}). Anche il valore di ritorno è sempre un intero; in
-caso di errore o fine del file il valore di ritorno è \val{EOF}.
+un \ctyp{unsigned char}). Anche il valore di ritorno è sempre un intero; in
+caso di errore o fine del file il valore di ritorno è \val{EOF}.
 
 Come nel caso dell'I/O binario con \func{fread} e \func{fwrite} le \acr{glibc}
 provvedono come estensione, per ciascuna delle funzioni precedenti,
-un'ulteriore funzione, il cui nome è ottenuto aggiungendo un
-\code{\_unlocked}, che esegue esattamente le stesse operazioni, evitando però
+un'ulteriore funzione, il cui nome è ottenuto aggiungendo un
+\code{\_unlocked}, che esegue esattamente le stesse operazioni, evitando però
 il lock implicito dello stream.
 
-Per compatibilità con SVID sono inoltre provviste anche due funzioni,
+Per compatibilità con SVID sono inoltre provviste anche due funzioni,
 \funcd{getw} e \funcd{putw}, da usare per leggere e scrivere una \textit{word}
-(cioè due byte in una volta); i loro prototipi sono:
+(cioè due byte in una volta); i loro prototipi sono:
 \begin{functions}
   \headdecl{stdio.h} 
   
@@ -668,21 +668,21 @@ Per compatibilit
 \end{functions}
 
 Le funzioni leggono e scrivono una \textit{word} di due byte, usando comunque
-una variabile di tipo \ctyp{int}; il loro uso è deprecato in favore dell'uso
-di \func{fread} e \func{fwrite}, in quanto non è possibile distinguere il
+una variabile di tipo \ctyp{int}; il loro uso è deprecato in favore dell'uso
+di \func{fread} e \func{fwrite}, in quanto non è possibile distinguere il
 valore -1 da una condizione di errore che restituisce \val{EOF}.
 
-Uno degli usi più frequenti dell'input/output a caratteri è nei programmi di
+Uno degli usi più frequenti dell'input/output a caratteri è nei programmi di
 \textit{parsing} in cui si analizza il testo; in questo contesto diventa utile
 poter analizzare il carattere successivo da uno stream senza estrarlo
-effettivamente (la tecnica è detta \textit{peeking ahead}) in modo che il
+effettivamente (la tecnica è detta \textit{peeking ahead}) in modo che il
 programma possa regolarsi avendo dato una \textsl{sbirciatina} a quello che
 viene dopo.
 
-Nel nostro caso questo tipo di comportamento può essere realizzato prima
-leggendo il carattere, e poi rimandandolo indietro, cosicché ridiventi
+Nel nostro caso questo tipo di comportamento può essere realizzato prima
+leggendo il carattere, e poi rimandandolo indietro, cosicché ridiventi
 disponibile per una lettura successiva; la funzione che inverte la
-lettura si chiama \funcd{ungetc} ed il suo prototipo è:
+lettura si chiama \funcd{ungetc} ed il suo prototipo è:
 \begin{prototype}{stdio.h}{int ungetc(int c, FILE *stream)}
   Rimanda indietro il carattere \param{c}, con un cast a \ctyp{unsigned
     char}, sullo stream \param{stream}.
@@ -690,24 +690,24 @@ lettura si chiama \funcd{ungetc} ed il suo prototipo 
   \bodydesc{La funzione ritorna \param{c} in caso di successo e
   \val{EOF} in caso di errore.}
 \end{prototype}
-\noindent benché lo standard ANSI C preveda che l'operazione possa
+\noindent benché lo standard ANSI C preveda che l'operazione possa
 essere ripetuta per un numero arbitrario di caratteri, alle
-implementazioni è richiesto di garantire solo un livello; questo è
+implementazioni è richiesto di garantire solo un livello; questo è
 quello che fa la \acr{glibc}, che richiede che avvenga un'altra
 operazione fra due \func{ungetc} successive.
 
-Non è necessario che il carattere che si manda indietro sia l'ultimo che
-si è letto, e non è necessario neanche avere letto nessun carattere
-prima di usare \func{ungetc}, ma di norma la funzione è intesa per
+Non è necessario che il carattere che si manda indietro sia l'ultimo che
+si è letto, e non è necessario neanche avere letto nessun carattere
+prima di usare \func{ungetc}, ma di norma la funzione è intesa per
 essere usata per rimandare indietro l'ultimo carattere letto.
 
 Nel caso \param{c} sia un \val{EOF} la funzione non fa nulla, e
-restituisce sempre \val{EOF}; così si può usare \func{ungetc} anche
+restituisce sempre \val{EOF}; così si può usare \func{ungetc} anche
 con il risultato di una lettura alla fine del file.
 
-Se si è alla fine del file si può comunque rimandare indietro un
-carattere, il flag di end-of-file verrà automaticamente cancellato
-perché c'è un nuovo carattere disponibile che potrà essere riletto
+Se si è alla fine del file si può comunque rimandare indietro un
+carattere, il flag di end-of-file verrà automaticamente cancellato
+perché c'è un nuovo carattere disponibile che potrà essere riletto
 successivamente.
 
 Infine si tenga presente che \func{ungetc} non altera il contenuto del
@@ -720,10 +720,10 @@ scartati.
 \subsection{Input/output di linea}
 \label{sec:file_line_io}
 
-La terza ed ultima modalità di input/output non formattato è quella di linea,
-in cui si legge o si scrive una riga alla volta; questa è una modalità molto
-usata per l'I/O da terminale, ma è anche quella che presenta le
-caratteristiche più controverse.
+La terza ed ultima modalità di input/output non formattato è quella di linea,
+in cui si legge o si scrive una riga alla volta; questa è una modalità molto
+usata per l'I/O da terminale, ma è anche quella che presenta le
+caratteristiche più controverse.
 
 Le funzioni previste dallo standard ANSI C per leggere una linea sono
 sostanzialmente due, \funcd{gets} e \funcd{fgets}, i cui rispettivi
@@ -747,32 +747,32 @@ dallo standard input \func{gets}) di una linea di caratteri (terminata dal
 carattere \textit{newline}, \verb|'\n'|, quello mappato sul tasto di ritorno a
 capo della tastiera), ma \func{gets} sostituisce \verb|'\n'| con uno zero,
 mentre \func{fgets} aggiunge uno zero dopo il \textit{newline}, che resta
-dentro la stringa. Se la lettura incontra la fine del file (o c'è un errore)
+dentro la stringa. Se la lettura incontra la fine del file (o c'è un errore)
 viene restituito un \val{NULL}, ed il buffer \param{buf} non viene toccato.
-L'uso di \func{gets} è deprecato e deve essere assolutamente evitato; la
+L'uso di \func{gets} è deprecato e deve essere assolutamente evitato; la
 funzione infatti non controlla il numero di byte letti, per cui nel caso la
-stringa letta superi le dimensioni del buffer, si avrà un
+stringa letta superi le dimensioni del buffer, si avrà un
 \itindex{buffer~overflow} \textit{buffer overflow}, con sovrascrittura della
-memoria del processo adiacente al buffer.\footnote{questa tecnica è spiegata
+memoria del processo adiacente al buffer.\footnote{questa tecnica è spiegata
   in dettaglio e con molta efficacia nell'ormai famoso articolo di Aleph1
   \cite{StS}.}
 
-Questa è una delle vulnerabilità più sfruttate per guadagnare accessi non
+Questa è una delle vulnerabilità più sfruttate per guadagnare accessi non
 autorizzati al sistema (i cosiddetti \textit{exploit}), basta infatti inviare
 una stringa sufficientemente lunga ed opportunamente forgiata per
 sovrascrivere gli indirizzi di ritorno nello \itindex{stack} \textit{stack}
 (supposto che la \func{gets} sia stata chiamata da una subroutine), in modo da
 far ripartire l'esecuzione nel codice inviato nella stringa stessa (in genere
-uno \textit{shell code} cioè una sezione di programma che lancia una shell).
+uno \textit{shell code} cioè una sezione di programma che lancia una shell).
 
 La funzione \func{fgets} non ha i precedenti problemi di \func{gets} in quanto
-prende in input la dimensione del buffer \param{size}, che non verrà mai
+prende in input la dimensione del buffer \param{size}, che non verrà mai
 ecceduta in lettura. La funzione legge fino ad un massimo di \param{size}
 caratteri (newline compreso), ed aggiunge uno zero di terminazione; questo
 comporta che la stringa possa essere al massimo di \code{size-1} caratteri.  Se
 la linea eccede la dimensione del buffer verranno letti solo \code{size-1}
-caratteri, ma la stringa sarà sempre terminata correttamente con uno zero
-finale; sarà possibile leggere i rimanenti caratteri in una chiamata
+caratteri, ma la stringa sarà sempre terminata correttamente con uno zero
+finale; sarà possibile leggere i rimanenti caratteri in una chiamata
 successiva.
 
 Per la scrittura di una linea lo standard ANSI C prevede altre due
@@ -792,11 +792,11 @@ rispettivi prototipi sono:
 \end{functions}
 
 Dato che in questo caso si scrivono i dati in uscita \func{puts} non ha i
-problemi di \func{gets} ed è in genere la forma più immediata per scrivere
+problemi di \func{gets} ed è in genere la forma più immediata per scrivere
 messaggi sullo standard output; la funzione prende una stringa terminata da
 uno zero ed aggiunge automaticamente il ritorno a capo. La differenza con
-\func{fputs} (a parte la possibilità di specificare un file diverso da
-\var{stdout}) è che quest'ultima non aggiunge il newline, che deve essere
+\func{fputs} (a parte la possibilità di specificare un file diverso da
+\var{stdout}) è che quest'ultima non aggiunge il newline, che deve essere
 previsto esplicitamente.
 
 Come per le analoghe funzioni di input/output a caratteri, anche per l'I/O di
@@ -817,26 +817,26 @@ loro prototipi sono:
     caso di errore o fine del file.}
 \end{functions}
 
-Il comportamento di queste due funzioni è identico a quello di \func{fgets} e
+Il comportamento di queste due funzioni è identico a quello di \func{fgets} e
 \func{fputs}, a parte il fatto che tutto (numero di caratteri massimo,
-terminatore della stringa, newline) è espresso in termini di caratteri estesi
-anziché di normali caratteri ASCII.
+terminatore della stringa, 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
 illustrate finora (eccetto \func{gets} e \func{puts}), che eseguono
-esattamente le stesse operazioni delle loro equivalenti, evitando però il lock
+esattamente le stesse operazioni delle loro equivalenti, evitando però il lock
 implicito dello stream (vedi sez.~\ref{sec:file_stream_thread}). Come per le
 altre forma di I/O, dette funzioni hanno lo stesso nome della loro analoga
 normale, con l'aggiunta dell'estensione \code{\_unlocked}.
 
 Come abbiamo visto, le funzioni di lettura per l'input/output di linea
-previste dallo standard ANSI C presentano svariati inconvenienti. Benché
-\func{fgets} non abbia i gravissimi problemi di \func{gets}, può
+previste dallo standard ANSI C presentano svariati inconvenienti. Benché
+\func{fgets} non abbia i gravissimi problemi di \func{gets}, può
 comunque dare risultati ambigui se l'input contiene degli zeri; questi
 infatti saranno scritti sul buffer di uscita e la stringa in output
-apparirà come più corta dei byte effettivamente letti. Questa è una
-condizione che è sempre possibile controllare (deve essere presente un
+apparirà come più corta dei byte effettivamente letti. Questa è una
+condizione che è sempre possibile controllare (deve essere presente un
 newline prima della effettiva conclusione della stringa presente nel
 buffer), ma a costo di una complicazione ulteriore della logica del
 programma. Lo stesso dicasi quando si deve gestire il caso di stringa
@@ -847,7 +847,7 @@ 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 \file{stdio.h}. La
 prima delle due, \funcd{getline}, serve per leggere una linea terminata da un
-newline, esattamente allo stesso modo di \func{fgets}, il suo prototipo è:
+newline, esattamente allo stesso modo di \func{fgets}, il suo prototipo è:
 \begin{prototype}{stdio.h}
   {ssize\_t getline(char **buffer, size\_t *n, FILE *stream)} Legge una linea
   dal file \param{stream} copiandola sul buffer indicato da \param{buffer}
@@ -863,22 +863,22 @@ La funzione permette di eseguire una lettura senza doversi preoccupare della
 eventuale lunghezza eccessiva della stringa da leggere. Essa prende come primo
 argomento l'indirizzo del puntatore al buffer su cui si vuole copiare la
 linea. Quest'ultimo \emph{deve} essere stato allocato in precedenza con una
-\func{malloc} (non si può passare l'indirizzo di un puntatore ad una variabile
+\func{malloc} (non si può passare l'indirizzo di un puntatore ad una variabile
 locale); come secondo argomento la funzione vuole l'indirizzo della variabile
 contenente le dimensioni del buffer suddetto.
 
-Se il buffer di destinazione è sufficientemente ampio la stringa viene scritta
+Se il buffer di destinazione è sufficientemente ampio la stringa viene scritta
 subito, altrimenti il buffer viene allargato usando \func{realloc} e la nuova
 dimensione ed il nuovo puntatore vengono restituiti indietro (si noti infatti
 come per entrambi gli argomenti si siano usati dei
 \itindex{value~result~argument} \textit{value result argument}, passando dei
-puntatori anziché i valori delle variabili, secondo la tecnica spiegata in
+puntatori anziché i valori delle variabili, secondo la tecnica spiegata in
 sez.~\ref{sec:proc_var_passing}).
 
 Se si passa alla funzione l'indirizzo di un puntatore impostato a \val{NULL} e
-\var{*n} è zero, la funzione provvede da sola all'allocazione della memoria
+\var{*n} è zero, la funzione provvede da sola all'allocazione della memoria
 necessaria a contenere la linea. In tutti i casi si ottiene dalla funzione un
-puntatore all'inizio del testo della linea letta. Un esempio di codice può
+puntatore all'inizio del testo della linea letta. Un esempio di codice può
 essere il seguente: 
 \includecodesnip{listati/getline.c} 
 e per evitare  \itindex{memory~leak} \textit{memory leak} occorre ricordarsi di
@@ -888,33 +888,33 @@ Il valore di ritorno della funzione indica il numero di caratteri letti
 dallo stream (quindi compreso il newline, ma non lo zero di
 terminazione); questo permette anche di distinguere eventuali zeri letti
 dallo stream da quello inserito dalla funzione per terminare la linea.
-Se si è alla fine del file e non si è potuto leggere nulla o c'è stato
+Se si è alla fine del file e non si è potuto leggere nulla o c'è stato
 un errore la funzione restituisce -1.
 
-La seconda estensione GNU è una generalizzazione di \func{getline} per
+La seconda estensione GNU è una generalizzazione di \func{getline} per
 poter usare come separatore un carattere qualsiasi, la funzione si
-chiama \funcd{getdelim} ed il suo prototipo è:
+chiama \funcd{getdelim} ed il suo prototipo è:
 \begin{prototype}{stdio.h}
 {ssize\_t getdelim(char **buffer, size\_t *n, int delim, FILE *stream)} 
   Identica a \func{getline} solo che usa \param{delim} al posto del
   carattere di newline come separatore di linea.
 \end{prototype}
 
-Il comportamento di \func{getdelim} è identico a quello di \func{getline} (che
-può essere implementata da questa passando \verb|'\n'| come valore di
+Il comportamento di \func{getdelim} è identico a quello di \func{getline} (che
+può essere implementata da questa passando \verb|'\n'| come valore di
 \param{delim}).
 
 
 \subsection{L'input/output formattato}
 \label{sec:file_formatted_io}
 
-L'ultima modalità di input/output è quella formattata, che è una delle
-caratteristiche più utilizzate delle librerie standard del C; in genere questa
-è la modalità in cui si esegue normalmente l'output su terminale poiché
+L'ultima modalità di input/output è quella formattata, che è una delle
+caratteristiche più utilizzate delle librerie standard del C; in genere questa
+è la modalità in cui si esegue normalmente l'output su terminale poiché
 permette di stampare in maniera facile e veloce dati, tabelle e messaggi.
 
 L'output formattato viene eseguito con una delle 13 funzioni della famiglia
-\func{printf}; le tre più usate sono \funcd{printf}, \funcd{fprintf} e
+\func{printf}; le tre più usate sono \funcd{printf}, \funcd{fprintf} e
 \funcd{sprintf}, i cui prototipi sono:
 \begin{functions}
   \headdecl{stdio.h} 
@@ -933,24 +933,24 @@ L'output formattato viene eseguito con una delle 13 funzioni della famiglia
 \end{functions}
 \noindent le prime due servono per stampare su file (lo standard output o
 quello specificato) la terza permette di stampare su una stringa, in genere
-l'uso di \func{sprintf} è sconsigliato in quanto è possibile, se non si ha la
+l'uso di \func{sprintf} è sconsigliato in quanto è possibile, se non si ha la
 sicurezza assoluta sulle dimensioni del risultato della stampa, eccedere le
 dimensioni di \param{str}, con conseguente sovrascrittura di altre variabili e
 possibili \itindex{buffer~overflow} \textit{buffer overflow}; per questo
 motivo si consiglia l'uso dell'alternativa \funcd{snprintf}, il cui prototipo
-è:
+è:
 \begin{prototype}{stdio.h}
 {snprintf(char *str, size\_t size, const char *format, ...)} 
-  Identica a \func{sprintf}, ma non scrive su \param{str} più di
+  Identica a \func{sprintf}, ma non scrive su \param{str} più di
   \param{size} caratteri.
 \end{prototype}
 
-La parte più complessa delle funzioni di scrittura formattata è il formato
+La parte più complessa delle funzioni di scrittura formattata è il formato
 della stringa \param{format} che indica le conversioni da fare, e da cui
 deriva anche il numero degli argomenti che dovranno essere passati a seguire
 (si noti come tutte queste funzioni siano \index{variadic} \textit{variadic},
 prendendo un numero di argomenti variabile che dipende appunto da quello che
-si è specificato in \param{format}).
+si è specificato in \param{format}).
 
 \begin{table}[htb]
   \centering
@@ -978,7 +978,7 @@ si 
                               lettere minuscole e maiuscole.\\
    \cmd{\%g}, 
    \cmd{\%G} &\ctyp{double} & Stampano un numero in virgola mobile con la
-                              notazione più appropriate delle due precedenti,
+                              notazione più appropriate delle due precedenti,
                               rispettivamente con lettere minuscole e
                               maiuscole.\\
    \cmd{\%a}, 
@@ -996,7 +996,7 @@ si 
   \label{tab:file_format_spec}
 \end{table}
 
-La stringa è costituita da caratteri normali (tutti eccetto \texttt{\%}), che
+La stringa è costituita da caratteri normali (tutti eccetto \texttt{\%}), che
 vengono passati invariati all'output, e da direttive di conversione, in cui
 devono essere sempre presenti il carattere \texttt{\%}, che introduce la
 direttiva, ed uno degli specificatori di conversione (riportati in
@@ -1011,7 +1011,7 @@ tab.~\ref{tab:file_format_spec}) che la conclude.
     \hline
     \hline
     \val{\#} & Chiede la conversione in forma alternativa. \\
-    \val{0}  & La conversione è riempita con zeri alla sinistra del valore.\\
+    \val{0}  & La conversione è riempita con zeri alla sinistra del valore.\\
     \val{-}  & La conversione viene allineata a sinistra sul bordo del campo.\\
     \val{' '}& Mette uno spazio prima di un numero con segno di valore 
                positivo.\\
@@ -1024,7 +1024,7 @@ tab.~\ref{tab:file_format_spec}) che la conclude.
 
 Il formato di una direttiva di conversione prevede una serie di possibili
 elementi opzionali oltre al \cmd{\%} e allo specificatore di conversione. In
-generale essa è sempre del tipo:
+generale essa è sempre del tipo:
 \begin{center}
 \begin{verbatim}
 % [n. parametro $] [flag] [[larghezza] [. precisione]] [tipo] conversione
@@ -1032,11 +1032,11 @@ generale essa 
 \end{center}
 in cui tutti i valori tranne il \val{\%} e lo specificatore di conversione
 sono opzionali (e per questo sono indicati fra parentesi quadre); si possono
-usare più elementi opzionali, nel qual caso devono essere specificati in
+usare più elementi opzionali, nel qual caso devono essere specificati in
 questo ordine:
 \begin{itemize*}
 \item uno specificatore del parametro da usare (terminato da un \val{\$}),
-\item uno o più flag (i cui valori possibili sono riassunti in
+\item uno o più flag (i cui valori possibili sono riassunti in
   tab.~\ref{tab:file_format_flag}) che controllano il formato di stampa della
   conversione,
 \item uno specificatore di larghezza (un numero decimale), eventualmente
@@ -1059,18 +1059,18 @@ manuale di \func{printf} e nella documentazione delle \acr{glibc}.
     \hline
     \hline
     \cmd{hh} & Una conversione intera corrisponde a un \ctyp{char} con o senza
-               segno, o il puntatore per il numero dei parametri \cmd{n} è di 
+               segno, o il puntatore per il numero dei parametri \cmd{n} è di 
                tipo \ctyp{char}.\\
     \cmd{h}  & Una conversione intera corrisponde a uno \ctyp{short} con o 
                senza segno, o il puntatore per il numero dei parametri \cmd{n}
-               è di tipo \ctyp{short}.\\
+               è di tipo \ctyp{short}.\\
     \cmd{l}  & Una conversione intera corrisponde a un \ctyp{long} con o 
                senza segno, o il puntatore per il numero dei parametri \cmd{n}
-               è di tipo \ctyp{long}, o il carattere o la stringa seguenti
+               è di tipo \ctyp{long}, o il carattere o la stringa seguenti
                sono in formato esteso.\\ 
     \cmd{ll} & Una conversione intera corrisponde a un \ctyp{long long} con o 
                senza segno, o il puntatore per il numero dei parametri \cmd{n}
-               è di tipo \ctyp{long long}.\\
+               è di tipo \ctyp{long long}.\\
     \cmd{L}  & Una conversione in virgola mobile corrisponde a un
                \ctyp{double}.\\
     \cmd{q}  & Sinonimo di \cmd{ll}.\\
@@ -1109,17 +1109,17 @@ sez.~\ref{sec:proc_variadic}), sono \funcd{vprintf}, \funcd{vfprintf} e
 \noindent con queste funzioni diventa possibile selezionare gli argomenti che
 si vogliono passare ad una funzione di stampa, passando direttamente la lista
 tramite l'argomento \param{ap}. Per poter far questo ovviamente la lista degli
-argomenti dovrà essere opportunamente trattata (l'argomento è esaminato in
+argomenti dovrà essere opportunamente trattata (l'argomento è esaminato in
 sez.~\ref{sec:proc_variadic}), e dopo l'esecuzione della funzione l'argomento
-\param{ap} non sarà più utilizzabile (in generale dovrebbe essere eseguito un
-\code{va\_end(ap)} ma in Linux questo non è necessario). 
+\param{ap} non sarà più utilizzabile (in generale dovrebbe essere eseguito un
+\code{va\_end(ap)} ma in Linux questo non è necessario). 
 
 Come per \func{sprintf} anche per \func{vsprintf} esiste una analoga
 \funcd{vsnprintf} che pone un limite sul numero di caratteri che vengono
 scritti sulla stringa di destinazione:
 \begin{prototype}{stdio.h}
 {vsnprintf(char *str, size\_t size, const char *format, va\_list ap)} 
-  Identica a \func{vsprintf}, ma non scrive su \param{str} più di
+  Identica a \func{vsprintf}, ma non scrive su \param{str} più di
   \param{size} caratteri.
 \end{prototype}
 \noindent in modo da evitare possibili \itindex{buffer~overflow} buffer
@@ -1147,24 +1147,24 @@ sono:
 \end{functions}
 
 Entrambe le funzioni prendono come argomento \param{strptr} che deve essere
-l'indirizzo di un puntatore ad una stringa di caratteri, in cui verrà
+l'indirizzo di un puntatore ad una stringa di caratteri, in cui verrà
 restituito (si ricordi quanto detto in sez.~\ref{sec:proc_var_passing} a
 proposito dei \itindex{value~result~argument} \textit{value result argument})
 l'indirizzo della stringa allocata automaticamente dalle funzioni. Occorre
 inoltre ricordarsi di invocare \func{free} per liberare detto puntatore quando
-la stringa non serve più, onde evitare \itindex{memory~leak} \textit{memory
+la stringa non serve più, onde evitare \itindex{memory~leak} \textit{memory
   leak}.
 
 Infine una ulteriore estensione GNU definisce le due funzioni \func{dprintf} e
 \func{vdprintf}, che prendono un file descriptor al posto dello stream. Altre
 estensioni permettono di scrivere con caratteri estesi. Anche queste funzioni,
-il cui nome è generato dalle precedenti funzioni aggiungendo una \texttt{w}
+il cui nome è generato dalle precedenti funzioni aggiungendo una \texttt{w}
 davanti a \texttt{print}, sono trattate in dettaglio nella documentazione delle
 \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
-famiglia \func{scanf}; fra queste le tre più importanti sono \funcd{scanf},
+famiglia \func{scanf}; fra queste le tre più importanti sono \funcd{scanf},
 \funcd{fscanf} e \funcd{sscanf}, i cui prototipi sono:
 \begin{functions}
   \headdecl{stdio.h} \funcdecl{int scanf(const char *format, ...)} Esegue una
@@ -1180,7 +1180,7 @@ famiglia \func{scanf}; fra queste le tre pi
   
   \bodydesc{Le funzioni ritornano il numero di elementi assegnati. Questi
     possono essere in numero inferiore a quelli specificati, ed anche zero.
-    Quest'ultimo valore significa che non si è trovata corrispondenza. In caso
+    Quest'ultimo valore significa che non si è trovata corrispondenza. In caso
     di errore o fine del file viene invece restituito \val{EOF}.}
 \end{functions}
 \noindent e come per le analoghe funzioni di scrittura esistono le relative
@@ -1188,14 +1188,14 @@ famiglia \func{scanf}; fra queste le tre pi
 lista di argomenti.
 
 Tutte le funzioni della famiglia delle \func{scanf} vogliono come argomenti i
-puntatori alle variabili che dovranno contenere le conversioni; questo è un
-primo elemento di disagio in quanto è molto facile dimenticarsi di questa
+puntatori alle variabili che dovranno contenere le conversioni; questo è un
+primo elemento di disagio in quanto è molto facile dimenticarsi di questa
 caratteristica.
 
 Le funzioni leggono i caratteri dallo stream (o dalla stringa) di input ed
 eseguono un confronto con quanto indicato in \param{format}, la sintassi di
-questo argomento è simile a quella usata per l'analogo di \func{printf}, ma ci
-sono varie differenze.  Le funzioni di input infatti sono più orientate verso
+questo argomento è simile a quella usata per l'analogo di \func{printf}, ma ci
+sono varie differenze.  Le funzioni di input infatti sono più orientate verso
 la lettura di testo libero che verso un input formattato in campi fissi. Uno
 spazio in \param{format} corrisponde con un numero qualunque di caratteri di
 separazione (che possono essere spazi, tabulatori, virgole ecc.), mentre
@@ -1210,19 +1210,19 @@ sia in grado di effettuare una delle conversioni richieste) la scansione viene
 interrotta immediatamente e la funzione ritorna lasciando posizionato lo
 stream al primo carattere che non corrisponde.
 
-Data la notevole complessità di uso di queste funzioni, che richiedono molta
+Data la notevole complessità di uso di queste funzioni, che richiedono molta
 cura nella definizione delle corrette stringhe di formato e sono facilmente
-soggette ad errori, e considerato anche il fatto che è estremamente macchinoso
+soggette ad errori, e considerato anche il fatto che è estremamente macchinoso
 recuperare in caso di fallimento nelle corrispondenze, l'input formattato non
-è molto usato. In genere infatti quando si ha a che fare con un input
+è molto usato. In genere infatti quando si ha a che fare con un input
 relativamente semplice si preferisce usare l'input di linea ed effettuare
 scansione e conversione di quanto serve direttamente con una delle funzioni di
-conversione delle stringhe; se invece il formato è più complesso diventa più
+conversione delle stringhe; se invece il formato è più complesso diventa più
 facile utilizzare uno strumento come \cmd{flex}\footnote{il programma
-  \cmd{flex}, è una implementazione libera di \cmd{lex} un generatore di
-  analizzatori lessicali. Per i dettagli si può fare riferimento al manuale
+  \cmd{flex}, è una implementazione libera di \cmd{lex} un generatore di
+  analizzatori lessicali. Per i dettagli si può fare riferimento al manuale
   \cite{flex}.} per generare un analizzatore lessicale o il
-\cmd{bison}\footnote{il programma \cmd{bison} è un clone del generatore di
+\cmd{bison}\footnote{il programma \cmd{bison} è un clone del generatore di
   parser \cmd{yacc}, maggiori dettagli possono essere trovati nel relativo
   manuale \cite{bison}.} per generare un parser.
 
@@ -1230,22 +1230,22 @@ facile utilizzare uno strumento come \cmd{flex}\footnote{il programma
 \subsection{Posizionamento su uno stream}
 \label{sec:file_fseek}
 
-Come per i file descriptor anche per gli stream è possibile spostarsi
+Come per i file descriptor anche per gli stream è possibile spostarsi
 all'interno di un file per effettuare operazioni di lettura o scrittura in un
 punto prestabilito; sempre che l'operazione di riposizionamento sia supportata
-dal file sottostante lo stream, quando cioè si ha a che fare con quello che
+dal file sottostante lo stream, quando cioè si ha a che fare con quello che
 viene detto un file ad \textsl{accesso casuale}.\footnote{dato che in un
   sistema Unix esistono vari tipi di file, come le fifo ed i
-  \index{file!di~dispositivo} file di dispositivo, non è scontato che questo
+  \index{file!di~dispositivo} file di dispositivo, non è scontato che questo
   sia sempre vero.}
 
-In GNU/Linux ed in generale in ogni sistema unix-like la posizione nel file è
+In GNU/Linux ed in generale in ogni sistema unix-like la posizione nel file è
 espressa da un intero positivo, rappresentato dal tipo \type{off\_t}, il
-problema è che alcune delle funzioni usate per il riposizionamento sugli
+problema è che alcune delle funzioni usate per il riposizionamento sugli
 stream originano dalle prime versioni di Unix, in cui questo tipo non era
-ancora stato definito, e che in altri sistemi non è detto che la posizione su
+ancora stato definito, e che in altri sistemi non è detto che la posizione su
 un file venga sempre rappresentata con il numero di caratteri dall'inizio (ad
-esempio in VMS può essere rappresentata come numero di record, più l'offset
+esempio in VMS può essere rappresentata come numero di record, più l'offset
 rispetto al record corrente).
 
 Tutto questo comporta la presenza di diverse funzioni che eseguono
@@ -1263,9 +1263,9 @@ stream sono \funcd{fseek} e \funcd{rewind} i cui prototipi sono:
   all'inizio del file.
 \end{functions}
 
-L'uso di \func{fseek} è del tutto analogo a quello di \func{lseek} per i file
+L'uso di \func{fseek} è del tutto analogo a quello di \func{lseek} per i file
 descriptor, e gli argomenti, a parte il tipo, hanno lo stesso significato; in
-particolare \param{whence} assume gli stessi valori già visti in
+particolare \param{whence} assume gli stessi valori già visti in
 sez.~\ref{sec:file_lseek}.  La funzione restituisce 0 in caso di successo e -1
 in caso di errore.  La funzione \func{rewind} riporta semplicemente la
 posizione corrente all'inizio dello stream, ma non esattamente equivalente ad
@@ -1273,13 +1273,13 @@ una \code{fseek(stream, 0L, SEEK\_SET)} in quanto vengono cancellati anche i
 flag di errore e fine del file.
 
 Per ottenere la posizione corrente si usa invece la funzione \funcd{ftell}, il
-cui prototipo è:
+cui prototipo è:
 \begin{prototype}{stdio.h}{long ftell(FILE *stream)} 
   Legge la posizione attuale nello stream \param{stream}.
   
   \bodydesc{La funzione restituisce la posizione corrente, o -1 in caso
-    di fallimento, che può esser dovuto sia al fatto che il file non
-    supporta il riposizionamento che al fatto che la posizione non può
+    di fallimento, che può esser dovuto sia al fatto che il file non
+    supporta il riposizionamento che al fatto che la posizione non può
     essere espressa con un \ctyp{long int}}
 \end{prototype}
 \noindent la funzione restituisce la posizione come numero di byte
@@ -1287,7 +1287,7 @@ dall'inizio dello stream.
 
 Queste funzioni esprimono tutte la posizione nel file come un \ctyp{long int}.
 Dato che (ad esempio quando si usa un filesystem indicizzato a 64 bit) questo
-può non essere possibile lo standard POSIX ha introdotto le nuove funzioni
+può non essere possibile lo standard POSIX ha introdotto le nuove funzioni
 \funcd{fgetpos} e \funcd{fsetpos}, che invece usano il nuovo tipo
 \type{fpos\_t}, ed i cui prototipi sono:
 \begin{functions}
@@ -1306,10 +1306,10 @@ pu
 In Linux, a partire dalle glibc 2.1, sono presenti anche le due funzioni
 \func{fseeko} e \func{ftello}, che sono assolutamente identiche alle
 precedenti \func{fseek} e \func{ftell} ma hanno argomenti di tipo
-\type{off\_t} anziché di tipo \ctyp{long int}. Dato che \ctyp{long} è nella
+\type{off\_t} anziché di tipo \ctyp{long int}. Dato che \ctyp{long} è nella
 gran parte dei casi un intero a 32 bit, questo diventa un problema quando la
 posizione sul file viene espressa con un valore a 64 bit come accade nei
-sistemi più moderni.
+sistemi più moderni.
 
 
 
@@ -1318,7 +1318,7 @@ sistemi pi
 
 In questa sezione esamineremo alcune funzioni avanzate che permettono di
 eseguire operazioni particolari sugli stream, come leggerne gli attributi,
-controllarne le modalità di bufferizzazione, gestire direttamente i lock
+controllarne le modalità di bufferizzazione, gestire direttamente i lock
 impliciti per la programmazione \itindex{thread} \textit{multi-thread}.
 
 
@@ -1327,9 +1327,9 @@ impliciti per la programmazione \itindex{thread} \textit{multi-thread}.
 
 Al contrario di quanto avviene con i file descriptor, le librerie standard del
 C non prevedono nessuna funzione come la \func{fcntl} per il controllo degli
-attributi dei file. Però, dato che ogni stream si appoggia ad un file
-descriptor, si può usare la funzione \funcd{fileno} per ottenere quest'ultimo,
-il prototipo della funzione è:
+attributi dei file. Però, dato che ogni stream si appoggia ad un file
+descriptor, si può usare la funzione \funcd{fileno} per ottenere quest'ultimo,
+il prototipo della funzione è:
 \begin{prototype}{stdio.h}{int fileno(FILE *stream)}
   Legge il file descriptor sottostante lo stream \param{stream}.
   
@@ -1340,16 +1340,16 @@ il prototipo della funzione 
 \noindent ed in questo modo diventa possibile usare direttamente \func{fcntl}.
 
 Questo permette di accedere agli attributi del file descriptor sottostante lo
-stream, ma non ci dà nessuna informazione riguardo alle proprietà dello stream
-medesimo.  Le \acr{glibc} però supportano alcune estensioni derivate da
+stream, ma non ci dà nessuna informazione riguardo alle proprietà dello stream
+medesimo.  Le \acr{glibc} però supportano alcune estensioni derivate da
 Solaris, che permettono di ottenere informazioni utili.
 
-Ad esempio in certi casi può essere necessario sapere se un certo stream è
-accessibile in lettura o scrittura. In genere questa informazione non è
-disponibile, e si deve ricordare come il file è stato aperto. La cosa può
+Ad esempio in certi casi può essere necessario sapere se un certo stream è
+accessibile in lettura o scrittura. In genere questa informazione non è
+disponibile, e si deve ricordare come il file è stato aperto. La cosa può
 essere complessa se le operazioni vengono effettuate in una subroutine, che a
-questo punto necessiterà di informazioni aggiuntive rispetto al semplice
-puntatore allo stream; questo può essere evitato con le due funzioni
+questo punto necessiterà di informazioni aggiuntive rispetto al semplice
+puntatore allo stream; questo può essere evitato con le due funzioni
 \funcd{\_\_freadable} e \funcd{\_\_fwritable} i cui prototipi sono:
 \begin{functions}
   \headdecl{stdio\_ext.h}
@@ -1362,25 +1362,25 @@ puntatore allo stream; questo pu
 \end{functions}
 \noindent che permettono di ottenere questa informazione.
 
-La conoscenza dell'ultima operazione effettuata su uno stream aperto è utile
+La conoscenza dell'ultima operazione effettuata su uno stream aperto è utile
 in quanto permette di trarre conclusioni sullo stato del buffer e del suo
 contenuto. Altre due funzioni, \funcd{\_\_freading} e \funcd{\_\_fwriting}
-servono a tale scopo, il loro prototipo è:
+servono a tale scopo, il loro prototipo è:
 \begin{functions}
   \headdecl{stdio\_ext.h}
   \funcdecl{int \_\_freading(FILE *stream)}
-  Restituisce un valore diverso da zero se \param{stream} è aperto in sola
-  lettura o se l'ultima operazione è stata di lettura.
+  Restituisce un valore diverso da zero se \param{stream} è aperto in sola
+  lettura o se l'ultima operazione è stata di lettura.
 
   \funcdecl{int \_\_fwriting(FILE *stream)}  
-  Restituisce un valore diverso da zero se \param{stream} è aperto in sola
-  scrittura o se l'ultima operazione è stata di scrittura.
+  Restituisce un valore diverso da zero se \param{stream} è aperto in sola
+  scrittura o se l'ultima operazione è stata di scrittura.
 \end{functions}
 
-Le due funzioni permettono di determinare di che tipo è stata l'ultima
+Le due funzioni permettono di determinare di che tipo è stata l'ultima
 operazione eseguita su uno stream aperto in lettura/scrittura; ovviamente se
-uno stream è aperto in sola lettura (o sola scrittura) la modalità dell'ultima
-operazione è sempre determinata; l'unica ambiguità è quando non sono state
+uno stream è aperto in sola lettura (o sola scrittura) la modalità dell'ultima
+operazione è sempre determinata; l'unica ambiguità è quando non sono state
 ancora eseguite operazioni, in questo caso le funzioni rispondono come se una
 operazione ci fosse comunque stata.
 
@@ -1390,18 +1390,18 @@ operazione ci fosse comunque stata.
 
 Come accennato in sez.~\ref{sec:file_buffering} le librerie definiscono una
 serie di funzioni che permettono di controllare il comportamento degli stream;
-se non si è specificato nulla, la modalità di buffering viene decisa
+se non si è specificato nulla, la modalità di buffering viene decisa
 autonomamente sulla base del tipo di file sottostante, ed i buffer vengono
 allocati automaticamente.
 
-Però una volta che si sia aperto lo stream (ma prima di aver compiuto
-operazioni su di esso) è possibile intervenire sulle modalità di buffering; la
-funzione che permette di controllare la bufferizzazione è \funcd{setvbuf}, il
-suo prototipo è:
+Però una volta che si sia aperto lo stream (ma prima di aver compiuto
+operazioni su di esso) è possibile intervenire sulle modalità di buffering; la
+funzione che permette di controllare la bufferizzazione è \funcd{setvbuf}, il
+suo prototipo è:
 \begin{prototype}{stdio.h}{int setvbuf(FILE *stream, char *buf, int mode, 
     size\_t size)}
   
-  Imposta la bufferizzazione dello stream \param{stream} nella modalità
+  Imposta la bufferizzazione dello stream \param{stream} nella modalità
   indicata da \param{mode}, usando \param{buf} come buffer di lunghezza
   \param{size}.
   
@@ -1410,27 +1410,27 @@ suo prototipo 
 \end{prototype}
 
 La funzione permette di controllare tutti gli aspetti della bufferizzazione;
-l'utente può specificare un buffer da usare al posto di quello allocato dal
+l'utente può specificare un buffer da usare al posto di quello allocato dal
 sistema passandone alla funzione l'indirizzo in \param{buf} e la dimensione in
 \param{size}. 
 
 Ovviamente se si usa un buffer specificato dall'utente questo deve essere
 stato allocato e rimanere disponibile per tutto il tempo in cui si opera sullo
 stream. In genere conviene allocarlo con \func{malloc} e disallocarlo dopo la
-chiusura del file; ma fintanto che il file è usato all'interno di una
-funzione, può anche essere usata una variabile automatica. In \file{stdio.h} è
+chiusura del file; ma fintanto che il file è usato all'interno di una
+funzione, può anche essere usata una variabile automatica. In \file{stdio.h} è
 definita la macro \const{BUFSIZ}, che indica le dimensioni generiche del
 buffer di uno stream; queste vengono usate dalla funzione \func{setbuf}.  Non
-è detto però che tale dimensione corrisponda sempre al valore ottimale (che
-può variare a seconda del dispositivo).
+è detto però che tale dimensione corrisponda sempre al valore ottimale (che
+può variare a seconda del dispositivo).
 
-Dato che la procedura di allocazione manuale è macchinosa, comporta dei rischi
+Dato che la procedura di allocazione manuale è macchinosa, comporta dei rischi
 (come delle scritture accidentali sul buffer) e non assicura la scelta delle
-dimensioni ottimali, è sempre meglio lasciare allocare il buffer alle funzioni
+dimensioni ottimali, è sempre meglio lasciare allocare il buffer alle funzioni
 di libreria, che sono in grado di farlo in maniera ottimale e trasparente
 all'utente (in quanto la deallocazione avviene automaticamente). Inoltre
 siccome alcune implementazioni usano parte del buffer per mantenere delle
-informazioni di controllo, non è detto che le dimensioni dello stesso
+informazioni di controllo, non è detto che le dimensioni dello stesso
 coincidano con quelle su cui viene effettuato l'I/O.
 
 \begin{table}[htb]
@@ -1438,7 +1438,7 @@ coincidano con quelle su cui viene effettuato l'I/O.
   \footnotesize
     \begin{tabular}[c]{|l|l|}
       \hline
-      \textbf{Valore} & \textbf{Modalità} \\
+      \textbf{Valore} & \textbf{Modalità} \\
       \hline
       \hline
       \const{\_IONBF} & \textit{unbuffered}\\
@@ -1447,16 +1447,16 @@ coincidano con quelle su cui viene effettuato l'I/O.
       \hline
     \end{tabular}
     \caption{Valori dell'argomento \param{mode} di \func{setvbuf} 
-      per l'impostazione delle modalità di bufferizzazione.}
+      per l'impostazione delle modalità di bufferizzazione.}
   \label{tab:file_stream_buf_mode}
 \end{table}
 
 Per evitare che \func{setvbuf} imposti il buffer basta passare un valore
-\val{NULL} per \param{buf} e la funzione ignorerà l'argomento \param{size}
-usando il buffer allocato automaticamente dal sistema.  Si potrà comunque
-modificare la modalità di bufferizzazione, passando in \param{mode} uno degli
+\val{NULL} per \param{buf} e la funzione ignorerà l'argomento \param{size}
+usando il buffer allocato automaticamente dal sistema.  Si potrà comunque
+modificare la modalità di bufferizzazione, passando in \param{mode} uno degli
 opportuni valori elencati in tab.~\ref{tab:file_stream_buf_mode}. Qualora si
-specifichi la modalità non bufferizzata i valori di \param{buf} e \param{size}
+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
@@ -1466,42 +1466,42 @@ e \funcd{setlinebuf}; i loro prototipi sono:
   \headdecl{stdio.h} 
   
   \funcdecl{void setbuf(FILE *stream, char *buf)} Disabilita la
-  bufferizzazione se \param{buf} è \val{NULL}, altrimenti usa \param{buf}
-  come buffer di dimensione \const{BUFSIZ} in modalità \textit{fully buffered}.
+  bufferizzazione se \param{buf} è \val{NULL}, altrimenti usa \param{buf}
+  come buffer di dimensione \const{BUFSIZ} in modalità \textit{fully buffered}.
   
   \funcdecl{void setbuffer(FILE *stream, char *buf, size\_t size)} Disabilita
-  la bufferizzazione se \param{buf} è \val{NULL}, altrimenti usa \param{buf}
-  come buffer di dimensione \param{size} in modalità \textit{fully buffered}.
+  la bufferizzazione se \param{buf} è \val{NULL}, altrimenti usa \param{buf}
+  come buffer di dimensione \param{size} in modalità \textit{fully buffered}.
   
-  \funcdecl{void setlinebuf(FILE *stream)} Pone lo stream in modalità
+  \funcdecl{void setlinebuf(FILE *stream)} Pone lo stream in modalità
   \textit{line buffered}.
 \end{functions}
 \noindent tutte queste funzioni sono realizzate con opportune chiamate a
-\func{setvbuf} e sono definite solo per compatibilità con le vecchie librerie
+\func{setvbuf} e sono definite solo per compatibilità con le vecchie librerie
 BSD. Infine le \acr{glibc} provvedono le funzioni non standard\footnote{anche
   queste funzioni sono originarie di Solaris.} \funcd{\_\_flbf} e
-\funcd{\_\_fbufsize} che permettono di leggere le proprietà di bufferizzazione
+\funcd{\_\_fbufsize} che permettono di leggere le proprietà di bufferizzazione
 di uno stream; i cui prototipi sono:
 \begin{functions}
   \headdecl{stdio\_ext.h} 
   
   \funcdecl{int \_\_flbf(FILE *stream)} Restituisce un valore diverso da zero
-  se \param{stream} è in modalità \textit{line buffered}.
+  se \param{stream} è in modalità \textit{line buffered}.
   
   \funcdecl{size\_t \_\_fbufsize(FILE *stream)} Restituisce le dimensioni del
   buffer di \param{stream}.
 \end{functions}
 
-Come già accennato, indipendentemente dalla modalità di bufferizzazione
-scelta, si può forzare lo scarico dei dati sul file con la funzione
-\funcd{fflush}, il suo prototipo è:
+Come già accennato, indipendentemente dalla modalità di bufferizzazione
+scelta, si può forzare lo scarico dei dati sul file con la funzione
+\funcd{fflush}, il suo prototipo è:
 \begin{prototype}{stdio.h}{int fflush(FILE *stream)}
   
   Forza la scrittura di tutti i dati bufferizzati dello stream \param{stream}.
   
   \bodydesc{Restituisce zero in caso di successo, ed \val{EOF} in caso di
-    errore, impostando \var{errno} a \errval{EBADF} se \param{stream} non è
-    aperto o non è aperto in scrittura, o ad uno degli errori di
+    errore, impostando \var{errno} a \errval{EBADF} se \param{stream} non è
+    aperto o non è aperto in scrittura, o ad uno degli errori di
     \func{write}.}
 \end{prototype}
 \noindent anche di questa funzione esiste una analoga
@@ -1509,14 +1509,14 @@ scelta, si pu
   \macro{\_SVID\_SOURCE} o \macro{\_GNU\_SOURCE}.} che non effettua il blocco
 dello stream.
 
-Se \param{stream} è \val{NULL} lo scarico dei dati è forzato per tutti gli
-stream aperti. Esistono però circostanze, ad esempio quando si vuole essere
+Se \param{stream} è \val{NULL} lo scarico dei dati è forzato per tutti gli
+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 stream in modalità line buffered;
+effettuare lo scarico dei dati solo per gli stream in modalità line buffered;
 per questo motivo le \acr{glibc} supportano una estensione di Solaris, la
-funzione \funcd{\_flushlbf}, il cui prototipo è:
+funzione \funcd{\_flushlbf}, il cui prototipo è:
 \begin{prototype}{stdio-ext.h}{void \_flushlbf(void)}
-  Forza la scrittura di tutti i dati bufferizzati degli stream in modalità
+  Forza la scrittura di tutti i dati bufferizzati degli stream in modalità
   line buffered.
 \end{prototype}
 
@@ -1526,7 +1526,7 @@ kernel dia effettivamente avvio alle operazioni di scrittura su disco occorre
 usare \func{sync} o \func{fsync} (si veda~sez.~\ref{sec:file_sync}).
 
 Infine esistono anche circostanze in cui si vuole scartare tutto l'output
-pendente; per questo si può usare \funcd{fpurge}, il cui prototipo è:
+pendente; per questo si può usare \funcd{fpurge}, il cui prototipo è:
 \begin{prototype}{stdio.h}{int fpurge(FILE *stream)}
  
   Cancella i buffer di input e di output dello stream \param{stream}.
@@ -1535,8 +1535,8 @@ pendente; per questo si pu
     errore.}
 \end{prototype}
 
-La funzione scarta tutti i dati non ancora scritti (se il file è aperto in
-scrittura), e tutto l'input non ancora letto (se è aperto in lettura),
+La funzione scarta tutti i dati non ancora scritti (se il file è aperto in
+scrittura), e tutto l'input non ancora letto (se è aperto in lettura),
 compresi gli eventuali caratteri rimandati indietro con \func{ungetc}.
 
 
@@ -1548,20 +1548,20 @@ compresi gli eventuali caratteri rimandati indietro con \func{ungetc}.
 Gli stream possono essere usati in applicazioni \textit{multi-thread} allo
 stesso modo in cui sono usati nelle applicazioni normali, ma si deve essere
 consapevoli delle possibili complicazioni anche quando non si usano i
-\textit{thread}, dato che l'implementazione delle librerie è influenzata
+\textit{thread}, dato che l'implementazione delle librerie è influenzata
 pesantemente dalle richieste necessarie per garantirne l'uso con i
 \textit{thread}.
 
 Lo standard POSIX richiede che le operazioni sui file siano atomiche rispetto
 ai \textit{thread}, per questo le operazioni sui buffer effettuate dalle
 funzioni di libreria durante la lettura e la scrittura di uno stream devono
-essere opportunamente protette (in quanto il sistema assicura l'atomicità solo
+essere opportunamente protette (in quanto il sistema assicura l'atomicità solo
 per le system call). Questo viene fatto associando ad ogni stream un opportuno
 blocco che deve essere implicitamente acquisito prima dell'esecuzione di
 qualunque operazione.
 
 Ci sono comunque situazioni in cui questo non basta, come quando un
-\textit{thread} necessita di compiere più di una operazione sullo stream
+\textit{thread} necessita di compiere più di una operazione sullo stream
 atomicamente, per questo motivo le librerie provvedono anche delle funzioni
 \funcd{flockfile}, \funcd{ftrylockfile} e \funcd{funlockfile}, che permettono
 la gestione esplicita dei blocchi sugli stream; esse sono disponibili
@@ -1570,10 +1570,10 @@ definendo \macro{\_POSIX\_THREAD\_SAFE\_FUNCTIONS} ed i loro prototipi sono:
   \headdecl{stdio.h}
   
   \funcdecl{void flockfile(FILE *stream)} Esegue l'acquisizione del lock dello
-  stream \param{stream}, bloccandosi se il lock non è disponibile.
+  stream \param{stream}, bloccandosi se il lock non è disponibile.
   
   \funcdecl{int ftrylockfile(FILE *stream)} Tenta l'acquisizione del lock
-  dello stream \param{stream}, senza bloccarsi se il lock non è disponibile.
+  dello stream \param{stream}, senza bloccarsi se il lock non è disponibile.
   Ritorna zero in caso di acquisizione del lock, diverso da zero altrimenti.
   
   \funcdecl{void funlockfile(FILE *stream)} Rilascia il lock dello
@@ -1582,28 +1582,28 @@ definendo \macro{\_POSIX\_THREAD\_SAFE\_FUNCTIONS} ed i loro prototipi sono:
 \noindent con queste funzioni diventa possibile acquisire un blocco ed
 eseguire tutte le operazioni volute, per poi rilasciarlo. 
 
-Ma, vista la complessità delle strutture di dati coinvolte, le operazioni di
-blocco non sono del tutto indolori, e quando il locking dello stream non è
+Ma, vista la complessità delle strutture di dati coinvolte, le operazioni di
+blocco non sono del tutto indolori, e quando il locking dello stream non è
 necessario (come in tutti i programmi che non usano i \textit{thread}), tutta
-la procedura può comportare dei costi pesanti in termini di prestazioni. Per
+la procedura può comportare dei costi pesanti in termini di prestazioni. Per
 questo motivo abbiamo visto come alle usuali funzioni di I/O non formattato
 siano associate delle versioni \code{\_unlocked} (alcune previste dallo stesso
 standard POSIX, altre aggiunte come estensioni dalle \acr{glibc}) che possono
 essere usate quando il locking non serve\footnote{in certi casi dette funzioni
-  possono essere usate, visto che sono molto più efficienti, anche in caso di
-  necessità di locking, una volta che questo sia stato acquisito manualmente.}
-con prestazioni molto più elevate, dato che spesso queste versioni (come
+  possono essere usate, visto che sono molto più efficienti, anche in caso di
+  necessità di locking, una volta che questo sia stato acquisito manualmente.}
+con prestazioni molto più elevate, dato che spesso queste versioni (come
 accade per \func{getc} e \func{putc}) sono realizzate come macro.
 
 La sostituzione di tutte le funzioni di I/O con le relative versioni
-\code{\_unlocked} in un programma che non usa i \textit{thread} è però un
+\code{\_unlocked} in un programma che non usa i \textit{thread} è però un
 lavoro abbastanza noioso; per questo motivo le \acr{glibc} forniscono al
 programmatore pigro un'altra via\footnote{anche questa mutuata da estensioni
   introdotte in Solaris.} da poter utilizzare per disabilitare in blocco il
 locking degli stream: l'uso della funzione \funcd{\_\_fsetlocking}, il cui
-prototipo è:
+prototipo è:
 \begin{prototype}{stdio\_ext.h}{int \_\_fsetlocking (FILE *stream, int type)}
-  Specifica o richiede a seconda del valore di \param{type} la modalità in cui
+  Specifica o richiede a seconda del valore di \param{type} la modalità in cui
   le operazioni di I/O su \param{stream} vengono effettuate rispetto
   all'acquisizione implicita del blocco sullo stream.
 
@@ -1611,15 +1611,15 @@ prototipo 
   valori \const{FSETLOCKING\_INTERNAL} o \const{FSETLOCKING\_BYCALLER}.}
 \end{prototype}
 
-La funzione imposta o legge lo stato della modalità di operazione di uno stream
+La funzione imposta o legge lo stato della modalità di operazione di uno stream
 nei confronti del locking a seconda del valore specificato con \param{type},
-che può essere uno dei seguenti:
+che può essere uno dei seguenti:
 \begin{basedescript}{\desclabelwidth{4.0cm}}
-\item[\const{FSETLOCKING\_INTERNAL}] Lo stream userà da ora in poi il blocco
+\item[\const{FSETLOCKING\_INTERNAL}] Lo stream userà da ora in poi il blocco
   implicito predefinito.
-\item[\const{FSETLOCKING\_BYCALLER}] Al ritorno della funzione sarà l'utente a
+\item[\const{FSETLOCKING\_BYCALLER}] Al ritorno della funzione sarà l'utente a
   dover gestire da solo il locking dello stream.
-\item[\const{FSETLOCKING\_QUERY}] Restituisce lo stato corrente della modalità
+\item[\const{FSETLOCKING\_QUERY}] Restituisce lo stato corrente della modalità
   di blocco dello stream.
 \end{basedescript}
 
@@ -1641,7 +1641,7 @@ che pu
 % LocalWords:  IROTH IWOTH umask fseek fsetpos rewind SEEK CUR EOF EBADF close
 % LocalWords:  sync fcloseall SOURCE void stdlib of feof ferror clearerr l'I ws
 % LocalWords:  unlocked fread fwrite size ptr nmemb nelem gcc padding point str
-% LocalWords:  lock thread fgetc getc getchar dell'overhead altresì unsigned ap
+% LocalWords:  lock thread fgetc getc getchar dell'overhead altresì unsigned ap
 % LocalWords:  getwc fgetwc getwchar wint wchar WEOF putc fputc putchar dell'I
 % LocalWords:  SVID getw putw parsing peeking ahead ungetc gets fgets string Di
 % LocalWords:  overflow Aleph stack fputs puts fgetws fputws getline ssize leak
diff --git a/fileunix.tex b/fileunix.tex
index 77736fb..5de72aa 100644
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -15,9 +15,9 @@
 
 Esamineremo in questo capitolo la prima delle due interfacce di programmazione
 per i file, quella dei \index{file!descriptor} \textit{file descriptor},
-nativa di Unix. Questa è l'interfaccia di basso livello provvista direttamente
-dalle system call, che non prevede funzionalità evolute come la
-bufferizzazione o funzioni di lettura o scrittura formattata, e sulla quale è
+nativa di Unix. Questa è l'interfaccia di basso livello provvista direttamente
+dalle system call, che non prevede funzionalità evolute come la
+bufferizzazione o funzioni di lettura o scrittura formattata, e sulla quale è
 costruita anche l'interfaccia definita dallo standard ANSI C che affronteremo
 al cap.~\ref{cha:files_std_interface}.
 
@@ -26,7 +26,7 @@ al cap.~\ref{cha:files_std_interface}.
 \section{L'architettura di base}
 \label{sec:file_base_arch}
 
-In questa sezione faremo una breve introduzione sull'architettura su cui è
+In questa sezione faremo una breve introduzione sull'architettura su cui è
 basata dell'interfaccia dei \textit{file descriptor}, che, sia pure con
 differenze nella realizzazione pratica, resta sostanzialmente la stessa in
 tutte le implementazione di un sistema unix-like.
@@ -40,11 +40,11 @@ tutte le implementazione di un sistema unix-like.
 Per poter accedere al contenuto di un file occorre creare un canale di
 comunicazione con il kernel che renda possibile operare su di esso (si ricordi
 quanto visto in sez.~\ref{sec:file_vfs_work}). Questo si fa aprendo il file
-con la funzione \func{open} che provvederà a localizzare \index{inode} l'inode
+con la funzione \func{open} che provvederà a localizzare \index{inode} l'inode
 del file e inizializzare i puntatori che rendono disponibili le funzioni che
 il VFS mette a disposizione (riportate in
 tab.~\ref{tab:file_file_operations}). Una volta terminate le operazioni, il
-file dovrà essere chiuso, e questo chiuderà il canale di comunicazione
+file dovrà essere chiuso, e questo chiuderà il canale di comunicazione
 impedendo ogni ulteriore operazione.
 
 All'interno di ogni processo i file aperti sono identificati da un intero non
@@ -59,11 +59,11 @@ un elenco dei processi attivi nella cosiddetta \itindex{process~table}
 \textit{process table} ed un elenco dei file aperti nella
 \itindex{file~table} \textit{file table}.
 
-La \itindex{process~table} \textit{process table} è una tabella che contiene
-una voce per ciascun processo attivo nel sistema. In Linux ciascuna voce è
+La \itindex{process~table} \textit{process table} è una tabella che contiene
+una voce per ciascun processo attivo nel sistema. In Linux ciascuna voce è
 costituita da una struttura di tipo \struct{task\_struct} nella quale sono
 raccolte tutte le informazioni relative al processo; fra queste informazioni
-c'è anche il puntatore ad una ulteriore struttura di tipo
+c'è anche il puntatore ad una ulteriore struttura di tipo
 \struct{files\_struct}, in cui sono contenute le informazioni relative ai file
 che il processo ha aperto, ed in particolare:
 \begin{itemize*}
@@ -72,19 +72,19 @@ che il processo ha aperto, ed in particolare:
 \item una tabella che contiene un puntatore alla relativa voce nella
   \itindex{file~table} \textit{file table} per ogni file aperto.
 \end{itemize*}
-il \textit{file descriptor} in sostanza è l'intero positivo che indicizza
+il \textit{file descriptor} in sostanza è l'intero positivo che indicizza
 quest'ultima tabella.
 
-La \itindex{file~table} \textit{file table} è una tabella che contiene una
-voce per ciascun file che è stato aperto nel sistema. In Linux è costituita da
+La \itindex{file~table} \textit{file table} è una tabella che contiene una
+voce per ciascun file che è stato aperto nel sistema. In Linux è costituita da
 strutture di tipo \struct{file}; in ciascuna di esse sono tenute varie
 informazioni relative al file, fra cui:
 \begin{itemize*}
 \item lo stato del file (nel campo \var{f\_flags}).
 \item il valore della posizione corrente (l'\textit{offset}) nel file (nel
   campo \var{f\_pos}).
-\item un puntatore \index{inode} all'inode\footnote{nel kernel 2.4.x si è in
-    realtà passati ad un puntatore ad una struttura \struct{dentry} che punta
+\item un puntatore \index{inode} all'inode\footnote{nel kernel 2.4.x si è in
+    realtà passati ad un puntatore ad una struttura \struct{dentry} che punta
     a sua volta \index{inode} all'inode passando per la nuova struttura del
     VFS.}  del file.
 %\item un puntatore alla tabella delle funzioni \footnote{la struttura
@@ -92,10 +92,10 @@ informazioni relative al file, fra cui:
 %  sul file.
 \end{itemize*}
 
-In fig.~\ref{fig:file_proc_file} si è riportato uno schema in cui è illustrata
+In fig.~\ref{fig:file_proc_file} si è riportato uno schema in cui è illustrata
 questa architettura, ed in cui si sono evidenziate le interrelazioni fra le
-varie strutture di dati sulla quale essa è basata.
-Ritorneremo su questo schema più volte, dato che esso è fondamentale per
+varie strutture di dati sulla quale essa è basata.
+Ritorneremo su questo schema più volte, dato che esso è fondamentale per
 capire i dettagli del funzionamento dell'interfaccia dei \textit{file
   descriptor}.  
 
@@ -116,20 +116,20 @@ capire i dettagli del funzionamento dell'interfaccia dei \textit{file
 
 Come accennato i \textit{file descriptor} non sono altro che un indice nella
 tabella dei file aperti di ciascun processo; per questo motivo essi vengono
-assegnati in successione tutte le volte che si apre un nuovo file (se non ne è
+assegnati in successione tutte le volte che si apre un nuovo file (se non ne è
 stato chiuso nessuno in precedenza).
 
 In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
 processo viene lanciato dalla shell con almeno tre file aperti. Questi, per
 quanto appena detto, avranno come \index{file!descriptor} \textit{file
-  descriptor} i valori 0, 1 e 2.  Benché questa sia soltanto una convenzione,
-essa è seguita dalla gran parte delle applicazioni, e non aderirvi potrebbe
-portare a gravi problemi di interoperabilità.
+  descriptor} i valori 0, 1 e 2.  Benché questa sia soltanto una convenzione,
+essa è seguita dalla gran parte delle applicazioni, e non aderirvi potrebbe
+portare a gravi problemi di interoperabilità.
 
-Il primo file è sempre associato al cosiddetto \textit{standard input}; è cioè
+Il primo file è sempre associato al cosiddetto \textit{standard input}; è cioè
 il file da cui il processo si aspetta di ricevere i dati in ingresso. Il
-secondo file è il cosiddetto \textit{standard output}, cioè quello su cui ci
-si aspetta debbano essere inviati i dati in uscita. Il terzo è lo
+secondo file è il cosiddetto \textit{standard output}, cioè quello su cui ci
+si aspetta debbano essere inviati i dati in uscita. Il terzo è lo
 \textit{standard error}, su cui viene inviata l'uscita relativa agli errori.
 Nel caso della shell tutti questi file sono associati al terminale di
 controllo, e corrispondono quindi alla lettura della tastiera per l'ingresso e
@@ -158,8 +158,8 @@ tab.~\ref{tab:file_std_files}.
   \label{tab:file_std_files}
 \end{table}
 
-In fig.~\ref{fig:file_proc_file} si è rappresentata una situazione diversa,
-facendo riferimento ad un programma in cui lo \textit{standard input} è
+In fig.~\ref{fig:file_proc_file} si è rappresentata una situazione diversa,
+facendo riferimento ad un programma in cui lo \textit{standard input} è
 associato ad un file mentre lo \textit{standard output} e lo \textit{standard
   error} sono entrambi associati ad un altro file (e quindi utilizzano lo
 stesso \index{inode} inode).
@@ -168,7 +168,7 @@ 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
 dimensioni del vettore di puntatori con cui era realizzata la tabella dei file
 descriptor dentro \struct{file\_struct}; questo limite intrinseco nei kernel
-più recenti non sussiste più, dato che si è passati da un vettore ad una
+più recenti non sussiste più, dato che si è passati da un vettore ad una
 lista, ma restano i limiti imposti dall'amministratore (vedi
 sez.~\ref{sec:sys_limits}).
 
@@ -177,7 +177,7 @@ sez.~\ref{sec:sys_limits}).
 \section{Le funzioni base}
 \label{sec:file_base_func}
 
-L'interfaccia standard Unix per l'input/output sui file è basata su cinque
+L'interfaccia standard Unix per l'input/output sui file è basata su cinque
 funzioni fondamentali: \func{open}, \func{read}, \func{write}, \func{lseek} e
 \func{close}, usate rispettivamente per aprire, leggere, scrivere, spostarsi e
 chiudere un file.  La gran parte delle operazioni sui file si effettua
@@ -189,40 +189,40 @@ usando direttamente le system call del kernel.
 \subsection{La funzione \func{open}}
 \label{sec:file_open}
 
-La funzione \funcd{open} è la funzione fondamentale per accedere ai file, ed è
+La funzione \funcd{open} è la funzione fondamentale per accedere ai file, ed è
 quella che crea l'associazione fra un \itindex{pathname} \textit{pathname} ed
-un \index{file!descriptor} file descriptor, il suo prototipo è:
+un \index{file!descriptor} file descriptor, il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{sys/stat.h}
   \headdecl{fcntl.h}
   \funcdecl{int open(const char *pathname, int flags)}
   \funcdecl{int open(const char *pathname, int flags, mode\_t mode)}
-  Apre il file indicato da \param{pathname} nella modalità indicata da
+  Apre il file indicato da \param{pathname} nella modalità indicata da
   \param{flags}, e, nel caso il file sia creato, con gli eventuali permessi
   specificati da \param{mode}.
   
   \bodydesc{La funzione ritorna il file descriptor in caso di successo e $-1$
-    in caso di errore. In questo caso la variabile \var{errno} assumerà uno
+    in caso di errore. In questo caso la variabile \var{errno} assumerà uno
     dei valori:
   \begin{errlist}
-  \item[\errcode{EEXIST}] \param{pathname} esiste e si è specificato
+  \item[\errcode{EEXIST}] \param{pathname} esiste e si è specificato
     \const{O\_CREAT} e \const{O\_EXCL}.  
-  \item[\errcode{EISDIR}] \param{pathname} indica una directory e si è tentato
+  \item[\errcode{EISDIR}] \param{pathname} indica una directory e si è tentato
     l'accesso in scrittura. 
-  \item[\errcode{ENOTDIR}] si è specificato \const{O\_DIRECTORY} e
-    \param{pathname} non è una directory.
+  \item[\errcode{ENOTDIR}] si è specificato \const{O\_DIRECTORY} e
+    \param{pathname} non è una directory.
   \item[\errcode{ENXIO}] si sono impostati \const{O\_NOBLOCK} 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 è
+    \const{O\_WRONLY} ed il file è una fifo che non viene letta da nessun
+    processo o \param{pathname} è un file di dispositivo ma il dispositivo è
     assente.
   \item[\errcode{ENODEV}] \param{pathname} si riferisce a un file di
     dispositivo che non esiste.
-  \item[\errcode{ETXTBSY}] si è cercato di accedere in scrittura all'immagine
+  \item[\errcode{ETXTBSY}] si è cercato di accedere in scrittura all'immagine
     di un programma in esecuzione.
   \item[\errcode{ELOOP}] si sono incontrati troppi link simbolici nel
-    risolvere il \textit{pathname} o si è indicato \const{O\_NOFOLLOW} e
-    \param{pathname} è un link simbolico.
+    risolvere il \textit{pathname} o si è indicato \const{O\_NOFOLLOW} e
+    \param{pathname} è un link simbolico.
   \end{errlist}
   ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG}, \errval{ENOENT},
   \errval{EROFS}, \errval{EFAULT}, \errval{ENOSPC}, \errval{ENOMEM},
@@ -231,12 +231,12 @@ un \index{file!descriptor} file descriptor, il suo prototipo 
 
 
 La funzione apre il file usando il primo file descriptor libero, e crea
-l'opportuna voce, cioè la struttura \struct{file}, nella \itindex{file~table}
+l'opportuna voce, cioè la struttura \struct{file}, nella \itindex{file~table}
 \textit{file table} del processo.  Viene sempre restituito come valore di
-ritorno il file descriptor con il valore più basso disponibile.
+ritorno il file descriptor con il valore più basso disponibile.
 
 \footnotetext[2]{la pagina di manuale di \func{open} segnala che questa
-  opzione è difettosa su NFS, e che i programmi che la usano per stabilire un
+  opzione è difettosa su NFS, e che i programmi che la usano per stabilire un
   \index{file!di lock} \textsl{file di lock} possono incorrere in una
   \itindex{race~condition} \textit{race condition}.  Si consiglia come
   alternativa di usare un file con un nome univoco e la funzione \func{link}
@@ -249,29 +249,29 @@ ritorno il file descriptor con il valore pi
     \hline
     \textbf{Flag} & \textbf{Descrizione} \\
     \hline
-    \hline % modalità di accesso al file
+    \hline % modalità di accesso al file
     \const{O\_RDONLY}  & Apre il file in sola lettura, le \acr{glibc}
                          definiscono anche \const{O\_READ} come sinonimo. \\
     \const{O\_WRONLY}  & Apre il file in sola scrittura, le \acr{glibc}
                          definiscono anche \const{O\_WRITE} come sinonimo. \\
     \const{O\_RDWR}    & Apre il file sia in lettura che in scrittura. \\
-    \hline % modalità di apertura del file
+    \hline % modalità di apertura del file
     \hline
-    \const{O\_CREAT}   & Se il file non esiste verrà creato, con le regole di
-                         titolarità del file viste in
+    \const{O\_CREAT}   & Se il file non esiste verrà creato, con le regole di
+                         titolarità del file viste in
                          sez.~\ref{sec:file_ownership_management}. Con questa
                          opzione l'argomento \param{mode} deve essere
                          specificato.\\ 
-    \const{O\_EXCL}    & Usato in congiunzione con \const{O\_CREAT} fa sì che
+    \const{O\_EXCL}    & Usato in congiunzione con \const{O\_CREAT} fa sì che
                          la precedente esistenza del file diventi un
                          errore\protect\footnotemark\ che fa fallire
                          \func{open} con \errcode{EEXIST}.\\
-    \const{O\_NONBLOCK}& Apre il file in modalità non bloccante, e
+    \const{O\_NONBLOCK}& Apre il file in modalità non bloccante, e
                          comporta che \func{open} ritorni immediatamente anche
                          quando dovrebbe bloccarsi (l'opzione ha senso solo per
                          le fifo, vedi sez.~\ref{sec:ipc_named_pipe}).\\
     \const{O\_NOCTTY}  & Se \param{pathname} si riferisce ad un dispositivo di
-                         terminale, questo non diventerà il terminale di
+                         terminale, questo non diventerà il terminale di
                          controllo, anche se il processo non ne ha ancora uno
                          (si veda sez.~\ref{sec:sess_ctrl_term}).\\ 
     \const{O\_SHLOCK}  & Apre il file con uno shared lock (vedi
@@ -283,19 +283,19 @@ ritorno il file descriptor con il valore pi
     \const{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
-                         comportamento non è specificato.\\ 
-    \const{O\_NOFOLLOW}& Se \param{pathname} è un link simbolico la chiamata
-                         fallisce. Questa è un'estensione BSD aggiunta in Linux
+                         comportamento non è specificato.\\ 
+    \const{O\_NOFOLLOW}& Se \param{pathname} è un link simbolico la chiamata
+                         fallisce. Questa è un'estensione BSD aggiunta in Linux
                          dal kernel 2.1.126. Nelle versioni precedenti i link
-                         simbolici sono sempre seguiti, e questa opzione è
+                         simbolici sono sempre seguiti, e questa opzione è
                          ignorata.\\
-    \const{O\_DIRECTORY}&Se \param{pathname} non è una directory la chiamata
-                         fallisce. Questo flag è specifico di Linux ed è stato
+    \const{O\_DIRECTORY}&Se \param{pathname} non è una directory la chiamata
+                         fallisce. Questo flag è specifico di Linux ed è stato
                          introdotto con il kernel 2.1.126 per evitare dei 
                          \itindex{Denial~of~Service~(DoS)}
                          \textit{DoS}\protect\footnotemark\ quando 
                          \func{opendir} viene chiamata su una fifo o su un
-                         dispositivo associato ad una unità a nastri, non deve
+                         dispositivo associato ad una unità a nastri, non deve
                          dispositivo a nastri; non deve essere utilizzato
                          al di fuori dell'implementazione di \func{opendir}.\\
     \const{O\_LARGEFILE}&Nel caso di sistemi a 32 bit che supportano file di
@@ -303,30 +303,30 @@ ritorno il file descriptor con il valore pi
                          dimensioni non possono essere rappresentate da numeri
                          a 31 bit.\\
     \hline
-    \hline  % modalità di operazione coi file
+    \hline  % modalità di operazione coi file
     \const{O\_APPEND}  & Il file viene aperto in \itindex{append~mode}
                          \textit{append mode}. Prima di ciascuna 
                          scrittura la posizione corrente viene sempre impostata
-                         alla fine del file. Con NFS si può avere una
-                         corruzione del file se più di un processo scrive allo
+                         alla fine del file. Con NFS si può avere una
+                         corruzione del file se più di un processo scrive allo
                          stesso tempo.\footnotemark\\ 
-    \const{O\_NONBLOCK}& Il file viene aperto in modalità non bloccante per
+    \const{O\_NONBLOCK}& Il file viene aperto in modalità non bloccante per
                          le operazioni di I/O (che tratteremo in
                          sez.~\ref{sec:file_noblocking}): questo significa il
                          fallimento di \func{read} in assenza di dati da
                          leggere e quello di \func{write} in caso di
-                         impossibilità di scrivere immediatamente. Questa
-                         modalità ha senso solo per le fifo e per alcuni file
+                         impossibilità di scrivere immediatamente. Questa
+                         modalità ha senso solo per le fifo e per alcuni file
                          di dispositivo.\\ 
-    \const{O\_NDELAY}  & In Linux\footnotemark\ è sinonimo di 
+    \const{O\_NDELAY}  & In Linux\footnotemark\ è sinonimo di 
                          \const{O\_NONBLOCK}.\\
-    \const{O\_ASYNC}   & Apre il file per l'I/O in modalità asincrona (vedi
-                         sez.~\ref{sec:file_asyncronous_io}). Quando è
+    \const{O\_ASYNC}   & Apre il file per l'I/O in modalità asincrona (vedi
+                         sez.~\ref{sec:file_asyncronous_io}). Quando è
                          impostato viene generato il segnale \const{SIGIO}
                          tutte le volte che sono disponibili dati in input
                          sul file.\\  
     \const{O\_SYNC}    & Apre il file per l'input/output sincrono: ogni
-                         \func{write} bloccherà fino al completamento della
+                         \func{write} bloccherà fino al completamento della
                          scrittura di tutti i dati sull'hardware
                          sottostante.\\  
     \const{O\_FSYNC}   & Sinonimo di \const{O\_SYNC}, usato da BSD.\\
@@ -337,7 +337,7 @@ ritorno il file descriptor con il valore pi
                          modo.\\
     \const{O\_NOATIME} & Blocca l'aggiornamento dei tempi di accesso dei
                          file (vedi sez.~\ref{sec:file_file_times}). Per molti
-                         filesystem questa funzionalità non è disponibile per
+                         filesystem questa funzionalità non è disponibile per
                          il singolo file ma come opzione generale da
                          specificare in fase di montaggio.\\
     \const{O\_DIRECT}  & Esegue l'I/O direttamente dai buffer in user space
@@ -350,7 +350,7 @@ ritorno il file descriptor con il valore pi
                          alle dimensioni dei blocchi del filesystem; per il
                          kernel 2.6 basta che siano allineati a multipli di 512
                          byte.\\
-    \const{O\_CLOEXEC} & Attiva la modalità di \itindex{close-on-exec}
+    \const{O\_CLOEXEC} & Attiva la modalità di \itindex{close-on-exec}
                          \textit{close-on-exec} (vedi 
                          sez.~\ref{sec:file_sharing} e
                          \ref{sec:file_fcntl}).\footnotemark\\  
@@ -361,50 +361,50 @@ ritorno il file descriptor con il valore pi
 \end{table}
 
 \footnotetext[3]{acronimo di \itindex{Denial~of~Service~(DoS)} \textit{Denial
-    of Service}, si chiamano così attacchi miranti ad impedire un servizio
+    of Service}, si chiamano così attacchi miranti ad impedire un servizio
   causando una qualche forma di carico eccessivo per il sistema, che resta
   bloccato nelle risposte all'attacco.}
 
-\footnotetext[4]{il problema è che NFS non supporta la scrittura in
+\footnotetext[4]{il problema è che NFS non supporta la scrittura in
   \itindex{append~mode} \textit{append}, ed il kernel deve simularla, ma
-  questo comporta la possibilità di una \itindex{race~condition} \textit{race
+  questo comporta la possibilità di una \itindex{race~condition} \textit{race
     condition}, vedi sez.~\ref{sec:file_atomic}.}
 
-\footnotetext[5]{l'opzione origina da SVr4, dove però causava il ritorno da
+\footnotetext[5]{l'opzione origina da SVr4, dove però causava il ritorno da
   una \func{read} con un valore nullo e non con un errore, questo introduce
-  un'ambiguità, dato che come vedremo in sez.~\ref{sec:file_read} il ritorno di
+  un'ambiguità, dato che come vedremo in sez.~\ref{sec:file_read} il ritorno di
   zero da parte di \func{read} ha il significato di una \textit{end-of-file}.}
 
-\footnotetext[6]{l'opzione è stata introdotta dalla SGI in IRIX, e serve
+\footnotetext[6]{l'opzione è stata introdotta dalla SGI in IRIX, e serve
   sostanzialmente a permettere ad alcuni programmi (in genere database) la
   gestione diretta della bufferizzazione dell'I/O in quanto essi sono in grado
-  di ottimizzarla al meglio per le loro prestazioni; l'opzione è presente
-  anche in FreeBSD, senza limiti di allineamento dei buffer. In Linux è stata
+  di ottimizzarla al meglio per le loro prestazioni; l'opzione è presente
+  anche in FreeBSD, senza limiti di allineamento dei buffer. In Linux è stata
   introdotta con il kernel 2.4.10, le versioni precedenti la ignorano.}
 
 \footnotetext[7]{introdotto con il kernel 2.6.23, per evitare una
-  \itindex{race~condition} \textit{race condition} che si può verificare con i
+  \itindex{race~condition} \textit{race condition} che si può verificare con i
   \itindex{thread} \textit{thread}, fra l'apertura del file e l'impostazione
-  della suddetta modalità con \func{fcntl}.}
+  della suddetta modalità con \func{fcntl}.}
 
 %TODO trattare le differenze fra O_DSYNC, O_SYNC e O_RSYNC introdotte nella  
 % nello sviluppo del kernel 2.6.33, vedi http://lwn.net/Articles/350219/
 
-Questa caratteristica permette di prevedere qual è il valore del file
-descriptor che si otterrà al ritorno di \func{open}, e viene talvolta usata da
+Questa caratteristica permette di prevedere qual è il valore del file
+descriptor che si otterrà al ritorno di \func{open}, e viene talvolta usata da
 alcune applicazioni per sostituire i file corrispondenti ai file standard
 visti in sez.~\ref{sec:file_std_descr}: se ad esempio si chiude lo standard
-input e si apre subito dopo un nuovo file questo diventerà il nuovo standard
-input (avrà cioè il file descriptor 0).  
+input e si apre subito dopo un nuovo file questo diventerà il nuovo standard
+input (avrà cioè il file descriptor 0).  
 
-Il nuovo file descriptor non è condiviso con nessun altro processo (torneremo
+Il nuovo file descriptor non è condiviso con nessun altro processo (torneremo
 sulla condivisione dei file, in genere accessibile dopo una \func{fork}, in
-sez.~\ref{sec:file_sharing}) ed è impostato per restare aperto attraverso una
-\func{exec} (come accennato in sez.~\ref{sec:proc_exec}); l'offset è impostato
+sez.~\ref{sec:file_sharing}) ed è impostato per restare aperto attraverso una
+\func{exec} (come accennato in sez.~\ref{sec:proc_exec}); l'offset è impostato
 all'inizio del file.
 
 L'argomento \param{mode} indica i permessi con cui il file viene creato; i
-valori possibili sono gli stessi già visti in
+valori possibili sono gli stessi già visti in
 sez.~\ref{sec:file_perm_overview} e possono essere specificati come OR binario
 delle costanti descritte in tab.~\ref{tab:file_bit_perm}. Questi permessi sono
 filtrati dal valore di \itindex{umask} \textit{umask} (vedi
@@ -412,31 +412,31 @@ sez.~\ref{sec:file_perm_management}) per il processo.
 
 La funzione prevede diverse opzioni, che vengono specificate usando vari bit
 dell'argomento \param{flags}.  Alcuni di questi bit vanno anche a costituire
-il flag di stato del file (o \textit{file status flag}), che è mantenuto nel
+il flag di stato del file (o \textit{file status flag}), che è mantenuto nel
 campo \var{f\_flags} della struttura \struct{file} (al solito si veda lo schema
 di fig.~\ref{fig:file_proc_file}).  Essi sono divisi in tre categorie
 principali:
 \begin{itemize*}
-\item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
-  si accederà al file: i valori possibili sono lettura, scrittura o
+\item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
+  si accederà al file: i valori possibili sono lettura, scrittura o
   lettura/scrittura.  Uno di questi bit deve essere sempre specificato quando
   si apre un file.  Vengono impostati alla chiamata da \func{open}, e possono
   essere riletti con \func{fcntl} (fanno parte del \textit{file status flag}),
   ma non possono essere modificati.
-\item \textsl{i bit delle modalità di apertura}: permettono di specificare
+\item \textsl{i bit delle modalità di apertura}: permettono di specificare
   alcune delle caratteristiche del comportamento di \func{open} quando viene
   eseguita. Hanno effetto solo al momento della chiamata della funzione e non
-  sono memorizzati né possono essere riletti.
-\item \textsl{i bit delle modalità di operazione}: permettono di specificare
+  sono memorizzati né possono essere riletti.
+\item \textsl{i bit delle modalità di operazione}: permettono di specificare
   alcune caratteristiche del comportamento delle future operazioni sul file
   (come \func{read} o \func{write}). Anch'essi fan parte del \textit{file
-    status flag}. Il loro valore è impostato alla chiamata di \func{open}, ma
+    status flag}. Il loro valore è impostato alla chiamata di \func{open}, ma
   possono essere riletti e modificati (insieme alle caratteristiche operative
   che controllano) con una \func{fcntl}.
 \end{itemize*}
 
 In tab.~\ref{tab:file_open_flags} sono riportate, ordinate e divise fra loro
-secondo le tre modalità appena elencate, le costanti mnemoniche associate a
+secondo le tre modalità appena elencate, le costanti mnemoniche associate a
 ciascuno di questi bit. Dette costanti possono essere combinate fra loro con
 un OR aritmetico per costruire il valore (in forma di maschera binaria)
 dell'argomento \param{flags} da passare alla \func{open}. I due flag
@@ -445,15 +445,15 @@ Linux, e deve essere definita la macro \macro{\_GNU\_SOURCE} per poterli
 usare.
 
 Nelle prime versioni di Unix i valori di \param{flag} specificabili per
-\func{open} erano solo quelli relativi alle modalità di accesso del file.  Per
+\func{open} erano solo quelli relativi alle modalità di accesso del file.  Per
 questo motivo per creare un nuovo file c'era una system call apposita,
-\funcd{creat}, il cui prototipo è:
+\funcd{creat}, il cui prototipo è:
 \begin{prototype}{fcntl.h}
   {int creat(const char *pathname, mode\_t mode)}
-  Crea un nuovo file vuoto, con i permessi specificati da \param{mode}. È del
+  Crea un nuovo file vuoto, con i permessi specificati da \param{mode}. È del
   tutto equivalente a \code{open(filedes, O\_CREAT|O\_WRONLY|O\_TRUNC, mode)}. 
 \end{prototype}
-\noindent adesso questa funzione resta solo per compatibilità con i vecchi 
+\noindent adesso questa funzione resta solo per compatibilità con i vecchi 
 programmi.
 
 
@@ -461,22 +461,22 @@ programmi.
 \label{sec:file_close}
 
 La funzione \funcd{close} permette di chiudere un file, in questo modo il file
-descriptor ritorna disponibile; il suo prototipo è:
+descriptor ritorna disponibile; il suo prototipo è:
 \begin{prototype}{unistd.h}{int close(int fd)}
   Chiude il descrittore \param{fd}. 
   
   \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
     errore, con \var{errno} che assume i valori:
   \begin{errlist}
-    \item[\errcode{EBADF}]  \param{fd} non è un descrittore valido.
-    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+    \item[\errcode{EBADF}]  \param{fd} non è un descrittore valido.
+    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
   \end{errlist}
   ed inoltre \errval{EIO}.}
 \end{prototype}
 
 La chiusura di un file rilascia ogni blocco (il \textit{file locking}
-\index{file!locking} è trattato in sez.~\ref{sec:file_locking}) che il
-processo poteva avere acquisito su di esso; se \param{fd} è l'ultimo
+\index{file!locking} è trattato in sez.~\ref{sec:file_locking}) che il
+processo poteva avere acquisito su di esso; se \param{fd} è l'ultimo
 riferimento (di eventuali copie) ad un file aperto, tutte le risorse nella
 \itindex{file~table} \textit{file table} vengono rilasciate. Infine se il file
 descriptor era l'ultimo riferimento ad un file su disco quest'ultimo viene
@@ -485,20 +485,20 @@ cancellato.
 Si ricordi che quando un processo termina anche tutti i suoi file descriptor
 vengono chiusi, molti programmi sfruttano questa caratteristica e non usano
 esplicitamente \func{close}. In genere comunque chiudere un file senza
-controllarne lo stato di uscita è errore; infatti molti filesystem
+controllarne lo stato di uscita è errore; infatti molti filesystem
 implementano la tecnica del \textit{write-behind}, per cui una \func{write}
-può avere successo anche se i dati non sono stati scritti, un eventuale errore
-di I/O allora può sfuggire, ma verrà riportato alla chiusura del file: per
-questo motivo non effettuare il controllo può portare ad una perdita di dati
-inavvertita.\footnote{in Linux questo comportamento è stato osservato con NFS
+può avere successo anche se i dati non sono stati scritti, un eventuale errore
+di I/O allora può sfuggire, ma verrà riportato alla chiusura del file: per
+questo motivo non effettuare il controllo può portare ad una perdita di dati
+inavvertita.\footnote{in Linux questo comportamento è stato osservato con NFS
   e le quote su disco.}
 
 In ogni caso una \func{close} andata a buon fine non garantisce che i dati
-siano stati effettivamente scritti su disco, perché il kernel può decidere di
+siano stati effettivamente scritti su disco, perché il kernel può decidere di
 ottimizzare l'accesso a disco ritardandone la scrittura. L'uso della funzione
 \func{sync} (vedi sez.~\ref{sec:file_sync}) effettua esplicitamente il
 \emph{flush} dei dati, ma anche in questo caso resta l'incertezza dovuta al
-comportamento dell'hardware (che a sua volta può introdurre ottimizzazioni
+comportamento dell'hardware (che a sua volta può introdurre ottimizzazioni
 dell'accesso al disco che ritardano la scrittura dei dati, da cui l'abitudine
 di ripetere tre volte il comando prima di eseguire lo shutdown).
 
@@ -506,17 +506,17 @@ di ripetere tre volte il comando prima di eseguire lo shutdown).
 \subsection{La funzione \func{lseek}}
 \label{sec:file_lseek}
 
-Come già accennato in sez.~\ref{sec:file_fd} a ciascun file aperto è associata
+Come già accennato in sez.~\ref{sec:file_fd} a ciascun file aperto è associata
 una \textsl{posizione corrente nel file} (il cosiddetto \textit{file offset},
 mantenuto nel campo \var{f\_pos} di \struct{file}) espressa da un numero intero
 positivo come numero di byte dall'inizio del file. Tutte le operazioni di
 lettura e scrittura avvengono a partire da questa posizione che viene
 automaticamente spostata in avanti del numero di byte letti o scritti.
 
-In genere (a meno di non avere richiesto la modalità \itindex{append~mode}
+In genere (a meno di non avere richiesto la modalità \itindex{append~mode}
 \const{O\_APPEND}) questa posizione viene impostata a zero all'apertura del
-file. È possibile impostarla ad un valore qualsiasi con la funzione
-\funcd{lseek}, il cui prototipo è:
+file. È possibile impostarla ad un valore qualsiasi con la funzione
+\funcd{lseek}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{unistd.h}
@@ -524,20 +524,20 @@ file. 
   Imposta la posizione attuale nel file. 
   
   \bodydesc{La funzione ritorna il valore della posizione corrente in caso di
-    successo e $-1$ in caso di errore nel qual caso \var{errno} assumerà uno
+    successo e $-1$ in caso di errore nel qual caso \var{errno} assumerà uno
     dei valori:
   \begin{errlist}
-    \item[\errcode{ESPIPE}] \param{fd} è una pipe, un socket o una fifo.
-    \item[\errcode{EINVAL}] \param{whence} non è un valore valido.
-    \item[\errcode{EOVERFLOW}] \param{offset} non può essere rappresentato nel
+    \item[\errcode{ESPIPE}] \param{fd} è una pipe, un socket o una fifo.
+    \item[\errcode{EINVAL}] \param{whence} non è un valore valido.
+    \item[\errcode{EOVERFLOW}] \param{offset} non può essere rappresentato nel
       tipo \type{off\_t}.
   \end{errlist}
   ed inoltre \errval{EBADF}.}
 \end{functions}
 
-La nuova posizione è impostata usando il valore specificato da \param{offset},
-sommato al riferimento dato da \param{whence}; quest'ultimo può assumere i
-seguenti valori\footnote{per compatibilità con alcune vecchie notazioni
+La nuova posizione è impostata usando il valore specificato da \param{offset},
+sommato al riferimento dato da \param{whence}; quest'ultimo può assumere i
+seguenti valori\footnote{per compatibilità con alcune vecchie notazioni
   questi valori possono essere rimpiazzati rispettivamente con 0, 1 e 2 o con
   \const{L\_SET}, \const{L\_INCR} e \const{L\_XTND}.}:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
@@ -545,86 +545,86 @@ seguenti valori\footnote{per compatibilit
   (sempre positivo) di \param{offset} indica direttamente la nuova posizione
   corrente.
 \item[\const{SEEK\_CUR}] si fa riferimento alla posizione corrente del file:
-  ad essa viene sommato \param{offset} (che può essere negativo e positivo)
+  ad essa viene sommato \param{offset} (che può essere negativo e positivo)
   per ottenere la nuova posizione corrente.
 \item[\const{SEEK\_END}] si fa riferimento alla fine del file: alle dimensioni
-  del file viene sommato \param{offset} (che può essere negativo e positivo)
+  del file viene sommato \param{offset} (che può essere negativo e positivo)
   per ottenere la nuova posizione corrente.
 \end{basedescript}
 
 Si tenga presente che la chiamata a \func{lseek} non causa nessun accesso al
-file, si limita a modificare la posizione corrente (cioè il valore
+file, si limita a modificare la posizione corrente (cioè il valore
 \var{f\_pos} in \param{file}, vedi fig.~\ref{fig:file_proc_file}).  Dato che
 la funzione ritorna la nuova posizione, usando il valore zero
-per \param{offset} si può riottenere la posizione corrente nel file chiamando
+per \param{offset} si può riottenere la posizione corrente nel file chiamando
 la funzione con \code{lseek(fd, 0, SEEK\_CUR)}.
 
 Si tenga presente inoltre che usare \const{SEEK\_END} non assicura affatto che
-la successiva scrittura avvenga alla fine del file, infatti se questo è stato
-aperto anche da un altro processo che vi ha scritto, la fine del file può
+la successiva scrittura avvenga alla fine del file, infatti se questo è stato
+aperto anche da un altro processo che vi ha scritto, la fine del file può
 essersi spostata, ma noi scriveremo alla posizione impostata in precedenza
-(questa è una potenziale sorgente di \itindex{race~condition} \textit{race
+(questa è una potenziale sorgente di \itindex{race~condition} \textit{race
   condition}, vedi sez.~\ref{sec:file_atomic}).
 
-Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
+Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
 questo caso la funzione ritorna l'errore \errcode{ESPIPE}. Questo, oltre che
 per i tre casi citati nel prototipo, vale anche per tutti quei dispositivi che
 non supportano questa funzione, come ad esempio per i file di
 terminale.\footnote{altri sistemi, usando \const{SEEK\_SET}, in questo caso
   ritornano il numero di caratteri che vi sono stati scritti.} Lo standard
-POSIX però non specifica niente in proposito. Inoltre alcuni file speciali, ad
+POSIX però non specifica niente in proposito. Inoltre alcuni file speciali, ad
 esempio \file{/dev/null}, non causano un errore ma restituiscono un valore
 indefinito.
 
 \itindbeg{sparse~file} 
 
 Infine si tenga presente che, come accennato in sez.~\ref{sec:file_file_size},
-con \func{lseek} è possibile impostare una posizione anche oltre la corrente
-fine del file; ed in tal caso alla successiva scrittura il file sarà esteso a
+con \func{lseek} è possibile impostare una posizione anche oltre la corrente
+fine del file; ed in tal caso alla successiva scrittura il file sarà esteso a
 partire da detta posizione. In questo caso si ha quella che viene chiamata la
-creazione di un \index{file!\textit{hole}} \textsl{buco} nel file, accade cioè
+creazione di un \index{file!\textit{hole}} \textsl{buco} nel file, accade cioè
 che nonostante la dimensione del file sia cresciuta in seguito alla scrittura
 effettuata, lo spazio vuoto fra la precedente fine del file ed la nuova parte
 scritta dopo lo spostamento, non corrisponda ad una allocazione effettiva di
-spazio su disco, che sarebbe inutile dato che quella zona è effettivamente
+spazio su disco, che sarebbe inutile dato che quella zona è effettivamente
 vuota.
 
-Questa è una delle caratteristiche spcifiche della gestione dei file di un
+Questa è una delle caratteristiche spcifiche della gestione dei file di un
 sistema unix-like, ed in questo caso si ha appunto quello che in gergo si
 chiama un \index{file!\textit{hole}} \textit{hole} nel file e si dice che il
-file in questione è uno \textit{sparse file}. In sostanza, se si ricorda la
+file in questione è uno \textit{sparse file}. In sostanza, se si ricorda la
 struttura di un filesystem illustrata in fig.~\ref{fig:file_filesys_detail},
-quello che accade è che nell'\textit{inode} del file viene segnata
+quello che accade è che nell'\textit{inode} del file viene segnata
 l'allocazione di un blocco di dati a partire dalla nuova posizione, ma non
 viene allocato nulla per le posizioni intermedie; in caso di lettura
-sequenziale del contenuto del file il kernel si accorgerà della presenza del
-buco, e restituirà degli zeri come contenuto di quella parte del file.
+sequenziale del contenuto del file il kernel si accorgerà della presenza del
+buco, e restituirà degli zeri come contenuto di quella parte del file.
 
-Questa funzionalità comporta una delle caratteristiche della gestione dei file
-su Unix che spesso genera più confusione in chi non la conosce, per cui
-sommando le dimensioni dei file si può ottenere, se si hanno molti
-\textit{sparse file}, un totale anche maggiore della capacità del proprio
+Questa funzionalità comporta una delle caratteristiche della gestione dei file
+su Unix che spesso genera più confusione in chi non la conosce, per cui
+sommando le dimensioni dei file si può ottenere, se si hanno molti
+\textit{sparse file}, un totale anche maggiore della capacità del proprio
 disco e comunque maggiore della dimensione che riporta un comando come
 \cmd{du}, che calcola lo spazio disco occupato in base al numero dei blocchi
 effettivamente allocati per il file.
 
-Questo avviene proprio perché in un sistema unix-like la dimensione di un file
-è una caratteristica del tutto indipendente dalla quantità di spazio disco
+Questo avviene proprio perché in un sistema unix-like la dimensione di un file
+è una caratteristica del tutto indipendente dalla quantità di spazio disco
 effettivamente allocato, e viene registrata sull'\textit{inode} come le altre
-proprietà del file. La dimensione viene aggiornata automaticamente quando si
+proprietà del file. La dimensione viene aggiornata automaticamente quando si
 estende un file scrivendoci, e viene riportata dal campo \var{st\_size} di una
 struttura \struct{stat} quando si effettua chiamata ad una delle funzioni
 \texttt{*stat} viste in sez.~\ref{sec:file_stat}.
 
-Questo comporta che in generale, fintanto che lo si è scritto sequenzialmente,
-la dimensione di un file sarà più o meno corrispondente alla quantità di
+Questo comporta che in generale, fintanto che lo si è scritto sequenzialmente,
+la dimensione di un file sarà più o meno corrispondente alla quantità di
 spazio disco da esso occupato, ma esistono dei casi, come questo in cui ci si
 sposta in una posizione oltre la fine corrente del file, o come quello
 accennato in in sez.~\ref{sec:file_file_size} in cui si estende la dimensione
 di un file con una \func{truncate}, in cui in sostanza di modifica il valore
 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
+dover occupare da subito dello spazio disco che in realtà sarebbe
 inutilizzato.
 
 \itindend{sparse~file}
@@ -633,21 +633,21 @@ inutilizzato.
 \subsection{Le funzioni \func{read} e \func{pread}}
 \label{sec:file_read}
 
-Una volta che un file è stato aperto (con il permesso in lettura) si possono
+Una volta che un file è stato aperto (con il permesso in lettura) si possono
 leggere i dati che contiene utilizzando la funzione \funcd{read}, il cui
-prototipo è:
+prototipo è:
 \begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)}
   
   Cerca di leggere \param{count} byte dal file \param{fd} al buffer
   \param{buf}.
   
   \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
-    $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+    $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
+  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
     aver potuto leggere qualsiasi dato.
   \item[\errcode{EAGAIN}] la funzione non aveva nessun dato da restituire e si
-    era aperto il file in modalità \const{O\_NONBLOCK}.
+    era aperto il file in modalità \const{O\_NONBLOCK}.
   \end{errlist}
   ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
   \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori dipendenti dalla
@@ -655,61 +655,61 @@ prototipo 
 \end{prototype}
 
 La funzione tenta di leggere \param{count} byte a partire dalla posizione
-corrente nel file. Dopo la lettura la posizione sul file è spostata
-automaticamente in avanti del numero di byte letti. Se \param{count} è zero la
+corrente nel file. Dopo la lettura la posizione sul file è spostata
+automaticamente in avanti del numero di byte letti. Se \param{count} è zero la
 funzione restituisce zero senza nessun altro risultato.  Si deve sempre tener
-presente che non è detto che la funzione \func{read} restituisca sempre il
+presente che non è detto che la funzione \func{read} restituisca sempre il
 numero di byte richiesto, ci sono infatti varie ragioni per cui la funzione
-può restituire un numero di byte inferiore; questo è un comportamento normale,
+può restituire un numero di byte inferiore; questo è un comportamento normale,
 e non un errore, che bisogna sempre tenere presente.  
 
-La prima e più ovvia di queste ragioni è che si è chiesto di leggere più byte
+La prima e più ovvia di queste ragioni è che si è chiesto di leggere più byte
 di quanto il file ne contenga. In questo caso il file viene letto fino alla
 sua fine, e la funzione ritorna regolarmente il numero di byte letti
 effettivamente. Raggiunta la fine del file, alla ripetizione di un'operazione
 di lettura, otterremmo il ritorno immediato di \func{read} con uno zero.  La
-condizione di raggiungimento della fine del file non è un errore, e viene
+condizione di raggiungimento della fine del file non è un errore, e viene
 segnalata appunto da un valore di ritorno di \func{read} nullo. Ripetere
 ulteriormente la lettura non avrebbe nessun effetto se non quello di
 continuare a ricevere zero come valore di ritorno.
 
-Con i \textsl{file regolari} questa è l'unica situazione in cui si può avere
-un numero di byte letti inferiore a quello richiesto, ma questo non è vero
+Con i \textsl{file regolari} questa è l'unica situazione in cui si può avere
+un numero di byte letti inferiore a quello richiesto, ma questo non è vero
 quando si legge da un terminale, da una fifo o da una pipe. In tal caso
 infatti, se non ci sono dati in ingresso, la \func{read} si blocca (a meno di
-non aver selezionato la modalità non bloccante, vedi
+non aver selezionato la modalità non bloccante, vedi
 sez.~\ref{sec:file_noblocking}) e ritorna solo quando ne arrivano; se il numero
 di byte richiesti eccede quelli disponibili la funzione ritorna comunque, ma
 con un numero di byte inferiore a quelli richiesti.
 
-Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un socket,
+Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un socket,
 come vedremo in sez.~\ref{sec:sock_io_behav}), o per la lettura da certi file
-di dispositivo, come le unità a nastro, che restituiscono sempre i dati ad un
+di dispositivo, come le unità a nastro, che restituiscono sempre i dati ad un
 singolo blocco alla volta, o come le linee seriali, che restituiscono solo i
 dati ricevuti fino al momento della lettura.
 
 Infine anche le due condizioni segnalate dagli errori \errcode{EINTR} ed
 \errcode{EAGAIN} non sono propriamente degli errori. La prima si verifica
-quando la \func{read} è bloccata in attesa di dati in ingresso e viene
-interrotta da un segnale; in tal caso l'azione da intraprendere è quella di
+quando la \func{read} è bloccata in attesa di dati in ingresso e viene
+interrotta da un segnale; in tal caso l'azione da intraprendere è quella di
 rieseguire la funzione.  Torneremo in dettaglio sull'argomento in
-sez.~\ref{sec:sig_gen_beha}.  La seconda si verifica quando il file è aperto
-in modalità non bloccante (vedi sez.~\ref{sec:file_noblocking}) e non ci sono
+sez.~\ref{sec:sig_gen_beha}.  La seconda si verifica quando il file è aperto
+in modalità non bloccante (vedi sez.~\ref{sec:file_noblocking}) e non ci sono
 dati in ingresso: la funzione allora ritorna immediatamente con un errore
 \errcode{EAGAIN}\footnote{in BSD si usa per questo errore la costante
-  \errcode{EWOULDBLOCK}, in Linux, con le \acr{glibc}, questa è sinonima di
+  \errcode{EWOULDBLOCK}, in Linux, con le \acr{glibc}, questa è sinonima di
   \errcode{EAGAIN}.} che indica soltanto che non essendoci al momento dati
 disponibili occorre provare a ripetere la lettura in un secondo tempo.
 
-La funzione \func{read} è una delle system call fondamentali, esistenti fin
+La funzione \func{read} è una delle 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 \acr{glibc}, compresa
-  l'emulazione per i vecchi kernel che non hanno la system call, è stato
+  l'emulazione per i vecchi kernel che non hanno la system call, è stato
   aggiunto con la versione 2.1, in versioni precedenti sia del kernel che
-  delle librerie la funzione non è disponibile.} (quello che viene chiamato
-normalmente Unix98, vedi sez.~\ref{sec:intro_xopen}) è stata introdotta la
-definizione di un'altra funzione di lettura, \funcd{pread}, il cui prototipo è:
+  delle librerie la funzione non è disponibile.} (quello che viene chiamato
+normalmente Unix98, vedi sez.~\ref{sec:intro_xopen}) è stata introdotta la
+definizione di un'altra funzione di lettura, \funcd{pread}, il cui prototipo è:
 \begin{prototype}{unistd.h}
 {ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)}
 
@@ -717,24 +717,24 @@ Cerca di leggere \param{count} byte dal file \param{fd}, a partire dalla
 posizione \param{offset}, nel buffer \param{buf}.
   
 \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
-  $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
+  $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
   visti per \func{read} e \func{lseek}.}
 \end{prototype}
 
 La funzione prende esattamente gli stessi argomenti di \func{read} con lo
 stesso significato, a cui si aggiunge l'argomento \func{offset} che indica una
-posizione sul file. Identico è il comportamento ed il valore di ritorno. La
+posizione sul file. Identico è il comportamento ed il valore di ritorno. La
 funzione serve quando si vogliono leggere dati dal file senza modificare la
 posizione corrente.
 
-L'uso di \func{pread} è equivalente all'esecuzione di una \func{read} seguita
+L'uso di \func{pread} è equivalente all'esecuzione di una \func{read} seguita
 da una \func{lseek} che riporti al valore precedente la posizione corrente sul
-file, ma permette di eseguire l'operazione atomicamente. Questo può essere
+file, ma permette di eseguire l'operazione atomicamente. Questo può essere
 importante quando la posizione sul file viene condivisa da processi diversi
 (vedi sez.~\ref{sec:file_sharing}).  Il valore di
 \param{offset} fa sempre riferimento all'inizio del file.
 
-La funzione \func{pread} è disponibile anche in Linux, però diventa
+La funzione \func{pread} è disponibile anche in Linux, però diventa
 accessibile solo attivando il supporto delle estensioni previste dalle
 \textit{Single Unix Specification} con la definizione della macro:
 \begin{verbatim}
@@ -748,29 +748,29 @@ dichiarazioni \file{unistd.h}.
 \subsection{Le funzioni \func{write} e \func{pwrite}}
 \label{sec:file_write}
 
-Una volta che un file è stato aperto (con il permesso in scrittura) si può
-scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo è:
+Una volta che un file è stato aperto (con il permesso in scrittura) si può
+scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo è:
 \begin{prototype}{unistd.h}{ssize\_t write(int fd, void * buf, size\_t count)}
   
   Scrive \param{count} byte dal buffer \param{buf} sul file \param{fd}.
   
   \bodydesc{La funzione ritorna il numero di byte scritti in caso di successo
-    e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
+    e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
     valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] \param{fd} è connesso ad un oggetto che non consente
+  \item[\errcode{EINVAL}] \param{fd} è connesso ad un oggetto che non consente
     la scrittura.
-  \item[\errcode{EFBIG}] si è cercato di scrivere oltre la dimensione massima
+  \item[\errcode{EFBIG}] si è cercato di scrivere oltre la dimensione massima
     consentita dal filesystem o il limite per le dimensioni dei file del
     processo o su una posizione oltre il massimo consentito.
-  \item[\errcode{EPIPE}] \param{fd} è connesso ad una pipe il cui altro capo è
+  \item[\errcode{EPIPE}] \param{fd} è connesso ad una pipe il cui altro capo è
     chiuso in lettura; in questo caso viene anche generato il segnale
     \const{SIGPIPE}, se questo viene gestito (o bloccato o ignorato) la
     funzione ritorna questo errore.
-  \item[\errcode{EINTR}] si è stati interrotti da un segnale prima di aver
+  \item[\errcode{EINTR}] si è stati interrotti da un segnale prima di aver
     potuto scrivere qualsiasi dato.
   \item[\errcode{EAGAIN}] ci si sarebbe bloccati, ma il file era aperto in
-    modalità \const{O\_NONBLOCK}.
+    modalità \const{O\_NONBLOCK}.
   \end{errlist}
   ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
   \errval{ENOSPC}, \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori
@@ -779,21 +779,21 @@ scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo 
 
 Come nel caso di \func{read} la funzione tenta di scrivere \param{count} byte
 a partire dalla posizione corrente nel file e sposta automaticamente la
-posizione in avanti del numero di byte scritti. Se il file è aperto in
-modalità \itindex{append~mode} \const{O\_APPEND} i dati vengono sempre scritti
+posizione in avanti del numero di byte scritti. Se il file è aperto in
+modalità \itindex{append~mode} \const{O\_APPEND} i dati vengono sempre scritti
 alla fine del file.  Lo standard POSIX richiede che i dati scritti siano
 immediatamente disponibili ad una \func{read} chiamata dopo che la
-\func{write} che li ha scritti è ritornata; ma dati i meccanismi di caching
-non è detto che tutti i filesystem supportino questa capacità.
+\func{write} che li ha scritti è ritornata; ma dati i meccanismi di caching
+non è detto che tutti i filesystem supportino questa capacità.
 
-Se \param{count} è zero la funzione restituisce zero senza fare nient'altro.
-Per i file ordinari il numero di byte scritti è sempre uguale a quello
+Se \param{count} è zero la funzione restituisce zero senza fare nient'altro.
+Per i file ordinari il numero di byte scritti è sempre uguale a quello
 indicato da \param{count}, a meno di un errore. Negli altri casi si ha lo
 stesso comportamento di \func{read}.
 
 Anche per \func{write} lo standard Unix98 definisce un'analoga \funcd{pwrite}
 per scrivere alla posizione indicata senza modificare la posizione corrente
-nel file, il suo prototipo è:
+nel file, il suo prototipo è:
 \begin{prototype}{unistd.h}
 {ssize\_t pwrite(int fd, void * buf, size\_t count, off\_t offset)}
   
@@ -801,7 +801,7 @@ Cerca di scrivere sul file \param{fd}, a partire dalla posizione
 \param{offset}, \param{count} byte dal buffer \param{buf}.
   
 \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
-  $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
+  $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
   visti per \func{write} e \func{lseek}.}
 \end{prototype}
 \noindent e per essa valgono le stesse considerazioni fatte per \func{pread}.
@@ -810,11 +810,11 @@ Cerca di scrivere sul file \param{fd}, a partire dalla posizione
 \section{Caratteristiche avanzate}
 \label{sec:file_adv_func}
 
-In questa sezione approfondiremo alcune delle caratteristiche più sottili
+In questa sezione approfondiremo alcune delle caratteristiche più sottili
 della gestione file in un sistema unix-like, esaminando in dettaglio il
 comportamento delle funzioni base, inoltre tratteremo le funzioni che
 permettono di eseguire alcune operazioni avanzate con i file (il grosso
-dell'argomento sarà comunque affrontato in cap.~\ref{cha:file_advanced}).
+dell'argomento sarà comunque affrontato in cap.~\ref{cha:file_advanced}).
 
 
 \subsection{La condivisione dei files}
@@ -834,33 +834,33 @@ confronti dell'accesso allo stesso file da parte di processi diversi.
   \label{fig:file_mult_acc}
 \end{figure}
 
-Il primo caso è quello in cui due processi diversi aprono lo stesso file su
+Il primo caso è quello in cui due processi diversi aprono lo stesso file su
 disco; sulla base di quanto visto in sez.~\ref{sec:file_fd} avremo una
 situazione come quella illustrata in fig.~\ref{fig:file_mult_acc}: ciascun
-processo avrà una sua voce nella \textit{file table} referenziata da un
+processo avrà una sua voce nella \textit{file table} referenziata da un
 diverso file descriptor nella sua \struct{file\_struct}. Entrambe le voci
-nella \itindex{file~table} \textit{file table} faranno però riferimento allo
+nella \itindex{file~table} \textit{file table} faranno però riferimento allo
 stesso \index{inode} inode su disco.
 
-Questo significa che ciascun processo avrà la sua posizione corrente sul file,
-la sua modalità di accesso e versioni proprie di tutte le proprietà che
+Questo significa che ciascun processo avrà la sua posizione corrente sul file,
+la sua modalità di accesso e versioni proprie di tutte le proprietà che
 vengono mantenute nella sua voce della \itindex{file~table} \textit{file
   table}. Questo ha conseguenze specifiche sugli effetti della possibile
 azione simultanea sullo stesso file, in particolare occorre tenere presente
 che:
 \begin{itemize}
-\item ciascun processo può scrivere indipendentemente; dopo ciascuna
-  \func{write} la posizione corrente sarà cambiata solo nel processo. Se la
-  scrittura eccede la dimensione corrente del file questo verrà esteso
+\item ciascun processo può scrivere indipendentemente; dopo ciascuna
+  \func{write} la posizione corrente sarà cambiata solo nel processo. Se la
+  scrittura eccede la dimensione corrente del file questo verrà esteso
   automaticamente con l'aggiornamento del campo \var{i\_size} \index{inode}
   nell'inode.
-\item se un file è in modalità \itindex{append~mode} \const{O\_APPEND} tutte
+\item se un file è in modalità \itindex{append~mode} \const{O\_APPEND} tutte
   le volte che viene effettuata una scrittura la posizione corrente viene
   prima impostata alla dimensione corrente del file letta \index{inode}
   dall'inode. Dopo la scrittura il file viene automaticamente esteso.
-\item l'effetto di \func{lseek} è solo quello di cambiare il campo
+\item l'effetto di \func{lseek} è solo quello di cambiare il campo
   \var{f\_pos} nella struttura \struct{file} della \itindex{file~table}
-  \textit{file table}, non c'è nessuna operazione sul file su disco. Quando la
+  \textit{file table}, non c'è nessuna operazione sul file su disco. Quando la
   si usa per porsi alla fine del file la posizione viene impostata leggendo la
   dimensione corrente \index{inode} dall'inode.
 \end{itemize}
@@ -872,29 +872,29 @@ che:
   \label{fig:file_acc_child}
 \end{figure}
 
-Il secondo caso è quello in cui due file descriptor di due processi diversi
+Il secondo caso è quello in cui due file descriptor di due processi diversi
 puntino alla stessa voce nella \itindex{file~table} \textit{file table};
-questo è ad esempio il caso dei file aperti che vengono ereditati dal processo
+questo è ad esempio il caso dei file aperti che vengono ereditati dal processo
 figlio all'esecuzione di una \func{fork} (si ricordi quanto detto in
-sez.~\ref{sec:proc_fork}). La situazione è illustrata in
+sez.~\ref{sec:proc_fork}). La situazione è illustrata in
 fig.~\ref{fig:file_acc_child}; dato che il processo figlio riceve una copia
-dello spazio di indirizzi del padre, riceverà anche una copia di
+dello spazio di indirizzi del padre, riceverà anche una copia di
 \struct{file\_struct} e relativa tabella dei file aperti.
 
 In questo modo padre e figlio avranno gli stessi file descriptor che faranno
-riferimento alla stessa voce nella \textit{file table}, condividendo così la
+riferimento alla stessa voce nella \textit{file table}, condividendo così la
 posizione corrente sul file. Questo ha le conseguenze descritte a suo tempo in
 sez.~\ref{sec:proc_fork}: in caso di scrittura contemporanea la posizione
-corrente nel file varierà per entrambi i processi (in quanto verrà modificato
-\var{f\_pos} che è lo stesso per entrambi).
+corrente nel file varierà per entrambi i processi (in quanto verrà modificato
+\var{f\_pos} che è lo stesso per entrambi).
 
 Si noti inoltre che anche i flag di stato del file (quelli impostati
 dall'argomento \param{flag} di \func{open}) essendo tenuti nella voce della
 \textit{file table}\footnote{per la precisione nel campo \var{f\_flags} di
-  \struct{file}.}, vengono in questo caso condivisi. Ai file però sono
-associati anche altri flag, dei quali l'unico usato al momento è
+  \struct{file}.}, vengono in questo caso condivisi. Ai file però sono
+associati anche altri flag, dei quali l'unico usato al momento è
 \const{FD\_CLOEXEC}, detti \textit{file descriptor flags}. Questi ultimi sono
-tenuti invece in \struct{file\_struct}, e perciò sono specifici di ciascun
+tenuti invece in \struct{file\_struct}, e perciò sono specifici di ciascun
 processo e non vengono modificati dalle azioni degli altri anche in caso di
 condivisione della stessa voce della \textit{file table}.
 
@@ -903,44 +903,44 @@ condivisione della stessa voce della \textit{file table}.
 \subsection{Operazioni atomiche con i file}
 \label{sec:file_atomic}
 
-Come si è visto in un sistema unix-like è sempre possibile per più processi
+Come si è visto in un sistema unix-like è sempre possibile per più processi
 accedere in contemporanea allo stesso file, e che le operazioni di lettura e
 scrittura possono essere fatte da ogni processo in maniera autonoma in base
-ad una posizione corrente nel file che è locale a ciascuno di essi.
+ad una posizione corrente nel file che è locale a ciascuno di essi.
 
 Se dal punto di vista della lettura dei dati questo non comporta nessun
-problema, quando si andrà a scrivere le operazioni potranno mescolarsi in
-maniera imprevedibile.  Il sistema però fornisce in alcuni casi la possibilità
+problema, quando si andrà a scrivere le operazioni potranno mescolarsi in
+maniera imprevedibile.  Il sistema però fornisce in alcuni casi la possibilità
 di eseguire alcune operazioni di scrittura in maniera coordinata anche senza
-utilizzare meccanismi di sincronizzazione più complessi (come il
+utilizzare meccanismi di sincronizzazione più complessi (come il
 \index{file!locking} \textit{file locking}, che esamineremo in
 sez.~\ref{sec:file_locking}).
 
-Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
+Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
 vari processi devono scrivere alla fine di un file (ad esempio un file di
 log). Come accennato in sez.~\ref{sec:file_lseek} impostare la posizione alla
-fine del file e poi scrivere può condurre ad una \itindex{race~condition}
-\textit{race condition}: infatti può succedere che un secondo processo scriva
+fine del file e poi scrivere può condurre ad una \itindex{race~condition}
+\textit{race condition}: infatti può succedere che un secondo processo scriva
 alla fine del file fra la \func{lseek} e la \func{write}; in questo caso, come
-abbiamo appena visto, il file sarà esteso, ma il nostro primo processo avrà
+abbiamo appena visto, il file sarà esteso, ma il nostro primo processo avrà
 ancora la posizione corrente impostata con la \func{lseek} che non corrisponde
-più alla fine del file, e la successiva \func{write} sovrascriverà i dati del
+più alla fine del file, e la successiva \func{write} sovrascriverà i dati del
 secondo processo.
 
-Il problema è che usare due system call in successione non è un'operazione
-atomica; il problema è stato risolto introducendo la modalità
+Il problema è che usare due system call in successione non è un'operazione
+atomica; il problema è stato risolto introducendo la modalità
 \itindex{append~mode} \const{O\_APPEND}. In questo caso infatti, come abbiamo
-descritto in precedenza, è il kernel che aggiorna automaticamente la posizione
+descritto in precedenza, è il kernel che aggiorna automaticamente la posizione
 alla fine del file prima di effettuare la scrittura, e poi estende il file.
 Tutto questo avviene all'interno di una singola system call (la \func{write})
 che non essendo interrompibile da un altro processo costituisce un'operazione
 atomica.
 
-Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
+Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
 creare un \textsl{file di lock} \index{file!di lock}, bloccandosi se il file
 esiste. In questo caso la sequenza logica porterebbe a verificare prima
 l'esistenza del file con una \func{stat} per poi crearlo con una \func{creat};
-di nuovo avremmo la possibilità di una \itindex{race~condition} \textit{race
+di nuovo avremmo la possibilità di una \itindex{race~condition} \textit{race
   condition} da parte di un altro processo che crea lo stesso file fra il
 controllo e la creazione.
 
@@ -962,14 +962,14 @@ sono in genere bufferizzate dal kernel, che provvede ad effettuarle in maniera
 asincrona (ad esempio accorpando gli accessi alla stessa zona del disco) in un
 secondo tempo rispetto al momento della esecuzione della \func{write}.
 
-Per questo motivo, quando è necessaria una sincronizzazione dei dati, il
+Per questo motivo, quando è necessaria una sincronizzazione dei dati, il
 sistema mette a disposizione delle funzioni che provvedono a forzare lo
-scarico dei dati dai buffer del kernel.\footnote{come già accennato neanche
-  questo dà la garanzia assoluta che i dati siano integri dopo la chiamata,
-  l'hardware dei dischi è in genere dotato di un suo meccanismo interno di
-  ottimizzazione per l'accesso al disco che può ritardare ulteriormente la
-  scrittura effettiva.} La prima di queste funzioni è \funcd{sync} il cui
-prototipo è:
+scarico dei dati dai buffer del kernel.\footnote{come già accennato neanche
+  questo dà la garanzia assoluta che i dati siano integri dopo la chiamata,
+  l'hardware dei dischi è in genere dotato di un suo meccanismo interno di
+  ottimizzazione per l'accesso al disco che può ritardare ulteriormente la
+  scrittura effettiva.} La prima di queste funzioni è \funcd{sync} il cui
+prototipo è:
 \begin{prototype}{unistd.h}{int sync(void)}
   
   Sincronizza il buffer della cache dei file col disco.
@@ -984,12 +984,12 @@ kernel.
 La funzione viene usata dal comando \cmd{sync} quando si vuole forzare
 esplicitamente lo scarico dei dati su disco, o dal demone di sistema
 \cmd{update} che esegue lo scarico dei dati ad intervalli di tempo fissi: il
-valore tradizionale, usato da BSD, per l'update dei dati è ogni 30 secondi, ma
-in Linux il valore utilizzato è di 5 secondi; con le nuove versioni\footnote{a
-  partire dal kernel 2.2.8} poi, è il kernel che si occupa direttamente di
+valore tradizionale, usato da BSD, per l'update dei dati è ogni 30 secondi, ma
+in Linux il valore utilizzato è di 5 secondi; con le nuove versioni\footnote{a
+  partire dal kernel 2.2.8} poi, è il kernel che si occupa direttamente di
 tutto quanto attraverso il demone interno \cmd{bdflush}, il cui comportamento
-può essere controllato attraverso il file \procfile{/proc/sys/vm/bdflush} (per
-il significato dei valori si può leggere la documentazione allegata al kernel
+può essere controllato attraverso il file \procfile{/proc/sys/vm/bdflush} (per
+il significato dei valori si può leggere la documentazione allegata al kernel
 in \file{Documentation/sysctl/vm.txt}).
 
 Quando si vogliono scaricare soltanto i dati di un file (ad esempio essere
@@ -1005,7 +1005,7 @@ usare le due funzioni \funcd{fsync} e \funcd{fdatasync}, i cui prototipi sono:
   \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
     errore, nel qual caso \var{errno} assume i valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] \param{fd} è un file speciale che non supporta la
+  \item[\errcode{EINVAL}] \param{fd} è un file speciale che non supporta la
     sincronizzazione.
   \end{errlist}
   ed inoltre \errval{EBADF}, \errval{EROFS} e \errval{EIO}.}
@@ -1020,7 +1020,7 @@ come i tempi del file).
 
 Si tenga presente che questo non comporta la sincronizzazione della
 directory che contiene il file (e scrittura della relativa voce su
-disco) che deve essere effettuata esplicitamente.\footnote{in realtà per
+disco) che deve essere effettuata esplicitamente.\footnote{in realtà per
   il filesystem \acr{ext2}, quando lo si monta con l'opzione \cmd{sync},
   il kernel provvede anche alla sincronizzazione automatica delle voci
   delle directory.}
@@ -1029,32 +1029,32 @@ disco) che deve essere effettuata esplicitamente.\footnote{in realt
 \subsection{Le funzioni \func{dup} e \func{dup2}}
 \label{sec:file_dup}
 
-Abbiamo già visto in sez.~\ref{sec:file_sharing} come un processo figlio
-condivida gli stessi file descriptor del padre; è possibile però ottenere un
+Abbiamo già visto in sez.~\ref{sec:file_sharing} come un processo figlio
+condivida gli stessi file descriptor del padre; è possibile però ottenere un
 comportamento analogo all'interno di uno stesso processo \textit{duplicando}
 un file descriptor. Per far questo si usa la funzione \funcd{dup} il cui
-prototipo è:
+prototipo è:
 \begin{prototype}{unistd.h}{int dup(int oldfd)}
   Crea una copia del file descriptor \param{oldfd}.
   
   \bodydesc{La funzione ritorna il nuovo file descriptor in caso di successo e
-    $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
+    $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
     valori:
   \begin{errlist}
-  \item[\errcode{EBADF}] \param{oldfd} non è un file aperto.
-  \item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
+  \item[\errcode{EBADF}] \param{oldfd} non è un file aperto.
+  \item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
     descriptor aperti.
   \end{errlist}}
 \end{prototype}
 
 La funzione ritorna, come \func{open}, il primo file descriptor libero. Il
-file descriptor è una copia esatta del precedente ed entrambi possono essere
+file descriptor è una copia esatta del precedente ed entrambi possono essere
 interscambiati nell'uso. Per capire meglio il funzionamento della funzione si
-può fare riferimento a fig.~\ref{fig:file_dup}: l'effetto della funzione è
+può fare riferimento a fig.~\ref{fig:file_dup}: l'effetto della funzione è
 semplicemente quello di copiare il valore nella struttura
-\struct{file\_struct}, cosicché anche il nuovo file descriptor fa riferimento
+\struct{file\_struct}, cosicché anche il nuovo file descriptor fa riferimento
 alla stessa voce nella \textit{file table}; per questo si dice che il nuovo
-file descriptor è \textsl{duplicato}, da cui il nome della funzione.
+file descriptor è \textsl{duplicato}, da cui il nome della funzione.
 
 \begin{figure}[htb]
   \centering \includegraphics[width=14cm]{img/filedup}
@@ -1065,102 +1065,102 @@ file descriptor 
 Si noti che per quanto illustrato in fig.~\ref{fig:file_dup} i file descriptor
 duplicati condivideranno eventuali lock, \textit{file status flag}, e
 posizione corrente. Se ad esempio si esegue una \func{lseek} per modificare la
-posizione su uno dei due file descriptor, essa risulterà modificata anche
-sull'altro (dato che quello che viene modificato è lo stesso campo nella voce
+posizione su uno dei due file descriptor, essa risulterà modificata anche
+sull'altro (dato che quello che viene modificato è lo stesso campo nella voce
 della \textit{file table} a cui entrambi fanno riferimento). L'unica
-differenza fra due file descriptor duplicati è che ciascuno avrà il suo
+differenza fra due file descriptor duplicati è che ciascuno avrà il suo
 \textit{file descriptor flag}; a questo proposito va specificato che nel caso
 di \func{dup} il flag di \textit{close-on-exec} \itindex{close-on-exec} (vedi
 sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl}) viene sempre cancellato
 nella copia.
 
-L'uso principale di questa funzione è per la redirezione dell'input e
+L'uso principale di questa funzione è per la redirezione dell'input e
 dell'output fra l'esecuzione di una \func{fork} e la successiva \func{exec};
-diventa così possibile associare un file (o una pipe) allo standard input o
+diventa così possibile associare un file (o una pipe) allo standard input o
 allo standard output (torneremo sull'argomento in sez.~\ref{sec:ipc_pipe_use},
 quando tratteremo le pipe). Per fare questo in genere occorre prima chiudere
-il file che si vuole sostituire, cosicché il suo file descriptor possa esser
+il file che si vuole sostituire, cosicché il suo file descriptor possa esser
 restituito alla chiamata di \func{dup}, come primo file descriptor
 disponibile.
 
-Dato che questa è l'operazione più comune, è prevista una diversa versione
+Dato che questa è l'operazione più comune, è prevista una diversa versione
 della funzione, \funcd{dup2}, che permette di specificare esplicitamente
-qual è il valore di file descriptor che si vuole avere come duplicato; il suo
-prototipo è:
+qual è il valore di file descriptor che si vuole avere come duplicato; il suo
+prototipo è:
 \begin{prototype}{unistd.h}{int dup2(int oldfd, int newfd)}
   
   Rende \param{newfd} una copia del file descriptor \param{oldfd}.
   
   \bodydesc{La funzione ritorna il nuovo file descriptor in caso di successo e
-    $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+    $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EBADF}] \param{oldfd} non è un file aperto o \param{newfd} ha
+  \item[\errcode{EBADF}] \param{oldfd} non è un file aperto o \param{newfd} ha
     un valore fuori dall'intervallo consentito per i file descriptor.
-  \item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
+  \item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
     descriptor aperti.
   \end{errlist}}
 \end{prototype}
-\noindent e qualora il file descriptor \param{newfd} sia già aperto (come
+\noindent e qualora il file descriptor \param{newfd} sia già aperto (come
 avviene ad esempio nel caso della duplicazione di uno dei file standard) esso
-sarà prima chiuso e poi duplicato (così che il file duplicato sarà connesso
+sarà prima chiuso e poi duplicato (così che il file duplicato sarà connesso
 allo stesso valore per il file descriptor).
 
-La duplicazione dei file descriptor può essere effettuata anche usando la
+La duplicazione dei file descriptor può essere effettuata anche usando la
 funzione di controllo dei file \func{fcntl} (che esamineremo in
 sez.~\ref{sec:file_fcntl}) con il parametro \const{F\_DUPFD}.  L'operazione ha
 la sintassi \code{fcntl(oldfd, F\_DUPFD, newfd)} e se si usa 0 come valore per
 \param{newfd} diventa equivalente a \func{dup}. 
 
 La sola differenza fra le due funzioni\footnote{a parte la sintassi ed i
-  diversi codici di errore.} è che \func{dup2} chiude il file descriptor
-\param{newfd} se questo è già aperto, garantendo che la duplicazione sia
+  diversi codici di errore.} è che \func{dup2} chiude il file descriptor
+\param{newfd} se questo è già aperto, garantendo che la duplicazione sia
 effettuata esattamente su di esso, invece \func{fcntl} restituisce il primo
 file descriptor libero di valore uguale o maggiore di \param{newfd} (e se
-\param{newfd} è aperto la duplicazione avverrà su un altro file descriptor).
+\param{newfd} è aperto la duplicazione avverrà su un altro file descriptor).
 
 
 
 \subsection{Le funzioni \func{openat}, \func{mkdirat} e affini}
 \label{sec:file_openat}
 
-Un problema che si pone con l'uso della funzione \func{open}, così come per
-molte altre funzioni che accettano come argomenti dei pathname relativi, è
+Un problema che si pone con l'uso della funzione \func{open}, così come per
+molte altre funzioni che accettano come argomenti dei pathname relativi, è
 che, quando un pathname relativo non fa riferimento alla directory di lavoro
-corrente, è possibile che alcuni dei suoi componenti vengano modificati in
-parallelo alla chiamata a \func{open}, e questo lascia aperta la possibilità
+corrente, è possibile che alcuni dei suoi componenti vengano modificati in
+parallelo alla chiamata a \func{open}, e questo lascia aperta la possibilità
 di una \itindex{race~condition} \textit{race condition}.
 
-Inoltre come già accennato, la directory di lavoro corrente è una proprietà
+Inoltre come già accennato, la directory di lavoro corrente è una proprietà
 del singolo processo; questo significa che quando si lavora con i
-\itindex{thread} \textit{thread} essa sarà la stessa per tutti, ma esistono
+\itindex{thread} \textit{thread} essa sarà la stessa per tutti, ma esistono
 molti casi in cui sarebbe invece utile che ogni singolo \itindex{thread}
 \textit{thread} avesse la sua directory di lavoro.
 
-Per risolvere questi problemi, riprendendo una interfaccia già presente in
+Per risolvere questi problemi, riprendendo una interfaccia già presente in
 Solaris, a fianco delle normali funzioni che operano sui file (come
 \func{open}, \func{mkdir}, ecc.) sono state introdotte delle ulteriori
 funzioni, contraddistinte dal suffisso \texttt{at}, che permettono l'apertura
 di un file (o le rispettive altre operazioni) usando un pathname relativo ad
-una directory specificata.\footnote{l'introduzione è avvenuta su proposta
+una directory specificata.\footnote{l'introduzione è avvenuta su proposta
   dello sviluppatore principale delle \acr{glibc} Urlich Drepper; le
   corrispondenti system call sono state inserite nel kernel ufficiale a
   partire dalla versione 2.6.16, in precedenza era disponibile una emulazione
   che, sia pure con prestazioni inferiori, funzionava facendo ricorso all'uso
   del filesystem \textit{proc} con l'apertura del file attraverso il
   riferimento a pathname del tipo di
-  \texttt{/proc/self/fd/dirfd/relative\_path}.} Benché queste funzioni non
+  \texttt{/proc/self/fd/dirfd/relative\_path}.} Benché queste funzioni non
 siano presenti negli standard tradizionali esse sono state adottate da vari
 Unix\footnote{oltre a Linux e Solaris sono presenti in vari BSD.} fino ad
 essere incluse nella recente revisione (la POSIX.1-2008) dello standard
-POSIX.1; con le \acr{glibc} per l'accesso a queste funzioni è necessario
+POSIX.1; con le \acr{glibc} per l'accesso a queste funzioni è necessario
 definire la macro \macro{\_ATFILE\_SOURCE}.
 
 L'uso di queste funzioni prevede una apertura iniziale della directory che
-sarà la base della risoluzione dei pathname relativi che verranno usati in
-seguito, dopo di che si dovrà passare il relativo file descriptor alle varie
+sarà la base della risoluzione dei pathname relativi che verranno usati in
+seguito, dopo di che si dovrà passare il relativo file descriptor alle varie
 funzioni che useranno quella directory come punto di partenza per la
 risoluzione.\footnote{in questo modo, anche quando si lavora con i
-  \itindex{thread} \textit{thread}, si può mantenere una directory di lavoro
+  \itindex{thread} \textit{thread}, si può mantenere una directory di lavoro
   diversa per ciascuno di essi.} 
 
 Questo metodo, oltre a risolvere i problemi di \itindex{race~condition}
@@ -1171,10 +1171,10 @@ profonde; infatti in questo caso basta eseguire la risoluzione del pathname
 della directory di partenza una sola volta (nell'apertura iniziale) e non
 tutte le volte che si deve accedere a ciascun file che essa contiene.
 
-La sintassi generale di queste nuove funzioni è che esse prevedono come primo
+La sintassi generale di queste nuove funzioni è che esse prevedono come primo
 argomento il file descriptor della directory da usare come base, mentre gli
 argomenti successivi restano identici a quelli della corrispondente funzione
-ordinaria; ad esempio nel caso di \funcd{openat} avremo che essa è definita
+ordinaria; ad esempio nel caso di \funcd{openat} avremo che essa è definita
 come:
 \begin{functions}
   \headdecl{fcntl.h}
@@ -1185,37 +1185,37 @@ come:
   Apre un file usando come directory di lavoro corrente \param{dirfd}.
   
   \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
-    errore di \func{open}, ed in più:
+    errore di \func{open}, ed in più:
   \begin{errlist}
-  \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
-  \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
+  \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
+  \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
     \param{dirfd} fa riferimento ad un file. 
   \end{errlist}}
 \end{functions}
 
-Il comportamento delle nuove funzioni è del tutto analogo a quello delle
+Il comportamento delle nuove funzioni è del tutto analogo a quello delle
 corrispettive classiche, con la sola eccezione del fatto che se fra i loro
-argomenti si utilizza un pathname relativo questo sarà risolto rispetto alla
+argomenti si utilizza un pathname relativo questo sarà risolto rispetto alla
 directory indicata da \param{dirfd}; qualora invece si usi un pathname
-assoluto \param{dirfd} verrà semplicemente ignorato. Infine se per
+assoluto \param{dirfd} verrà semplicemente ignorato. Infine se per
 \param{dirfd} si usa il valore speciale \const{AT\_FDCWD},\footnote{questa,
-  come le altre costanti \texttt{AT\_*}, è definita in \texttt{fcntl.h},
-  pertanto se la si vuole usare occorrerà includere comunque questo file,
-  anche per le funzioni che non sono definite in esso.} la risoluzione sarà
+  come le altre costanti \texttt{AT\_*}, è definita in \texttt{fcntl.h},
+  pertanto se la si vuole usare occorrerà includere comunque questo file,
+  anche per le funzioni che non sono definite in esso.} la risoluzione sarà
 effettuata rispetto alla directory di lavoro corrente del processo.
 
-Così come il comportamento, anche i valori di ritorno e le condizioni di
+Così come il comportamento, anche i valori di ritorno e le condizioni di
 errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
-errori si aggiungono però quelli dovuti a valori errati per \param{dirfd}; in
-particolare si avrà un errore di \errcode{EBADF} se esso non è un file
+errori si aggiungono però quelli dovuti a valori errati per \param{dirfd}; in
+particolare si avrà un errore di \errcode{EBADF} se esso non è un file
 descriptor valido, ed un errore di \errcode{ENOTDIR} se esso non fa riferimento
 ad una directory.\footnote{tranne il caso in cui si sia specificato un
   pathname assoluto, nel qual caso, come detto, il valore di \param{dirfd}
-  sarà completamente ignorato.}
+  sarà completamente ignorato.}
 
 In tab.~\ref{tab:file_atfunc_corr} si sono riportate le funzioni introdotte
 con questa nuova interfaccia, con a fianco la corrispondente funzione
-classica.\footnote{in realtà, come visto in sez.~\ref{sec:file_temp_file}, le
+classica.\footnote{in realtà, come visto in sez.~\ref{sec:file_temp_file}, le
   funzioni \func{utimes} e \func{lutimes} non sono propriamente le
   corrispondenti di \func{utimensat}, dato che questa ha una maggiore
   precisione nella indicazione dei tempi dei file.} La gran parte di queste
@@ -1223,7 +1223,7 @@ seguono la convenzione appena vista per \func{openat}, in cui agli argomenti
 della corrispondente funzione classica viene anteposto
 l'argomento \param{dirfd}.\footnote{non staremo pertanto a riportarle una per
   una.} Per una parte di queste, indicate dal contenuto della omonima colonna
-di tab.~\ref{tab:file_atfunc_corr}, oltre al nuovo argomento iniziale, è
+di tab.~\ref{tab:file_atfunc_corr}, oltre al nuovo argomento iniziale, è
 prevista anche l'aggiunta di un ulteriore argomento finale, \param{flags}.
 
 \begin{table}[htb]
@@ -1255,45 +1255,45 @@ prevista anche l'aggiunta di un ulteriore argomento finale, \param{flags}.
   \label{tab:file_atfunc_corr}
 \end{table}
 
-\footnotetext{in questo caso l'argomento \param{flags} è disponibile ed
+\footnotetext{in questo caso l'argomento \param{flags} è disponibile ed
   utilizzabile solo a partire dal kernel 2.6.18.}
 
 Per tutte le funzioni che lo prevedono, a parte \func{unlinkat} e
-\funcd{faccessat}, l'ulteriore argomento è stato introdotto solo per fornire
+\funcd{faccessat}, l'ulteriore argomento è stato introdotto solo per fornire
 un meccanismo con cui modificarne il comportamento nel caso si stia operando
-su un link simbolico, così da poter scegliere se far agire la funzione
+su un link simbolico, così da poter scegliere se far agire la funzione
 direttamente sullo stesso o sul file da esso referenziato. Dato che in certi
-casi esso può fornire ulteriori indicazioni per modificare il comportamento
+casi esso può fornire ulteriori indicazioni per modificare il comportamento
 delle funzioni, \param{flags} deve comunque essere passato come maschera
 binaria, ed impostato usando i valori delle appropriate costanti
 \texttt{AT\_*}, definite in \texttt{fcntl.h}.
 
 Come esempio di questo secondo tipo di funzioni possiamo considerare
-\funcd{fchownat}, che può essere usata per sostituire sia \func{chown}
-che \func{lchown}; il suo prototipo è:
+\funcd{fchownat}, che può essere usata per sostituire sia \func{chown}
+che \func{lchown}; il suo prototipo è:
 \begin{functions}
   \headdecl{unistd.h} \headdecl{fcntl.h} 
 
   \funcdecl{int fchownat(int dirfd, const char *pathname, uid\_t owner, gid\_t
     group, int flags)}
 
-  .Modifica la proprietà di un file.
+  .Modifica la proprietà di un file.
   
   \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
-    errore di \func{chown}, ed in più:
+    errore di \func{chown}, ed in più:
   \begin{errlist}
-  \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
+  \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
   \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
-  \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
+  \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
     \param{dirfd} fa riferimento ad un file. 
   \end{errlist}}
 \end{functions}
 
 In questo caso il valore di \param{flags} stabilisce il comportamento della
 funzione quando la si applica ad un link simbolico, e l'unico valore
-utilizzabile è \const{AT\_SYMLINK\_NOFOLLOW}\footnote{in \texttt{fcntl.h} è
+utilizzabile è \const{AT\_SYMLINK\_NOFOLLOW}\footnote{in \texttt{fcntl.h} è
   definito anche \const{AT\_SYMLINK\_FOLLOW}, che richiede di dereferenziare i
-  link simbolici, essendo questo però il comportamento adottato per un valore
+  link simbolici, essendo questo però il comportamento adottato per un valore
   nullo di \param{flags} questo valore non viene mai usato.} che se impostato
 indica alla funzione di non eseguire la dereferenziazione di un eventuale link
 simbolico, facendo comportare \func{fchownat} come \func{lchown} invece che
@@ -1301,8 +1301,8 @@ come \func{chown}.
 
 Come accennato fra tutte quelle marcate in tab.~\ref{tab:file_atfunc_corr}
 solo due funzioni possono usare l'argomento \param{flags} con valori diversi
-da \const{AT\_SYMLINK\_NOFOLLOW}, la prima di queste è \funcd{faccessat}, ed
-il suo prototipo è:
+da \const{AT\_SYMLINK\_NOFOLLOW}, la prima di queste è \funcd{faccessat}, ed
+il suo prototipo è:
 \begin{functions}
   \headdecl{unistd.h}
   \funcdecl{int faccessat(int dirfd, const char *path, int mode, int flags)}
@@ -1310,19 +1310,19 @@ il suo prototipo 
   Controlla i permessi di accesso.
   
   \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
-    errore di \func{access}, ed in più:
+    errore di \func{access}, ed in più:
   \begin{errlist}
-  \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
+  \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
   \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
-  \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
+  \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
     \param{dirfd} fa riferimento ad un file. 
   \end{errlist}}
 \end{functions}
 
 La funzione esegue lo stesso controllo di accesso effettuabile con
-\func{access}, ma si può utilizzare l'argomento \param{flags} per modificarne
+\func{access}, ma si può utilizzare l'argomento \param{flags} per modificarne
 il comportamento rispetto a quello ordinario di \func{access}. In questo caso
-esso può essere specificato come maschera binaria di due valori:
+esso può essere specificato come maschera binaria di due valori:
 \begin{basedescript}{\desclabelwidth{3.0cm}}
 \item[\const{AT\_EACCESS}] se impostato \funcd{faccessat} esegue il controllo
   dei permessi usando l'\textsl{user-ID effettivo} invece di quello reale (il
@@ -1332,10 +1332,10 @@ esso pu
   permessi direttamente sugli stessi.
 \end{basedescript}
 
-La seconda eccezione è \func{unlinkat}, in questo caso l'ulteriore
-argomento \param{flags} viene utilizzato perché tramite esso la funzione possa
+La seconda eccezione è \func{unlinkat}, in questo caso l'ulteriore
+argomento \param{flags} viene utilizzato perché tramite esso la funzione possa
 comportarsi sia come analogo di \func{unlink} che di \func{rmdir}; il suo
-prototipo è:
+prototipo è:
 \begin{functions}
   \headdecl{fcntl.h}
   \funcdecl{int unlinkat(int dirfd, const char *pathname, int flags)}
@@ -1344,22 +1344,22 @@ prototipo 
   
   \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
     errore di \func{unlink} o di \func{rmdir} a seconda del valore di
-    \param{flags}, ed in più:
+    \param{flags}, ed in più:
   \begin{errlist}
-  \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
+  \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
   \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
-  \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
+  \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
     \param{dirfd} fa riferimento ad un file. 
   \end{errlist}}
 \end{functions}
 
-Di default il comportamento di \func{unlinkat} è equivalente a quello che
+Di default il comportamento di \func{unlinkat} è equivalente a quello che
 avrebbe \func{unlink} applicata a \param{pathname}, fallendo in tutti i casi
-in cui questo è una directory, se però si imposta \param{flags} al valore di
-\const{AT\_REMOVEDIR},\footnote{anche se \param{flags} è una maschera binaria,
-  essendo questo l'unico flag disponibile per questa funzione, lo si può
-  assegnare direttamente.}  essa si comporterà come \func{rmdir}, in tal
-caso \param{pathname} deve essere una directory, che sarà rimossa qualora
+in cui questo è una directory, se però si imposta \param{flags} al valore di
+\const{AT\_REMOVEDIR},\footnote{anche se \param{flags} è una maschera binaria,
+  essendo questo l'unico flag disponibile per questa funzione, lo si può
+  assegnare direttamente.}  essa si comporterà come \func{rmdir}, in tal
+caso \param{pathname} deve essere una directory, che sarà rimossa qualora
 risulti vuota.
 
 
@@ -1367,17 +1367,17 @@ risulti vuota.
 \label{sec:file_fcntl}
 
 Oltre alle operazioni base esaminate in sez.~\ref{sec:file_base_func} esistono
-tutta una serie di operazioni ausiliarie che è possibile eseguire su un file
+tutta una serie di operazioni ausiliarie che è possibile eseguire su un file
 descriptor, che non riguardano la normale lettura e scrittura di dati, ma la
-gestione sia delle loro proprietà, che di tutta una serie di ulteriori
-funzionalità che il kernel può mettere a disposizione.\footnote{ad esempio si
-  gestiscono con questa funzione varie modalità di I/O asincrono (vedi
+gestione sia delle loro proprietà, che di tutta una serie di ulteriori
+funzionalità che il kernel può mettere a disposizione.\footnote{ad esempio si
+  gestiscono con questa funzione varie modalità di I/O asincrono (vedi
   sez.~\ref{sec:file_asyncronous_operation}) e il \index{file!locking}
   \textit{file locking} (vedi sez.~\ref{sec:file_locking}).}
 
-Per queste operazioni di manipolazione e di controllo delle varie proprietà e
+Per queste operazioni di manipolazione e di controllo delle varie proprietà e
 caratteristiche di un file descriptor, viene usata la funzione \funcd{fcntl},
-il cui prototipo è:
+il cui prototipo è:
 \begin{functions}
   \headdecl{unistd.h}
   \headdecl{fcntl.h}
@@ -1388,42 +1388,42 @@ il cui prototipo 
   sul file \param{fd}.
   
   \bodydesc{La funzione ha valori di ritorno diversi a seconda
-    dell'operazione. In caso di errore il valore di ritorno è sempre $-1$ ed
-    il codice dell'errore è restituito nella variabile \var{errno}; i codici
-    possibili dipendono dal tipo di operazione, l'unico valido in generale è:
+    dell'operazione. In caso di errore il valore di ritorno è sempre $-1$ ed
+    il codice dell'errore è restituito nella variabile \var{errno}; i codici
+    possibili dipendono dal tipo di operazione, l'unico valido in generale è:
   \begin{errlist}
-  \item[\errcode{EBADF}] \param{fd} non è un file aperto.
+  \item[\errcode{EBADF}] \param{fd} non è un file aperto.
   \end{errlist}}
 \end{functions}
 
 
-Il primo argomento della funzione è sempre il numero di file descriptor
+Il primo argomento della funzione è sempre il numero di file descriptor
 \var{fd} su cui si vuole operare. Il comportamento di questa funzione, il
 numero e il tipo degli argomenti, il valore di ritorno e gli eventuali errori
 sono determinati dal valore dell'argomento \param{cmd} che in sostanza
 corrisponde all'esecuzione di un determinato \textsl{comando}; in
 sez.~\ref{sec:file_dup} abbiamo incontrato un esempio dell'uso di \func{fcntl}
 per la duplicazione dei file descriptor, una lista di tutti i possibili valori
-per \var{cmd} è riportata di seguito:
+per \var{cmd} è riportata di seguito:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\const{F\_DUPFD}] trova il primo file descriptor disponibile di valore
   maggiore o uguale ad \param{arg} e ne fa una copia di \param{fd}. Ritorna il
   nuovo file descriptor in caso di successo e $-1$ in caso di errore. Gli
-  errori possibili sono \errcode{EINVAL} se \param{arg} è negativo o maggiore
-  del massimo consentito o \errcode{EMFILE} se il processo ha già raggiunto il
+  errori possibili sono \errcode{EINVAL} se \param{arg} è negativo o maggiore
+  del massimo consentito o \errcode{EMFILE} se il processo ha già raggiunto il
   massimo numero di descrittori consentito.
 \item[\const{F\_SETFD}] imposta il valore del \textit{file descriptor flag} al
-  valore specificato con \param{arg}. Al momento l'unico bit usato è quello di
+  valore specificato con \param{arg}. Al momento l'unico bit usato è quello di
   \itindex{close-on-exec} \textit{close-on-exec}, identificato dalla costante
   \const{FD\_CLOEXEC}, che serve a richiedere che il file venga chiuso nella
   esecuzione di una \func{exec} (vedi sez.~\ref{sec:proc_exec}).  Ritorna un
   valore nullo in caso di successo e $-1$ in caso di errore.
 \item[\const{F\_GETFD}] ritorna il valore del \textit{file descriptor flag} di
-  \param{fd} o $-1$ in caso di errore; se \const{FD\_CLOEXEC} è impostato i
+  \param{fd} o $-1$ in caso di errore; se \const{FD\_CLOEXEC} è impostato i
   file descriptor aperti vengono chiusi attraverso una \func{exec} altrimenti
   (il comportamento predefinito) restano aperti.
 \item[\const{F\_GETFL}] ritorna il valore del \textit{file status flag} in
-  caso di successo o $-1$ in caso di errore; permette cioè di rileggere quei
+  caso di successo o $-1$ in caso di errore; permette cioè di rileggere quei
   bit impostati da \func{open} all'apertura del file che vengono memorizzati
   (quelli riportati nella prima e terza sezione di
   tab.~\ref{tab:file_open_flags}).
@@ -1436,25 +1436,25 @@ per \var{cmd} 
 \item[\const{F\_GETLK}] richiede un controllo sul file lock specificato da
   \param{lock}, sovrascrivendo la struttura da esso puntata con il risultato;
   ritorna un valore nullo in caso di successo o $-1$ in caso di errore.  Questa
-  funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
+  funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
 \item[\const{F\_SETLK}] richiede o rilascia un file lock a seconda di quanto
-  specificato nella struttura puntata da \param{lock}. Se il lock è tenuto da
+  specificato nella struttura puntata da \param{lock}. Se il lock è tenuto da
   qualcun altro ritorna immediatamente restituendo $-1$ e imposta \var{errno} a
   \errcode{EACCES} o \errcode{EAGAIN}, in caso di successo ritorna un valore
-  nullo. Questa funzionalità è trattata in dettaglio in
+  nullo. Questa funzionalità è trattata in dettaglio in
   sez.~\ref{sec:file_posix_lock}.
 \item[\const{F\_SETLKW}] identica a \const{F\_SETLK} eccetto per il fatto che
   la funzione non ritorna subito ma attende che il blocco sia rilasciato. Se
   l'attesa viene interrotta da un segnale la funzione restituisce $-1$ e
   imposta \var{errno} a \errcode{EINTR}, in caso di successo ritorna un valore
-  nullo.  Questa funzionalità è trattata in dettaglio in
+  nullo.  Questa funzionalità è trattata in dettaglio in
   sez.~\ref{sec:file_posix_lock}.
 \item[\const{F\_GETOWN}] restituisce il \acr{pid} del processo o
   l'identificatore del \itindex{process~group} \textit{process
     group}\footnote{i \itindex{process~group} \textit{process group} sono
     (vedi sez.~\ref{sec:sess_proc_group}) raggruppamenti di processi usati nel
-    controllo di sessione; a ciascuno di essi è associato un identificatore
-    (un numero positivo analogo al \acr{pid}).} che è preposto alla ricezione
+    controllo di sessione; a ciascuno di essi è associato un identificatore
+    (un numero positivo analogo al \acr{pid}).} che è preposto alla ricezione
   dei segnali \const{SIGIO}\footnote{o qualunque altro segnale alternativo
     impostato con \const{F\_FSETSIG}.} per gli eventi associati al file
   descriptor \param{fd}\footnote{il segnale viene usato sia per il
@@ -1469,7 +1469,7 @@ per \var{cmd} 
   caso di errore viene restituito $-1$.
 \item[\const{F\_SETOWN}] imposta, con il valore dell'argomento \param{arg},
   l'identificatore del processo o del \itindex{process~group} \textit{process
-    group} che riceverà i segnali \const{SIGIO}  e \const{SIGURG} per gli
+    group} che riceverà i segnali \const{SIGIO}  e \const{SIGURG} per gli
   eventi associati al file descriptor \param{fd}, ritorna un valore nullo in
   caso di successo o $-1$ in caso di errore.  Come per \const{F\_GETOWN}, per
   impostare un \itindex{process~group} \textit{process group} si deve usare
@@ -1478,15 +1478,15 @@ per \var{cmd} 
 \item[\const{F\_GETSIG}] restituisce il valore del segnale inviato quando ci
   sono dati disponibili in ingresso su un file descriptor aperto ed impostato
   per l'I/O asincrono (si veda sez.~\ref{sec:file_asyncronous_io}). Il valore 0
-  indica il valore predefinito (che è \const{SIGIO}), un valore diverso da
-  zero indica il segnale richiesto, (che può essere anche lo stesso
+  indica il valore predefinito (che è \const{SIGIO}), un valore diverso da
+  zero indica il segnale richiesto, (che può essere anche lo stesso
   \const{SIGIO}). In caso di errore ritorna $-1$.
 \item[\const{F\_SETSIG}] imposta il segnale da inviare quando diventa
   possibile effettuare I/O sul file descriptor in caso di I/O asincrono,
   ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Il
   valore zero indica di usare il segnale predefinito, \const{SIGIO}. Un altro
   valore diverso da zero (compreso lo stesso \const{SIGIO}) specifica il
-  segnale voluto; l'uso di un valore diverso da zero permette inoltre, se si è
+  segnale voluto; l'uso di un valore diverso da zero permette inoltre, se si è
   installato il gestore del segnale come \var{sa\_sigaction} usando
   \const{SA\_SIGINFO}, (vedi sez.~\ref{sec:sig_sigaction}), di rendere
   disponibili al gestore informazioni ulteriori riguardo il file che ha
@@ -1495,47 +1495,47 @@ per \var{cmd} 
     \const{F\_SETSIG} e \const{F\_GETSIG} sono una estensione specifica di
     Linux.}
 \item[\const{F\_SETLEASE}] imposta o rimuove un \index{file!lease}
-  \textit{file lease}\footnote{questa è una nuova funzionalità, specifica di
+  \textit{file lease}\footnote{questa è una nuova funzionalità, specifica di
     Linux, e presente solo a partire dai kernel della serie 2.4.x, in cui il
     processo che detiene un \textit{lease} su un file riceve una notifica
     qualora un altro processo cerca di eseguire una \func{open} o una
     \func{truncate} su di esso.} sul file descriptor \var{fd} a seconda del
-  valore del terzo argomento, che in questo caso è un \ctyp{int}, ritorna un
+  valore del terzo argomento, che in questo caso è un \ctyp{int}, ritorna un
   valore nullo in caso di successo o $-1$ in caso di errore. Questa
-  funzionalità avanzata è trattata in dettaglio in
+  funzionalità avanzata è trattata in dettaglio in
   sez.~\ref{sec:file_asyncronous_lease}.
 \item[\const{F\_GETLEASE}] restituisce il tipo di \index{file!lease}
   \textit{file lease} che il processo detiene nei confronti del file
   descriptor \var{fd} o $-1$ in caso di errore. Con questo comando il terzo
-  argomento può essere omesso. Questa funzionalità avanzata è trattata in
+  argomento può essere omesso. Questa funzionalità avanzata è trattata in
   dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
 \item[\const{F\_NOTIFY}] attiva un meccanismo di notifica per cui viene
   riportata al processo chiamante, tramite il segnale \const{SIGIO} (o altro
   segnale specificato con \const{F\_SETSIG}) ogni modifica eseguita o
   direttamente sulla directory cui \var{fd} fa riferimento, o su uno dei file
   in essa contenuti; ritorna un valore nullo in caso di successo o $-1$ in caso
-  di errore. Questa funzionalità avanzata, disponibile dai kernel della serie
-  2.4.x, è trattata in dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
+  di errore. Questa funzionalità avanzata, disponibile dai kernel della serie
+  2.4.x, è trattata in dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
 \end{basedescript}
 
-La maggior parte delle funzionalità di \func{fcntl} sono troppo avanzate per
+La maggior parte delle funzionalità di \func{fcntl} sono troppo avanzate per
 poter essere affrontate in tutti i loro aspetti a questo punto; saranno
-pertanto riprese più avanti quando affronteremo le problematiche ad esse
+pertanto riprese più avanti quando affronteremo le problematiche ad esse
 relative. In particolare le tematiche relative all'I/O asincrono e ai vari
 meccanismi di notifica saranno trattate in maniera esaustiva in
 sez.~\ref{sec:file_asyncronous_access} mentre quelle relative al
 \index{file!locking} \textit{file locking} saranno esaminate in
-sez.~\ref{sec:file_locking}). L'uso di questa funzione con i socket verrà
+sez.~\ref{sec:file_locking}). L'uso di questa funzione con i socket verrà
 trattato in sez.~\ref{sec:sock_ctrl_func}.
 
 Si tenga presente infine che quando si usa la funzione per determinare le
-modalità di accesso con cui è stato aperto il file (attraverso l'uso del
-comando \const{F\_GETFL}) è necessario estrarre i bit corrispondenti nel
-\textit{file status flag} che si è ottenuto.  Infatti la definizione corrente
-di quest'ultimo non assegna bit separati alle tre diverse modalità
+modalità di accesso con cui è stato aperto il file (attraverso l'uso del
+comando \const{F\_GETFL}) è necessario estrarre i bit corrispondenti nel
+\textit{file status flag} che si è ottenuto.  Infatti la definizione corrente
+di quest'ultimo non assegna bit separati alle tre diverse modalità
 \const{O\_RDONLY}, \const{O\_WRONLY} e \const{O\_RDWR}.\footnote{in Linux
   queste costanti sono poste rispettivamente ai valori 0, 1 e 2.} Per questo
-motivo il valore della modalità di accesso corrente si ottiene eseguendo un
+motivo il valore della modalità di accesso corrente si ottiene eseguendo un
 AND binario del valore di ritorno di \func{fcntl} con la maschera
 \const{O\_ACCMODE} (anch'essa definita in \file{fcntl.h}), che estrae i bit di
 accesso dal \textit{file status flag}.
@@ -1545,31 +1545,31 @@ accesso dal \textit{file status flag}.
 \subsection{La funzione \func{ioctl}}
 \label{sec:file_ioctl}
 
-Benché il concetto di \textit{everything is a file} si sia dimostrato molto
-valido anche per l'interazione con i dispositivi più vari, fornendo una
+Benché il concetto di \textit{everything is a file} si sia dimostrato molto
+valido anche per l'interazione con i dispositivi più vari, fornendo una
 interfaccia che permette di interagire con essi tramite le stesse funzioni
 usate per i normali file di dati, esisteranno sempre caratteristiche
-peculiari, specifiche dell'hardware e della funzionalità che ciascun
-dispositivo può provvedere, che non possono venire comprese in questa
-interfaccia astratta (un caso tipico è l'impostazione della velocità di una
+peculiari, specifiche dell'hardware e della funzionalità che ciascun
+dispositivo può provvedere, che non possono venire comprese in questa
+interfaccia astratta (un caso tipico è l'impostazione della velocità di una
 porta seriale, o le dimensioni di un framebuffer).
 
-Per questo motivo nell'architettura del sistema è stata prevista l'esistenza
+Per questo motivo nell'architettura del sistema è stata prevista l'esistenza
 di una funzione apposita, \funcd{ioctl}, con cui poter compiere le operazioni
 specifiche di ogni dispositivo particolare, usando come riferimento il solito
-file descriptor.  Il prototipo di questa funzione è:
+file descriptor.  Il prototipo di questa funzione è:
 \begin{prototype}{sys/ioctl.h}{int ioctl(int fd, int request, ...)}  
 
   Esegue l'operazione di controllo specificata da \param{request} sul file
   descriptor \param{fd}.
   
   \bodydesc{La funzione nella maggior parte dei casi ritorna 0, alcune
-    operazioni usano però il valore di ritorno per restituire informazioni. In
-    caso di errore viene sempre restituito $-1$ ed \var{errno} assumerà uno dei
+    operazioni usano però il valore di ritorno per restituire informazioni. In
+    caso di errore viene sempre restituito $-1$ ed \var{errno} assumerà uno dei
     valori:
   \begin{errlist}
-  \item[\errcode{ENOTTY}] il file \param{fd} non è associato con un
-    dispositivo, o la richiesta non è applicabile all'oggetto a cui fa
+  \item[\errcode{ENOTTY}] il file \param{fd} non è associato con un
+    dispositivo, o la richiesta non è applicabile all'oggetto a cui fa
     riferimento \param{fd}.
   \item[\errcode{EINVAL}] gli argomenti \param{request} o \param{argp} non sono
     validi.
@@ -1579,31 +1579,31 @@ file descriptor.  Il prototipo di questa funzione 
 
 La funzione serve in sostanza come meccanismo generico per fare tutte quelle
 operazioni che non rientrano nell'interfaccia ordinaria della gestione dei
-file e che non è possibile effettuare con le funzioni esaminate finora. La
+file e che non è possibile effettuare con le funzioni esaminate finora. La
 funzione richiede che si passi come primo argomento un file descriptor
 regolarmente aperto, e l'operazione da compiere viene selezionata attraverso
 il valore dell'argomento \param{request}. Il terzo argomento dipende
-dall'operazione prescelta; tradizionalmente è specificato come \code{char *
+dall'operazione prescelta; tradizionalmente è specificato come \code{char *
   argp}, da intendersi come puntatore ad un area di memoria
 generica,\footnote{all'epoca della creazione di questa funzione infatti ancora
-  non era stato introdotto il tipo \ctyp{void}.} ma per certe operazioni può
-essere omesso, e per altre è un semplice intero.
+  non era stato introdotto il tipo \ctyp{void}.} ma per certe operazioni può
+essere omesso, e per altre è un semplice intero.
 
 Normalmente la funzione ritorna zero in caso di successo e $-1$ in caso di
 errore, ma per alcune operazione il valore di ritorno, che nel caso viene
-impostato ad un valore positivo, può essere utilizzato come parametro di
-uscita. È più comune comunque restituire i risultati all'indirizzo puntato dal
+impostato ad un valore positivo, può essere utilizzato come parametro di
+uscita. È più comune comunque restituire i risultati all'indirizzo puntato dal
 terzo argomento.
 
-Data la genericità dell'interfaccia non è possibile classificare in maniera
+Data la genericità dell'interfaccia non è possibile classificare in maniera
 sistematica le operazioni che si possono gestire con \func{ioctl}, un breve
-elenco di alcuni esempi di esse è il seguente:
+elenco di alcuni esempi di esse è il seguente:
 \begin{itemize*}
 \item il cambiamento dei font di un terminale.
 \item l'esecuzione di una traccia audio di un CDROM.
 \item i comandi di avanti veloce e riavvolgimento di un nastro.
 \item il comando di espulsione di un dispositivo rimovibile.
-\item l'impostazione della velocità trasmissione di una linea seriale.
+\item l'impostazione della velocità trasmissione di una linea seriale.
 \item l'impostazione della frequenza e della durata dei suoni emessi dallo
   speaker.
 \item l'impostazione degli attributi dei file su un filesystem
@@ -1620,20 +1620,20 @@ opportunamente differenziati a seconda del dispositivo\footnote{il kernel usa
   un apposito \textit{magic number} per distinguere ciascun dispositivo nella
   definizione delle macro da usare per \param{request}, in modo da essere
   sicuri che essi siano sempre diversi, ed il loro uso per dispositivi diversi
-  causi al più un errore.  Si veda il capitolo quinto di \cite{LinDevDri} per
-  una trattazione dettagliata dell'argomento.} così che la richiesta di
+  causi al più un errore.  Si veda il capitolo quinto di \cite{LinDevDri} per
+  una trattazione dettagliata dell'argomento.} così che la richiesta di
 operazioni relative ad altri dispositivi usualmente provoca il ritorno della
 funzione con una condizione di errore, in alcuni casi, relativi a valori
 assegnati prima che questa differenziazione diventasse pratica corrente, si
 potrebbero usare valori validi anche per il dispositivo corrente, con effetti
 imprevedibili o indesiderati.
 
-Data la assoluta specificità della funzione, il cui comportamento varia da
-dispositivo a dispositivo, non è possibile fare altro che dare una descrizione
+Data la assoluta specificità della funzione, il cui comportamento varia da
+dispositivo a dispositivo, non è possibile fare altro che dare una descrizione
 sommaria delle sue caratteristiche; torneremo ad esaminare in
 seguito\footnote{per l'uso di \func{ioctl} con i socket si veda
   sez.~\ref{sec:sock_ctrl_func}.} quelle relative ad alcuni casi specifici (ad
-esempio la gestione dei terminali è effettuata attraverso \func{ioctl} in
+esempio la gestione dei terminali è effettuata attraverso \func{ioctl} in
 quasi tutte le implementazioni di Unix), qui riportiamo solo l'elenco delle
 operazioni che sono predefinite per qualunque file,\footnote{in particolare
   queste operazioni sono definite nel kernel a livello generale, e vengono
@@ -1649,53 +1649,53 @@ operazioni che sono predefinite per qualunque file,\footnote{in particolare
   \textit{close-on-exec} sul file, in questo caso, essendo usata come
   operazione logica, \func{ioctl} non richiede un terzo argomento, il cui
   eventuale valore viene ignorato.
-\item[\const{FIOASYNC}] abilita o disabilita la modalità di I/O asincrono sul
+\item[\const{FIOASYNC}] abilita o disabilita la modalità di I/O asincrono sul
   file (vedi sez.~\ref{sec:file_asyncronous_operation}); il terzo argomento
-  deve essere un puntatore ad un intero (cioè di tipo \texttt{const int *})
+  deve essere un puntatore ad un intero (cioè di tipo \texttt{const int *})
   che contiene un valore logico (un valore nullo disabilita, un valore non
   nullo abilita).
-\item[\const{FIONBIO}] abilita o disabilita sul file l'I/O in modalità non
-  bloccante; il terzo argomento deve essere un puntatore ad un intero (cioè di
+\item[\const{FIONBIO}] abilita o disabilita sul file l'I/O in modalità non
+  bloccante; il terzo argomento deve essere un puntatore ad un intero (cioè di
   tipo \texttt{const int *}) che contiene un valore logico (un valore nullo
   disabilita, un valore non nullo abilita).
-\item[\const{FIOSETOWN}] imposta il processo che riceverà i segnali
+\item[\const{FIOSETOWN}] imposta il processo che riceverà i segnali
   \const{SIGURG} e \const{SIGIO} generati sul file; il terzo argomento deve
-  essere un puntatore ad un intero (cioè di tipo \texttt{const int *}) il cui
+  essere un puntatore ad un intero (cioè di tipo \texttt{const int *}) il cui
   valore specifica il PID del processo.
-\item[\const{FIOGETOWN}] legge il processo che riceverà i segnali
+\item[\const{FIOGETOWN}] legge il processo che riceverà i segnali
   \const{SIGURG} e \const{SIGIO} generati sul file; il terzo argomento deve
-  essere un puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà
+  essere un puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà
   scritto il PID del processo.
 \item[\const{FIONREAD}] legge il numero di byte disponibili in lettura sul
-  file descriptor;\footnote{questa operazione è disponibile solo su alcuni
+  file descriptor;\footnote{questa operazione è disponibile solo su alcuni
     file descriptor, in particolare sui socket (vedi
     sez.~\ref{sec:sock_ioctl_IP}) o sui file descriptor di \textit{epoll}
     (vedi sez.~\ref{sec:file_epoll}).} il terzo argomento deve essere un
-  puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà restituito
+  puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà restituito
   il valore.
 \item[\const{FIOQSIZE}] restituisce la dimensione corrente di un file o di una
   directory, mentre se applicata ad un dispositivo fallisce con un errore di
   \errcode{ENOTTY}; il terzo argomento deve essere un puntatore ad un intero
-  (cioè di tipo \texttt{int *}) su cui sarà restituito il valore.
+  (cioè di tipo \texttt{int *}) su cui sarà restituito il valore.
 \end{basedescript}
 
 % TODO aggiungere FIBMAP e FIEMAP, vedi http://lwn.net/Articles/260832
 
 
-Si noti però come la gran parte di queste operazioni specifiche dei file (per
+Si noti però come la gran parte di queste operazioni specifiche dei file (per
 essere precisi le prime sei dell'elenco) siano effettuabili in maniera
 generica anche tramite l'uso di \func{fcntl}. Le due funzioni infatti sono
-molto simili e la presenza di questa sovrapposizione è principalmente dovuta
+molto simili e la presenza di questa sovrapposizione è principalmente dovuta
 al fatto che alle origini di Unix i progettisti considerarono che era
 necessario trattare diversamente rispetto alle operazione di controllo delle
-modalità di I/O file e dispositivi usando \func{fcntl} per i primi e
+modalità di I/O file e dispositivi usando \func{fcntl} per i primi e
 \func{ioctl} per i secondi;\footnote{all'epoca tra l'altro i dispositivi che
   usavano \func{ioctl} erano sostanzialmente solo i terminali, il che spiega
-  l'uso comune di \errcode{ENOTTY} come codice di errore.} oggi non è più così
+  l'uso comune di \errcode{ENOTTY} come codice di errore.} oggi non è più così
 ma le due funzioni sono rimaste.
 
 % TODO trovare qualche posto per la eventuale documentazione delle seguenti
-% (bassa/bassissima priorità)
+% (bassa/bassissima priorità)
 % EXT4_IOC_MOVE_EXT (dal 2.6.31)
 
 
diff --git a/gapil.tex b/gapil.tex
index 0e74233..72a0abd 100644
--- a/gapil.tex
+++ b/gapil.tex
@@ -17,7 +17,7 @@
 \documentclass[a4paper,11pt,twoside]{book}
 \usepackage{ae,aecompl}
 \usepackage[T1]{fontenc}
-\usepackage[latin1]{inputenc}
+\usepackage[utf8]{inputenc}
 %\usepackage[tex4ht, bookmarks=true]{hyperref}
 \usepackage[bookmarks=true,plainpages=false,pdfpagelabels,hyperfootnotes=false]{hyperref}
 \usepackage{makeidx}
diff --git a/intro.tex b/intro.tex
index 1667989..b481353 100644
--- a/intro.tex
+++ b/intro.tex
@@ -12,10 +12,10 @@
 \chapter{L'architettura del sistema}
 \label{cha:intro_unix}
 
-In questo primo capitolo sarà fatta un'introduzione ai concetti generali su
-cui è basato un sistema operativo di tipo Unix come GNU/Linux, in questo modo
-potremo fornire una base di comprensione mirata a sottolineare le peculiarità
-del sistema che sono più rilevanti per quello che riguarda la programmazione.
+In questo primo capitolo sarà fatta un'introduzione ai concetti generali su
+cui è basato un sistema operativo di tipo Unix come GNU/Linux, in questo modo
+potremo fornire una base di comprensione mirata a sottolineare le peculiarità
+del sistema che sono più rilevanti per quello che riguarda la programmazione.
 
 Dopo un'introduzione sulle caratteristiche principali di un sistema di tipo
 Unix passeremo ad illustrare alcuni dei concetti base dell'architettura di
@@ -27,14 +27,14 @@ introdurremo alcuni degli standard principali a cui viene fatto riferimento.
 \label{sec:intro_unix_struct}
 
 In questa prima sezione faremo una breve panoramica sull'architettura del
-sistema. Chi avesse già una conoscenza di questa materia può tranquillamente
+sistema. Chi avesse già una conoscenza di questa materia può tranquillamente
 saltare questa sezione.
 
 
 \subsection{Concetti base}
 \label{sec:intro_base_concept}
 
-Il concetto base di un sistema unix-like è quello di un nucleo del sistema (il
+Il concetto base di un sistema unix-like è quello di un nucleo del sistema (il
 cosiddetto \textit{kernel}, nel nostro caso Linux) a cui si demanda la
 gestione delle risorse essenziali (la CPU, la memoria, le periferiche) mentre
 tutto il resto, quindi anche la parte che prevede l'interazione con l'utente,
@@ -42,9 +42,9 @@ dev'essere realizzato tramite programmi eseguiti dal kernel, che accedano
 alle risorse hardware tramite delle richieste a quest'ultimo.
 
 Fin dall'inizio uno Unix si presenta come un sistema operativo
-\textit{multitasking}, cioè in grado di eseguire contemporaneamente più
-programmi, e multiutente, in cui è possibile che più utenti siano connessi ad
-una macchina eseguendo più programmi ``\textsl{in contemporanea}''; in realtà,
+\textit{multitasking}, cioè in grado di eseguire contemporaneamente più
+programmi, e multiutente, in cui è possibile che più utenti siano connessi ad
+una macchina eseguendo più programmi ``\textsl{in contemporanea}''; in realtà,
 almeno per macchine a processore singolo, i programmi vengono eseguiti
 singolarmente a rotazione.
 
@@ -53,85 +53,85 @@ singolarmente a rotazione.
 %computer (e quindi per un uso personale), sui quali l'hardware (allora
 %limitato) non consentiva la realizzazione di un sistema evoluto come uno unix.
 
-I kernel Unix più recenti, come Linux, sono realizzati sfruttando alcune
+I kernel Unix più recenti, come Linux, sono realizzati sfruttando alcune
 caratteristiche dei processori moderni come la gestione hardware della memoria
-e la modalità protetta. In sostanza con i processori moderni si può
+e la modalità protetta. In sostanza con i processori moderni si può
 disabilitare temporaneamente l'uso di certe istruzioni e l'accesso a certe
-zone di memoria fisica.  Quello che succede è che il kernel è il solo
-programma ad essere eseguito in modalità privilegiata, con il completo accesso
-all'hardware, mentre i programmi normali vengono eseguiti in modalità protetta
+zone di memoria fisica.  Quello che succede è che il kernel è il solo
+programma ad essere eseguito in modalità privilegiata, con il completo accesso
+all'hardware, mentre i programmi normali vengono eseguiti in modalità protetta
 e non possono accedere direttamente alle zone di memoria riservate o alle
 porte di input/output.
 
 Una parte del kernel, lo \itindex{scheduler} \textit{scheduler}, si occupa di
 stabilire, ad intervalli fissi e sulla base di un opportuno calcolo delle
-priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione (il
+priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione (il
 cosiddetto \itindex{preemptive~multitasking} \textit{preemptive
-  multitasking}).  Questo verrà comunque eseguito in modalità protetta; quando
-necessario il processo potrà accedere alle risorse hardware soltanto
+  multitasking}).  Questo verrà comunque eseguito in modalità protetta; quando
+necessario il processo potrà accedere alle risorse hardware soltanto
 attraverso delle opportune chiamate al sistema che restituiranno il controllo
 al kernel.
 
 La memoria viene sempre gestita dal kernel attraverso il meccanismo della
 \index{memoria~virtuale} \textsl{memoria virtuale}, che consente di assegnare
 a ciascun processo uno spazio di indirizzi ``\textsl{virtuale}'' (vedi
-sez.~\ref{sec:proc_memory}) che il kernel stesso, con l'ausilio della unità di
-gestione della memoria, si incaricherà di rimappare automaticamente sulla
+sez.~\ref{sec:proc_memory}) che il kernel stesso, con l'ausilio della unità di
+gestione della memoria, si incaricherà di rimappare automaticamente sulla
 memoria disponibile, salvando su disco quando necessario (nella cosiddetta
 area di \textit{swap}) le pagine di memoria in eccedenza.
 
 Le periferiche infine vengono viste in genere attraverso un'interfaccia
 astratta che permette di trattarle come fossero file, secondo il concetto per
 cui \textit{everything is a file}, su cui torneremo in dettaglio in
-cap.~\ref{cha:file_intro}. Questo non è vero per le interfacce di rete, che
+cap.~\ref{cha:file_intro}. Questo non è vero per le interfacce di rete, che
 hanno un'interfaccia diversa, ma resta valido il concetto generale che tutto
-il lavoro di accesso e gestione a basso livello è effettuato dal kernel.
+il lavoro di accesso e gestione a basso livello è effettuato dal kernel.
 
 
 \subsection{Il kernel e il sistema}
 \label{sec:intro_kern_and_sys}
 
-Uno dei concetti fondamentali su cui si basa l'architettura dei sistemi Unix è
+Uno dei concetti fondamentali su cui si basa l'architettura dei sistemi Unix è
 quello della distinzione fra il cosiddetto \textit{user space}, che
 contraddistingue l'ambiente in cui vengono eseguiti i programmi, e il
-\textit{kernel space}, che è l'ambiente in cui viene eseguito il kernel. Ogni
-programma vede sé stesso come se avesse la piena disponibilità della CPU e
-della memoria ed è, salvo i meccanismi di comunicazione previsti
+\textit{kernel space}, che è l'ambiente in cui viene eseguito il kernel. Ogni
+programma vede sé stesso come se avesse la piena disponibilità della CPU e
+della memoria ed è, salvo i meccanismi di comunicazione previsti
 dall'architettura, completamente ignaro del fatto che altri programmi possono
 essere messi in esecuzione dal kernel.
 
-Per questa separazione non è possibile ad un singolo programma disturbare
-l'azione di un altro programma o del sistema e questo è il principale motivo
-della stabilità di un sistema unix-like nei confronti di altri sistemi in cui
+Per questa separazione non è possibile ad un singolo programma disturbare
+l'azione di un altro programma o del sistema e questo è il principale motivo
+della stabilità di un sistema unix-like nei confronti di altri sistemi in cui
 i processi non hanno di questi limiti, o che vengono per vari motivi eseguiti
 al livello del kernel. Pertanto deve essere chiaro a chi programma in Unix che
-l'accesso diretto all'hardware non può avvenire se non all'interno del kernel;
+l'accesso diretto all'hardware non può avvenire se non all'interno del kernel;
 al di fuori dal kernel il programmatore deve usare le opportune interfacce che
 quest'ultimo fornisce allo user space.
 
-Per capire meglio la distinzione fra kernel space e user space si può prendere
+Per capire meglio la distinzione fra kernel space e user space si può prendere
 in esame la procedura di avvio di un sistema unix-like; all'avvio il BIOS (o
-in generale il software di avvio posto nelle EPROM) eseguirà la procedura di
+in generale il software di avvio posto nelle EPROM) eseguirà la procedura di
 avvio del sistema (il cosiddetto \textit{bootstrap}\footnote{il nome deriva da
   un'espressione gergale che significa ``sollevarsi da terra tirandosi per le
   stringhe delle scarpe'', per indicare il compito, almeno apparentemente
   impossibile, di far eseguire un programma a partire da un computer appena
-  acceso che appunto non ne contiene nessuno; non è impossibile perché in
-  realtà c'è un programma iniziale, che è il BIOS.}), incaricandosi di
+  acceso che appunto non ne contiene nessuno; non è impossibile perché in
+  realtà c'è un programma iniziale, che è il BIOS.}), incaricandosi di
 caricare il kernel in memoria e di farne partire l'esecuzione; quest'ultimo,
-dopo aver inizializzato le periferiche, farà partire il primo processo,
-\cmd{init}, che è quello che a sua volta farà partire tutti i processi
-successivi. Fra questi ci sarà pure quello che si occupa di dialogare con la
+dopo aver inizializzato le periferiche, farà partire il primo processo,
+\cmd{init}, che è quello che a sua volta farà partire tutti i processi
+successivi. Fra questi ci sarà pure quello che si occupa di dialogare con la
 tastiera e lo schermo della console, e quello che mette a disposizione
 dell'utente che si vuole collegare, un terminale e la \textit{shell} da cui
 inviare i comandi.
 
-E' da rimarcare come tutto ciò, che usualmente viene visto come parte del
-sistema, non abbia in realtà niente a che fare con il kernel, ma sia
+E' da rimarcare come tutto ciò, che usualmente viene visto come parte del
+sistema, non abbia in realtà niente a che fare con il kernel, ma sia
 effettuato da opportuni programmi che vengono eseguiti, allo stesso modo di un
 qualunque programma di scrittura o di disegno, in user space.
 
-Questo significa, ad esempio, che il sistema di per sé non dispone di
+Questo significa, ad esempio, che il sistema di per sé non dispone di
 primitive per tutta una serie di operazioni (come la copia di un file) che
 altri sistemi (come Windows) hanno invece al loro interno. Pertanto buona
 parte delle operazioni di normale amministrazione di un sistema, come quella
@@ -141,10 +141,10 @@ in esempio, sono implementate come normali programmi.
 %realizzare un sistema di permessi e controlli che evitano che i programmi
 %eseguano accessi non autorizzati. 
 
-Per questo motivo quando ci si riferisce al sistema nella sua interezza è
-corretto parlare di un sistema GNU/Linux: da solo il kernel è assolutamente
-inutile; quello che costruisce un sistema operativo utilizzabile è la presenza
-di tutta una serie di librerie e programmi di utilità (che di norma sono
+Per questo motivo quando ci si riferisce al sistema nella sua interezza è
+corretto parlare di un sistema GNU/Linux: da solo il kernel è assolutamente
+inutile; quello che costruisce un sistema operativo utilizzabile è la presenza
+di tutta una serie di librerie e programmi di utilità (che di norma sono
 quelli realizzati dal progetto GNU della Free Software Foundation) che
 permettono di eseguire le normali operazioni che ci si aspetta da un sistema
 operativo.
@@ -155,11 +155,11 @@ operativo.
 
 Come accennato le interfacce con cui i programmi possono accedere all'hardware
 vanno sotto il nome di chiamate al sistema (le cosiddette \textit{system
-  call}), si tratta di un insieme di funzioni che un programma può chiamare,
+  call}), si tratta di un insieme di funzioni che un programma può chiamare,
 per le quali viene generata un'interruzione del processo passando il controllo
-dal programma al kernel. Sarà poi quest'ultimo che (oltre a compiere una serie
+dal programma al kernel. Sarà poi quest'ultimo che (oltre a compiere una serie
 di operazioni interne come la gestione del multitasking e l'allocazione della
-memoria) eseguirà la funzione richiesta in \textit{kernel space} restituendo i
+memoria) eseguirà la funzione richiesta in \textit{kernel space} restituendo i
 risultati al chiamante.
 
 Ogni versione di Unix ha storicamente sempre avuto un certo numero di queste
@@ -167,7 +167,7 @@ chiamate, che sono riportate nella seconda sezione del \textsl{Manuale di
   programmazione di Unix} (quella cui si accede con il comando \cmd{man 2
   <nome>}) e Linux non fa eccezione. Queste sono poi state codificate da vari
 standard, che esamineremo brevemente in sez.~\ref{sec:intro_standard}. Uno
-schema elementare della struttura del sistema è riportato in
+schema elementare della struttura del sistema è riportato in
 fig.~\ref{fig:intro_sys_struct}.
 
 \begin{figure}[htb]
@@ -223,9 +223,9 @@ Standard del C, che, oltre alle interfacce alle \textit{system call}, contiene
 anche tutta la serie delle ulteriori funzioni definite dai vari standard, che
 sono comunemente usate nella programmazione.
 
-Questo è importante da capire perché programmare in Linux significa anzitutto
+Questo è importante da capire perché programmare in Linux significa anzitutto
 essere in grado di usare le varie interfacce contenute nella Libreria Standard
-del C, in quanto né il kernel, né il linguaggio C implementano direttamente
+del C, in quanto né il kernel, né il linguaggio C implementano direttamente
 operazioni comuni come l'allocazione dinamica della memoria, l'input/output
 bufferizzato sui file o la manipolazione delle stringhe, presenti in qualunque
 programma.
@@ -236,21 +236,21 @@ maggioranza dei casi,\footnote{esistono implementazioni diverse delle librerie
   dal progetto GNU. Le \textit{libc5} oggi sono, tranne casi particolari,
   completamente soppiantate dalle \acr{glibc}, le \textit{uClib} pur non
   essendo complete come le \acr{glibc}, restano invece molto diffuse nel mondo
-  embedded per le loro dimensioni ridotte (e soprattutto la possibilità di
+  embedded per le loro dimensioni ridotte (e soprattutto la possibilità di
   togliere le parti non necessarie), e pertanto costituiscono un valido
   rimpiazzo delle \acr{glibc} in tutti quei sistemi specializzati che
   richiedono una minima occupazione di memoria.} si dovrebbe usare il nome
 GNU/Linux (piuttosto che soltanto Linux) in quanto una parte essenziale del
-sistema (senza la quale niente funzionerebbe) è la \textit{GNU Standard C
+sistema (senza la quale niente funzionerebbe) è la \textit{GNU Standard C
   Library} (in breve \acr{glibc}), ovvero la libreria realizzata dalla Free
 Software Foundation nella quale sono state implementate tutte le funzioni
 essenziali definite negli standard POSIX e ANSI C, utilizzate da qualunque
 programma.
 
 Le funzioni di questa libreria sono quelle riportate dalla terza sezione del
-\textsl{Manuale di Programmazione di Unix} (cioè accessibili con il comando
+\textsl{Manuale di Programmazione di Unix} (cioè accessibili con il comando
 \cmd{man 3 <nome>}) e sono costruite sulla base delle chiamate al sistema del
-kernel; è importante avere presente questa distinzione, fondamentale dal punto
+kernel; è importante avere presente questa distinzione, fondamentale dal punto
 di vista dell'implementazione, anche se poi, nella realizzazione di normali
 programmi, non si hanno differenze pratiche fra l'uso di una funzione di
 libreria e quello di una chiamata al sistema.
@@ -258,8 +258,8 @@ libreria e quello di una chiamata al sistema.
 Le librerie standard del C consentono comunque, nel caso non sia presente una
 specifica funzione di libreria corrispondente, di eseguire una \textit{system
   call} generica tramite la funzione \funcd{syscall}, il cui prototipo,
-accessible se si è definita la macro \macro{\_GNU\_SOURCE}, (vedi
-sez.~\ref{sec:intro_gcc_glibc_std}) è:
+accessible se si è definita la macro \macro{\_GNU\_SOURCE}, (vedi
+sez.~\ref{sec:intro_gcc_glibc_std}) è:
 \begin{functions}
   \headdecl{unistd.h}
   \headdecl{sys/syscall.h}
@@ -272,7 +272,7 @@ La funzione richiede come primo argomento il numero della \textit{system call}
 da invocare, seguita dagli argomenti da passare alla stessa (che ovviamente
 dipendono da quest'ultima), e restituisce il codice di ritorno della
 \textit{system call} invocata. In generale un valore nullo indica il successo
-ed un valore negativo è un codice di errore che poi viene memorizzato nella
+ed un valore negativo è un codice di errore che poi viene memorizzato nella
 variabile \var{errno} (sulla gestione degli errori torneremo in dettaglio in
 sez.~\ref{sec:sys_errors}).
 
@@ -290,41 +290,41 @@ direttamente valori numerici.
 \label{sec:intro_multiuser}
 
 Linux, come gli altri kernel Unix, nasce fin dall'inizio come sistema
-multiutente, cioè in grado di fare lavorare più persone in contemporanea. Per
+multiutente, cioè in grado di fare lavorare più persone in contemporanea. Per
 questo esistono una serie di meccanismi di sicurezza, che non sono previsti in
 sistemi operativi monoutente, e che occorre tenere presenti.
 
-Il concetto base è quello di utente (\textit{user}) del sistema, le cui
-capacità rispetto a quello che può fare sono sottoposte a ben precisi limiti.
-Sono così previsti una serie di meccanismi per identificare i singoli utenti
+Il concetto base è quello di utente (\textit{user}) del sistema, le cui
+capacità rispetto a quello che può fare sono sottoposte a ben precisi limiti.
+Sono così previsti una serie di meccanismi per identificare i singoli utenti
 ed una serie di permessi e protezioni per impedire che utenti diversi possano
 danneggiarsi a vicenda o danneggiare il sistema. Questi meccanismi sono
-realizzati dal kernel stesso ed attengono alle operazioni più varie, e
-torneremo su di essi in dettaglio più avanti.
+realizzati dal kernel stesso ed attengono alle operazioni più varie, e
+torneremo su di essi in dettaglio più avanti.
 
-Ogni utente è identificato da un nome (l'\textit{username}), che è quello che
+Ogni utente è identificato da un nome (l'\textit{username}), che è quello che
 viene richiesto all'ingresso nel sistema dalla procedura di \textit{login}
 (descritta in dettaglio in sez.~\ref{sec:sess_login}).  Questa procedura si
-incarica di verificare l'identità dell'utente, in genere attraverso la
+incarica di verificare l'identità dell'utente, in genere attraverso la
 richiesta di una parola d'ordine (la \textit{password}), anche se sono
 possibili meccanismi diversi.\footnote{ad esempio usando la libreria PAM
-  (\textit{Pluggable Autentication Methods}) è possibile astrarre
+  (\textit{Pluggable Autentication Methods}) è possibile astrarre
   completamente dai meccanismi di autenticazione e sostituire ad esempio l'uso
   delle password con meccanismi di identificazione biometrica.} Eseguita la
 procedura di riconoscimento in genere il sistema manda in esecuzione un
-programma di interfaccia (che può essere la \textit{shell} su terminale o
+programma di interfaccia (che può essere la \textit{shell} su terminale o
 un'interfaccia grafica) che mette a disposizione dell'utente un meccanismo con
-cui questo può impartire comandi o eseguire altri programmi.
+cui questo può impartire comandi o eseguire altri programmi.
 
 Ogni utente appartiene anche ad almeno un gruppo (il cosiddetto
-\textit{default group}), ma può essere associato ad altri gruppi (i
+\textit{default group}), ma può essere associato ad altri gruppi (i
 \textit{supplementary group}), questo permette di gestire i permessi di
-accesso ai file e quindi anche alle periferiche, in maniera più flessibile,
+accesso ai file e quindi anche alle periferiche, in maniera più flessibile,
 definendo gruppi di lavoro, di accesso a determinate risorse, ecc. 
 
 L'utente e il gruppo sono identificati da due numeri, la cui corrispondenza ad
-un nome espresso in caratteri è inserita nei due file \conffile{/etc/passwd} e
-\conffile{/etc/group}.\footnote{in realtà negli sistemi più moderni, come
+un nome espresso in caratteri è inserita nei due file \conffile{/etc/passwd} e
+\conffile{/etc/group}.\footnote{in realtà negli sistemi più moderni, come
   vedremo in sez.~\ref{sec:sys_user_group} queste informazioni possono essere
   mantenute, con l'uso del \itindex{Name~Service~Switch} \textit{Name Service
     Switch}, su varie tipologie di supporti, compresi server centralizzati
@@ -335,16 +335,16 @@ un nome espresso in caratteri 
 l'utente; torneremo in dettaglio su questo argomento in
 sez.~\ref{sec:proc_perms}. 
  
-In questo modo il sistema è in grado di tenere traccia dell'utente a cui
+In questo modo il sistema è in grado di tenere traccia dell'utente a cui
 appartiene ciascun processo ed impedire ad altri utenti di interferire con
 quest'ultimo.  Inoltre con questo sistema viene anche garantita una forma base
 di sicurezza interna in quanto anche l'accesso ai file (vedi
-sez.~\ref{sec:file_access_control}) è regolato da questo meccanismo di
+sez.~\ref{sec:file_access_control}) è regolato da questo meccanismo di
 identificazione.
 
-Infine in ogni Unix è presente un utente speciale privilegiato, il cosiddetto
-\textit{superuser}, il cui username è di norma \textit{root}, ed il cui
-\acr{uid} è zero. Esso identifica l'amministratore del sistema, che deve
+Infine in ogni Unix è presente un utente speciale privilegiato, il cosiddetto
+\textit{superuser}, il cui username è di norma \textit{root}, ed il cui
+\acr{uid} è zero. Esso identifica l'amministratore del sistema, che deve
 essere in grado di fare qualunque operazione; per l'utente \textit{root}
 infatti i meccanismi di controllo descritti in precedenza sono
 disattivati.\footnote{i controlli infatti vengono sempre eseguiti da un codice
@@ -371,18 +371,18 @@ particolare attenzione alle \acr{glibc}).
 \subsection{Lo standard ANSI C}
 \label{sec:intro_ansiC}
 
-Lo standard ANSI C è stato definito nel 1989 dall'\textit{American National
+Lo standard ANSI C è stato definito nel 1989 dall'\textit{American National
   Standard Institute} come prima standardizzazione del linguaggio C e per
-questo si fa riferimento ad esso anche come C89. L'anno successivo è stato
+questo si fa riferimento ad esso anche come C89. L'anno successivo è stato
 adottato dalla ISO (\textit{International Standard Organisation}) come
-standard internazionale con la sigla ISO/IEC 9899:1990, e per questo è noto
+standard internazionale con la sigla ISO/IEC 9899:1990, e per questo è noto
 anche sotto il nome di standard ISO C, o ISO C90.
 
-Nel 1999 è stata pubblicata una revisione dello standard C89, che viene
-usualmente indicata come C99, anche questa è stata ratificata dalla ISO con la
+Nel 1999 è stata pubblicata una revisione dello standard C89, che viene
+usualmente indicata come C99, anche questa è stata ratificata dalla ISO con la
 sigla ISO/IEC 9899:1990, per cui vi si fa riferimento anche come ISO C99.
 
-Scopo dello standard è quello di garantire la portabilità dei programmi C fra
+Scopo dello standard è quello di garantire la portabilità dei programmi C fra
 sistemi operativi diversi, ma oltre alla sintassi ed alla semantica del
 linguaggio C (operatori, parole chiave, tipi di dati) lo standard prevede
 anche una libreria di funzioni che devono poter essere implementate su
@@ -390,7 +390,7 @@ qualunque sistema operativo.
 
 Per questo motivo, anche se lo standard non ha alcun riferimento ad un sistema
 di tipo Unix, GNU/Linux (per essere precisi le \acr{glibc}), come molti Unix
-moderni, provvede la compatibilità con questo standard, fornendo le funzioni
+moderni, provvede la compatibilità con questo standard, fornendo le funzioni
 di libreria da esso previste. Queste sono dichiarate in una serie di
 \textit{header file}\footnote{i file di dichiarazione di variabili, tipi e
   funzioni, usati normalmente da un compilatore C. Per poter accedere alle
@@ -439,34 +439,34 @@ sezioni successive.
   \label{tab:intro_posix_header}
 \end{table}
 
-In realtà \acr{glibc} ed i relativi header file definiscono un insieme di
-funzionalità in cui sono incluse come sottoinsieme anche quelle previste dallo
-standard ANSI C. È possibile ottenere una conformità stretta allo standard
-(scartando le funzionalità addizionali) usando il \cmd{gcc} con l'opzione
+In realtà \acr{glibc} ed i relativi header file definiscono un insieme di
+funzionalità in cui sono incluse come sottoinsieme anche quelle previste dallo
+standard ANSI C. È possibile ottenere una conformità stretta allo standard
+(scartando le funzionalità addizionali) usando il \cmd{gcc} con l'opzione
 \cmd{-ansi}. Questa opzione istruisce il compilatore a definire nei vari
-header file soltanto le funzionalità previste dallo standard ANSI C e a non
+header file soltanto le funzionalità previste dallo standard ANSI C e a non
 usare le varie estensioni al linguaggio e al preprocessore da esso supportate.
 
 
 \subsection{I tipi di dati primitivi}
 \label{sec:intro_data_types}
 
-Uno dei problemi di portabilità del codice più comune è quello dei tipi di
+Uno dei problemi di portabilità del codice più comune è quello dei tipi di
 dati utilizzati nei programmi, che spesso variano da sistema a sistema, o
 anche da una architettura ad un'altra (ad esempio passando da macchine con
-processori 32 bit a 64). In particolare questo è vero nell'uso dei cosiddetti
+processori 32 bit a 64). In particolare questo è vero nell'uso dei cosiddetti
 \index{tipo!elementare} \textit{tipi elementari}del linguaggio C (come
 \ctyp{int}) la cui dimensione varia a seconda dell'architettura hardware.
 
 Storicamente alcuni tipi nativi dello standard ANSI C sono sempre stati
 associati ad alcune variabili nei sistemi Unix, dando per scontata la
-dimensione. Ad esempio la posizione corrente all'interno di un file è sempre
-stata associata ad un intero a 32 bit, mentre il numero di dispositivo è
+dimensione. Ad esempio la posizione corrente all'interno di un file è sempre
+stata associata ad un intero a 32 bit, mentre il numero di dispositivo è
 sempre stato associato ad un intero a 16 bit. Storicamente questi erano
 definiti rispettivamente come \ctyp{int} e \ctyp{short}, ma tutte le volte
 che, con l'evolversi ed il mutare delle piattaforme hardware, alcuni di questi
-tipi si sono rivelati inadeguati o sono cambiati, ci si è trovati di fronte ad
-una infinita serie di problemi di portabilità.
+tipi si sono rivelati inadeguati o sono cambiati, ci si è trovati di fronte ad
+una infinita serie di problemi di portabilità.
 
 \begin{table}[htb]
   \footnotesize
@@ -514,13 +514,13 @@ compilatore C.
 \subsection{Lo standard System V}
 \label{sec:intro_sysv}
 
-Come noto Unix nasce nei laboratori della AT\&T, che ne registrò il nome come
+Come noto Unix nasce nei laboratori della AT\&T, che ne registrò il nome come
 marchio depositato, sviluppandone una serie di versioni diverse; nel 1983 la
 versione supportata ufficialmente venne rilasciata al pubblico con il nome di
 Unix System V, e si fa rifermento a questa implementazione con la sigla SysV o
 SV.
 
-Negli anni successivi l'AT\&T proseguì lo sviluppo rilasciando varie versioni
+Negli anni successivi l'AT\&T proseguì lo sviluppo rilasciando varie versioni
 con aggiunte e integrazioni, ed in particolare la \textit{release 2} nel 1985,
 a cui si fa riferimento con SVr2 e la \textit{release 3} nel 1986 (denominata
 SVr3). Le interfacce di programmazione di queste due versioni vennero
@@ -528,7 +528,7 @@ descritte formalmente in due documenti denominati \textit{System V Interface
   Definition} (o SVID), pertanto nel 1995 venne rilasciata la specifica SVID 1
 e nel 1986 la specifica SVID 2.
 
-Nel 1989 un accordo fra vari venditori (AT\&T, Sun, HP, ed altri) portò ad una
+Nel 1989 un accordo fra vari venditori (AT\&T, Sun, HP, ed altri) portò ad una
 versione di System V che provvedeva un'unificazione delle interfacce
 comprendente anche Xenix e BSD, questa venne denominata \textit{release 4} o
 SVr4. Anche le relative interfacce vennero descritte in un documento dal
@@ -538,21 +538,21 @@ cui spesso si fa riferimento semplicemente con SVID. Anche SVID costituisce un
 sovrainsieme delle interfacce definite dallo standard POSIX.  
 
 Nel 1992 venne rilasciata una seconda versione del sistema, la SVr4.2; l'anno
-successivo la divisione della AT\&T (già a suo tempo rinominata in Unix System
-Laboratories) venne acquistata dalla Novell, che poi trasferì il marchio Unix
+successivo la divisione della AT\&T (già a suo tempo rinominata in Unix System
+Laboratories) venne acquistata dalla Novell, che poi trasferì il marchio Unix
 al consorzio X/Open. L'ultima versione di System V fu la SVr4.2MP rilasciata
-nel Dicembre 93. Infine nel 1995 è stata rilasciata da SCO, che aveva
+nel Dicembre 93. Infine nel 1995 è stata rilasciata da SCO, che aveva
 acquisito alcuni diritti sul codice di System V, una ulteriore versione delle
 \textit{System V Interface Description}, che va sotto la denominazione di SVID
 4.
 
-Linux e le \acr{glibc} implementano le principali funzionalità richieste dalle
-specifiche SVID che non sono già incluse negli standard POSIX ed ANSI C, per
-compatibilità con lo Unix System V e con altri Unix (come SunOS) che le
-includono. Tuttavia le funzionalità più oscure e meno utilizzate (che non sono
+Linux e le \acr{glibc} implementano le principali funzionalità richieste dalle
+specifiche SVID che non sono già incluse negli standard POSIX ed ANSI C, per
+compatibilità con lo Unix System V e con altri Unix (come SunOS) che le
+includono. Tuttavia le funzionalità più oscure e meno utilizzate (che non sono
 presenti neanche in System V) sono state tralasciate.
 
-Le funzionalità implementate sono principalmente il meccanismo di
+Le funzionalità implementate sono principalmente il meccanismo di
 intercomunicazione fra i processi e la memoria condivisa (il cosiddetto System
 V IPC, che vedremo in sez.~\ref{sec:ipc_sysv}) le funzioni della famiglia
 \func{hsearch} e \func{drand48}, \func{fmtmsg} e svariate funzioni
@@ -562,16 +562,16 @@ matematiche.
 \subsection{Lo ``\textsl{standard}'' BSD}
 \label{sec:intro_bsd}
 
-Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università
-di Berkeley e la AT\&T generò una delle prime e più importanti fratture del
-mondo Unix.  L'università di Berkeley proseguì nello sviluppo della base di
+Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università
+di Berkeley e la AT\&T generò una delle prime e più importanti fratture del
+mondo Unix.  L'università di Berkeley proseguì nello sviluppo della base di
 codice di cui disponeva, e che presentava parecchie migliorie rispetto alle
 versioni allora disponibili, fino ad arrivare al rilascio di una versione
 completa di Unix, chiamata appunto BSD, del tutto indipendente dal codice
 della AT\&T.
 
-Benché BSD non sia mai stato uno standard formalizzato, l'implementazione
-dello Unix dell'Università di Berkeley nella sua storia ha introdotto una
+Benché BSD non sia mai stato uno standard formalizzato, l'implementazione
+dello Unix dell'Università di Berkeley nella sua storia ha introdotto una
 serie di estensioni e interfacce di grandissima rilevanza, come i link
 simbolici, la funzione \code{select} ed i socket di rete. Per questo motivo si
 fa spesso riferimento esplicito alle interfacce presenti nelle varie versioni
@@ -587,7 +587,7 @@ Le varie estensioni ideate a Berkeley sono state via via aggiunte al sistema
 nelle varie versioni succedutesi negli anni, che vanno sotto il nome di
 4.3BSD, per la versione rilasciata nel 1986 e 4.4BSD, per la versione
 rilasciata nel 1993, che costituisce l'ultima release ufficiale
-dell'università di Berkeley. Si tenga presente che molte di queste interfacce
+dell'università di Berkeley. Si tenga presente che molte di queste interfacce
 sono presenti in derivati commerciali di BSD come SunOS. Il kernel Linux e le
 \acr{glibc} forniscono tutte queste estensioni che sono state in gran parte
 incorporate negli standard successivi.
@@ -596,14 +596,14 @@ incorporate negli standard successivi.
 \subsection{Gli standard IEEE -- POSIX}
 \label{sec:intro_posix}
 
-Lo standard ufficiale creato da un organismo indipendente più attinente alle
+Lo standard ufficiale creato da un organismo indipendente più attinente alle
 interfacce di un sistema unix-like nel suo complesso (e che concerne sia il
-kernel che le librerie che i comandi) è stato lo standard POSIX. Esso prende
+kernel che le librerie che i comandi) è stato lo standard POSIX. Esso prende
 origine dallo standard ANSI C, che contiene come sottoinsieme, prevedendo
-ulteriori capacità per le funzioni in esso definite, ed aggiungendone di
+ulteriori capacità per le funzioni in esso definite, ed aggiungendone di
 nuove.
 
-In realtà POSIX è una famiglia di standard diversi, il cui nome, suggerito da
+In realtà POSIX è una famiglia di standard diversi, il cui nome, suggerito da
 Richard Stallman, sta per \textit{Portable Operating System Interface}, ma la
 X finale denuncia la sua stretta relazione con i sistemi Unix. Esso nasce dal
 lavoro dell'IEEE (\textit{Institute of Electrical and Electronics Engeneers})
@@ -614,17 +614,17 @@ Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di
 libreria, e in seguito sono stati prodotti anche altri standard per la shell e
 i comandi di sistema (1003.2), per le estensioni \textit{real-time} e per i
 \itindex{thread} \textit{thread} (rispettivamente 1003.1d e 1003.1c) per i
-socket (1003.1g) e vari altri.  In tab.~\ref{tab:intro_posix_std} è riportata
+socket (1003.1g) e vari altri.  In tab.~\ref{tab:intro_posix_std} è riportata
 una classificazione sommaria dei principali documenti prodotti, e di come sono
 identificati fra IEEE ed ISO; si tenga conto inoltre che molto spesso si usa
-l'estensione IEEE anche come aggiunta al nome POSIX; ad esempio è più comune
+l'estensione IEEE anche come aggiunta al nome POSIX; ad esempio è più comune
 parlare di POSIX.4 come di POSIX.1b.
 
 Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione
 si aggiungono continuamente, mentre le versioni precedenti vengono riviste;
 talvolta poi i riferimenti cambiano nome, per cui anche solo seguire le
 denominazioni usate diventa particolarmente faticoso; una pagina dove si
-possono recuperare varie (e di norma piuttosto intricate) informazioni è
+possono recuperare varie (e di norma piuttosto intricate) informazioni è
 \href{http://www.pasc.org/standing/sd11.html}
 {\textsf{http://www.pasc.org/standing/sd11.html}}.
 
@@ -654,19 +654,19 @@ possono recuperare varie (e di norma piuttosto intricate) informazioni 
   \label{tab:intro_posix_std}
 \end{table}
 
-Benché l'insieme degli standard POSIX siano basati sui sistemi Unix, essi
+Benché l'insieme degli standard POSIX siano basati sui sistemi Unix, essi
 definiscono comunque un'interfaccia di programmazione generica e non fanno
 riferimento ad una implementazione specifica (ad esempio esiste
 un'implementazione di POSIX.1 anche sotto Windows NT).  
 
 Linux e le \acr{glibc} implementano tutte le funzioni definite nello standard
-POSIX.1, queste ultime forniscono in più alcune ulteriori capacità (per
+POSIX.1, queste ultime forniscono in più alcune ulteriori capacità (per
 funzioni di \textit{pattern matching} e per la manipolazione delle
 \textit{regular expression}), che vengono usate dalla shell e dai comandi di
 sistema e che sono definite nello standard POSIX.2.
 
-Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate
-ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i
+Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate
+ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i
 \itindex{thread} \textit{thread} (vedi cap.~\ref{cha:threads}), e dallo
 standard POSIX.1b per quanto riguarda i segnali e lo \itindex{scheduler}
 scheduling real-time (sez.~\ref{sec:sig_real_time} e
@@ -675,19 +675,19 @@ intercomunicazione (sez.~\ref{sec:ipc_posix}) e l'I/O asincrono
 (sez.~\ref{sec:file_asyncronous_io}).
 
 Lo standard principale resta comunque POSIX.1, che continua ad evolversi; la
-versione più nota, cui gran parte delle implementazioni fanno riferimento, e
-che costituisce una base per molti altri tentativi di standardizzazione, è
+versione più nota, cui gran parte delle implementazioni fanno riferimento, e
+che costituisce una base per molti altri tentativi di standardizzazione, è
 stata rilasciata anche come standard internazionale con la sigla
 \textsl{ISO/IEC 9945-1:1996} ed include i precedenti POSIX.1b e POSIX.1c. In
 genere si fa riferimento ad essa come POSIX.1-1996.
 
-Nel 2001 è stata poi eseguita una sintesi degli standard POSIX.1, POSIX.2 e
+Nel 2001 è stata poi eseguita una sintesi degli standard POSIX.1, POSIX.2 e
 SUSv3 (vedi sez.~\ref{sec:intro_xopen}) in un unico documento, redatto sotto
 gli auspici del cosiddetto gruppo Austin che va sotto il nome di POSIX.1-2001.
-Questo standard definisce due livelli di conformità, quello POSIX, in cui sono
+Questo standard definisce due livelli di conformità, quello POSIX, in cui sono
 presenti solo le interfacce di base, e quello XSI che richiede la presenza di
 una serie di estensioni opzionali per lo standard POSIX, riprese da SUSv3.
-Inoltre lo standard è stato allineato allo standard C99, e segue lo stesso
+Inoltre lo standard è stato allineato allo standard C99, e segue lo stesso
 nella definizione delle interfacce.
 
 A questo standard sono stati aggiunti due documenti di correzione e
@@ -695,12 +695,12 @@ perfezionamento denominati \textit{Technical Corrigenda}, il TC1 del 2003 ed
 il TC2 del 2004, e talvolta si fa riferimento agli stessi con le sigle
 POSIX.1-2003 e POSIX.1-2004.
 
-Infine è in corso una ulteriore revisione degli standard POSIX e SUS, che
-dovrebbe essere completata entro l'anno 2008 e che andrà presumibilmente
-sotto il nome di POSIX.1-2008. È prevista l'incorporazione di molte interfacce
+Infine è in corso una ulteriore revisione degli standard POSIX e SUS, che
+dovrebbe essere completata entro l'anno 2008 e che andrà presumibilmente
+sotto il nome di POSIX.1-2008. È prevista l'incorporazione di molte interfacce
 opzionali dentro le specifiche di base, oltre che le solite precisazioni ed
-aggiornamenti. Anche in questo caso è prevista la suddivisione in una
-conformità di base, e delle interfacce aggiuntive.
+aggiornamenti. Anche in questo caso è prevista la suddivisione in una
+conformità di base, e delle interfacce aggiuntive.
 
 % vedi anche man standards
 
@@ -709,7 +709,7 @@ conformit
 
 Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi
 Unix per giungere ad un'armonizzazione delle varie implementazioni.  Per far
-questo iniziò a pubblicare una serie di documentazioni e specifiche sotto il
+questo iniziò a pubblicare una serie di documentazioni e specifiche sotto il
 nome di \textit{X/Open Portability Guide} a cui di norma si fa riferimento con
 l'abbreviazione XPG$n$, con $n$ che indica la versione.
 
@@ -717,8 +717,8 @@ Nel 1989 il consorzio produsse una terza versione di questa guida
 particolarmente voluminosa (la \textit{X/Open Portability Guide, Issue 3}),
 contenente una dettagliata standardizzazione dell'interfaccia di sistema di
 Unix, che venne presa come riferimento da vari produttori. Questo standard,
-detto anche XPG3 dal nome della suddetta guida, è sempre basato sullo standard
-POSIX.1, ma prevede una serie di funzionalità aggiuntive fra cui le specifiche
+detto anche XPG3 dal nome della suddetta guida, è sempre basato sullo standard
+POSIX.1, ma prevede una serie di funzionalità aggiuntive fra cui le specifiche
 delle API\footnote{le \textit{Application Programmable Interface}, in sostanze
   le interfacce di programmazione.} per l'interfaccia grafica (X11).
 
@@ -726,79 +726,79 @@ Nel 1992 lo standard venne rivisto con una nuova versione della guida, la
 Issue 4, da cui la sigla XPG4, che aggiungeva l'interfaccia XTI (\textit{X
   Transport Interface}) mirante a soppiantare (senza molto successo)
 l'interfaccia dei socket derivata da BSD. Una seconda versione della guida fu
-rilasciata nel 1994; questa è nota con il nome di Spec 1170 (dal numero delle
+rilasciata nel 1994; questa è nota con il nome di Spec 1170 (dal numero delle
 interfacce, header e comandi definiti) ma si fa riferimento ad essa anche come
 XPG4v2.
 
-Nel 1993 il marchio Unix passò di proprietà dalla Novell (che a sua volta lo
-aveva comprato dalla AT\&T) al consorzio X/Open che iniziò a pubblicare le sue
+Nel 1993 il marchio Unix passò di proprietà dalla Novell (che a sua volta lo
+aveva comprato dalla AT\&T) al consorzio X/Open che iniziò a pubblicare le sue
 specifiche sotto il nome di \textit{Single UNIX Specification} o SUS, l'ultima
-versione di Spec 1170 diventò così la prima versione delle \textit{Single UNIX
-  Specification}, detta SUS o SUSv1, ma più comunemente nota anche come
+versione di Spec 1170 diventò così la prima versione delle \textit{Single UNIX
+  Specification}, detta SUS o SUSv1, ma più comunemente nota anche come
 \textit{Unix 95}.
 
 Nel 1996 la fusione del consorzio X/Open con la Open Software Foundation (nata
-da un gruppo di aziende concorrenti rispetto ai fondatori di X/Open) portò
+da un gruppo di aziende concorrenti rispetto ai fondatori di X/Open) portò
 alla costituzione dell'\textit{Open Group}, un consorzio internazionale che
-raccoglie produttori, utenti industriali, entità accademiche e governative.
-Attualmente il consorzio è detentore del marchio depositato Unix, e prosegue
+raccoglie produttori, utenti industriali, entità accademiche e governative.
+Attualmente il consorzio è detentore del marchio depositato Unix, e prosegue
 il lavoro di standardizzazione delle varie implementazioni, rilasciando
-periodicamente nuove specifiche e strumenti per la verifica della conformità
+periodicamente nuove specifiche e strumenti per la verifica della conformità
 alle stesse.
 
 Nel 1997 fu annunciata la seconda versione delle \textit{Single UNIX
   Specification}, nota con la sigla SUSv2, in questa versione le interfacce
 specificate salgono a 1434, e addirittura a 3030 se si considerano le stazioni
 di lavoro grafiche, per le quali sono inserite pure le interfacce usate da CDE
-che richiede sia X11 che Motif. La conformità a questa versione permette l'uso
+che richiede sia X11 che Motif. La conformità a questa versione permette l'uso
 del nome \textit{Unix 98}, usato spesso anche per riferirsi allo standard. Un
-altro nome alternativo di queste specifiche, date le origini, è XPG5.
+altro nome alternativo di queste specifiche, date le origini, è XPG5.
 
-Come accennato nel 2001, con il rilascio dello standard POSIX.1-2001, è stato
+Come accennato nel 2001, con il rilascio dello standard POSIX.1-2001, è stato
 effettuato uno sforzo di sintesi in cui sono state comprese, nella parte di
 interfacce estese, anche le interfacce definite nelle \textit{Single UNIX
-  Specification}, pertanto si può fare riferimento a detto standard, quando
+  Specification}, pertanto si può fare riferimento a detto standard, quando
 comprensivo del rispetto delle estensioni XSI, come SUSv3, e fregiarsi del
 marchio UNIX 03 se conformi ad esso. 
 
-Infine con la prossima revisione dello standard POSIX.1 è previsto che, come
-avviene per il POSIX.1-2001, la conformità completa a tutte quelle che saranno
-le nuove estensioni XSI previste dall'aggiornamento andrà a definire la nuova
+Infine con la prossima revisione dello standard POSIX.1 è previsto che, come
+avviene per il POSIX.1-2001, la conformità completa a tutte quelle che saranno
+le nuove estensioni XSI previste dall'aggiornamento andrà a definire la nuova
 versione delle \textit{Single UNIX Specification} che verranno chiamate SUSv4.
 
 
 \subsection{Il controllo di aderenza agli standard}
 \label{sec:intro_gcc_glibc_std}
 
-In Linux, grazie alle \acr{glibc}, la conformità agli standard appena
-descritti può essere richiesta sia attraverso l'uso di opportune opzioni del
+In Linux, grazie alle \acr{glibc}, la conformità agli standard appena
+descritti può essere richiesta sia attraverso l'uso di opportune opzioni del
 compilatore (il \texttt{gcc}) che definendo delle specifiche costanti prima
 dell'inclusione dei file di dichiarazione (gli \textit{header file}) che
 definiscono le funzioni di libreria.
 
 Ad esempio se si vuole che i programmi seguano una stretta attinenza allo
-standard ANSI C si può usare l'opzione \texttt{-ansi} del compilatore, e non
-potrà essere utilizzata nessuna funzione non riconosciuta dalle specifiche
+standard ANSI C si può usare l'opzione \texttt{-ansi} del compilatore, e non
+potrà essere utilizzata nessuna funzione non riconosciuta dalle specifiche
 standard ISO per il C.  Il \texttt{gcc} possiede inoltre una specifica opzione
-per richiedere la conformità ad uno standard, nella forma \texttt{-std=nome},
-dove \texttt{nome} può essere \texttt{c89} per indicare lo standard ANSI C
-(vedi sez.~\ref{sec:intro_ansiC}) o \texttt{c99} per indicare la conformità
-allo standard C99.\footnote{che non è al momento completa, esistono anche le
-  possibilità di usare i valori \texttt{gnu89}, l'attuale default, che indica
+per richiedere la conformità ad uno standard, nella forma \texttt{-std=nome},
+dove \texttt{nome} può essere \texttt{c89} per indicare lo standard ANSI C
+(vedi sez.~\ref{sec:intro_ansiC}) o \texttt{c99} per indicare la conformità
+allo standard C99.\footnote{che non è al momento completa, esistono anche le
+  possibilità di usare i valori \texttt{gnu89}, l'attuale default, che indica
   l'uso delle estensioni GNU al C89, riprese poi dal C99, o \texttt{gnu89} che
-  indica il dialetto GNU del C99, che diventerà il default quando la
-  conformità a quest'ultimo sarà completa.}
+  indica il dialetto GNU del C99, che diventerà il default quando la
+  conformità a quest'ultimo sarà completa.}
 
-Per attivare le varie opzioni di controllo di aderenza agli standard è poi
+Per attivare le varie opzioni di controllo di aderenza agli standard è poi
 possibile definire delle macro di preprocessore che controllano le
-funzionalità che le \acr{glibc} possono mettere a disposizione:\footnote{le
-  macro sono definite nel file di dichiarazione \file{<features.h>}, ma non è
+funzionalità che le \acr{glibc} possono mettere a disposizione:\footnote{le
+  macro sono definite nel file di dichiarazione \file{<features.h>}, ma non è
   necessario includerlo nei propri programmi in quanto viene automaticamente
   incluso da tutti gli altri file di dichiarazione che utilizzano le macro in
   esso definite; si tenga conto inoltre che il file definisce anche delle
   ulteriori macro interne, in genere con un doppio prefisso di \texttt{\_},
-  che non devono assolutamente mai essere usate direttamente. } questo può
-essere fatto attraverso l'opzione \texttt{-D} del compilatore, ma è buona
+  che non devono assolutamente mai essere usate direttamente. } questo può
+essere fatto attraverso l'opzione \texttt{-D} del compilatore, ma è buona
 norma farlo inserendo gli opportuni \code{\#define} prima della inclusione dei
 propri \textit{header file}.
 
@@ -811,107 +811,107 @@ in esse definite, sono illustrate nel seguente elenco:
   con le opzione \texttt{-ansi} o \texttt{-std=c99}.
 
 \item[\macro{\_POSIX\_SOURCE}] definendo questa macro (considerata obsoleta)
-  si rendono disponibili tutte le funzionalità dello standard POSIX.1 (la
-  versione IEEE Standard 1003.1) insieme a tutte le funzionalità dello
+  si rendono disponibili tutte le funzionalità dello standard POSIX.1 (la
+  versione IEEE Standard 1003.1) insieme a tutte le funzionalità dello
   standard ISO C. Se viene anche definita con un intero positivo la macro
   \macro{\_POSIX\_C\_SOURCE} lo stato di questa non viene preso in
   considerazione.
 
 \item[\macro{\_POSIX\_C\_SOURCE}] definendo questa macro ad un valore intero
-  positivo si controlla quale livello delle funzionalità specificate da POSIX
-  viene messa a disposizione; più alto è il valore maggiori sono le
-  funzionalità:
+  positivo si controlla quale livello delle funzionalità specificate da POSIX
+  viene messa a disposizione; più alto è il valore maggiori sono le
+  funzionalità:
   \begin{itemize}
-  \item un valore uguale a ``\texttt{1}'' rende disponibili le funzionalità
+  \item un valore uguale a ``\texttt{1}'' rende disponibili le funzionalità
     specificate nella edizione del 1990 (IEEE Standard 1003.1-1990);
   \item valori maggiori o uguali a ``\texttt{2}'' rendono disponibili le
-    funzionalità previste dallo standard POSIX.2 specificate nell'edizione del
+    funzionalità previste dallo standard POSIX.2 specificate nell'edizione del
     1992 (IEEE Standard 1003.2-1992),
   \item un valore maggiore o uguale a ``\texttt{199309L}'' rende disponibili
-    le funzionalità previste dallo standard POSIX.1b specificate nell'edizione
+    le funzionalità previste dallo standard POSIX.1b specificate nell'edizione
     del 1993 (IEEE Standard 1003.1b-1993);
   \item un valore maggiore o uguale a ``\texttt{199506L}'' rende disponibili
-    le funzionalità previste dallo standard POSIX.1 specificate nell'edizione
+    le funzionalità previste dallo standard POSIX.1 specificate nell'edizione
     del 1996 (\textit{ISO/IEC 9945-1:1996}), ed in particolare le definizioni
     dello standard POSIX.1c per i \itindex{thread} \textit{thread};
   \item a partire dalla versione 2.3.3 delle \acr{glibc} un valore maggiore o
-    uguale a ``\texttt{200112L}'' rende disponibili le funzionalità di base
+    uguale a ``\texttt{200112L}'' rende disponibili le funzionalità di base
     previste dallo standard POSIX.1-2001, escludendo le estensioni XSI;
   \item in futuro valori superiori potranno abilitare ulteriori estensioni.
   \end{itemize}
 
 \item[\macro{\_BSD\_SOURCE}] definendo questa macro si rendono disponibili le
-  funzionalità derivate da BSD4.3, insieme a quelle previste dagli standard
-  ISO C, POSIX.1 e POSIX.2; alcune delle funzionalità previste da BSD sono
-  però in conflitto con le corrispondenti definite nello standard POSIX.1, in
-  questo caso se la macro è definita le definizioni previste da BSD4.3 avranno
+  funzionalità derivate da BSD4.3, insieme a quelle previste dagli standard
+  ISO C, POSIX.1 e POSIX.2; alcune delle funzionalità previste da BSD sono
+  però in conflitto con le corrispondenti definite nello standard POSIX.1, in
+  questo caso se la macro è definita le definizioni previste da BSD4.3 avranno
   la precedenza rispetto a POSIX.
 
   A causa della natura dei conflitti con POSIX per ottenere una piena
-  compatibilità con BSD4.3 può essere necessario anche usare una libreria di
-  compatibilità, dato che alcune funzioni sono definite in modo diverso. In
-  questo caso occorrerà anche usare l'opzione \cmd{-lbsd-compat} con il
+  compatibilità con BSD4.3 può essere necessario anche usare una libreria di
+  compatibilità, dato che alcune funzioni sono definite in modo diverso. In
+  questo caso occorrerà anche usare l'opzione \cmd{-lbsd-compat} con il
   compilatore per indicargli di utilizzare le versioni nella libreria di
-  compatibilità prima di quelle normali.
+  compatibilità prima di quelle normali.
 
   Si tenga inoltre presente che la preferenza verso le versioni delle funzioni
   usate da BSD viene mantenuta soltanto se nessuna delle ulteriori macro di
   specificazione di standard successivi (vale a dire una fra
   \macro{\_POSIX\_C\_SOURCE}, \macro{\_POSIX\_SOURCE}, \macro{\_SVID\_SOURCE},
   \macro{\_XOPEN\_SOURCE}, \macro{\_XOPEN\_SOURCE\_EXTENDED} o
-  \macro{\_GNU\_SOURCE}) è stata a sua volta attivata, nel qual caso queste
-  hanno la precedenza. Se però si definisce \macro{\_BSD\_SOURCE} dopo aver
-  definito una di queste macro, l'effetto sarà quello di dare la precedenza
+  \macro{\_GNU\_SOURCE}) è stata a sua volta attivata, nel qual caso queste
+  hanno la precedenza. Se però si definisce \macro{\_BSD\_SOURCE} dopo aver
+  definito una di queste macro, l'effetto sarà quello di dare la precedenza
   alle funzioni in forma BSD.
 
 \item[\macro{\_SVID\_SOURCE}] definendo questa macro si rendono disponibili le
-  funzionalità derivate da SVID. Esse comprendono anche quelle definite negli
+  funzionalità derivate da SVID. Esse comprendono anche quelle definite negli
   standard ISO C, POSIX.1, POSIX.2, e X/Open (XPG$n$) illustrati in
   precedenza.
 
 \item[\macro{\_XOPEN\_SOURCE}] definendo questa macro si rendono disponibili
-  le funzionalità descritte nella \textit{X/Open Portability Guide}. Anche
+  le funzionalità descritte nella \textit{X/Open Portability Guide}. Anche
   queste sono un sovrainsieme di quelle definite negli standard POSIX.1 e
   POSIX.2 ed in effetti sia \macro{\_POSIX\_SOURCE} che
   \macro{\_POSIX\_C\_SOURCE} vengono automaticamente definite. Sono incluse
-  anche ulteriori funzionalità disponibili in BSD e SVID, più una serie di
+  anche ulteriori funzionalità disponibili in BSD e SVID, più una serie di
   estensioni a secondo dei seguenti valori:
   \begin{itemize}
   \item la definizione della macro ad un valore qualunque attiva le
-    funzionalità specificate negli standard POSIX.1, POSIX.2 e XPG4;
+    funzionalità specificate negli standard POSIX.1, POSIX.2 e XPG4;
   \item un valore di ``\texttt{500}'' o superiore rende disponibili anche le
-    funzionalità introdotte con SUSv2, vale a dire la conformità ad Unix98;
+    funzionalità introdotte con SUSv2, vale a dire la conformità ad Unix98;
   \item a partire dalla versione 2.2 delle \acr{glibc} un valore uguale a
-    ``\texttt{600}'' o superiore rende disponibili anche le funzionalità
-    introdotte con SUSv3, corrispondenti allo standard POSIX.1-2001 più le
+    ``\texttt{600}'' o superiore rende disponibili anche le funzionalità
+    introdotte con SUSv3, corrispondenti allo standard POSIX.1-2001 più le
     estensioni XSI.
   \end{itemize}
 
 \item[\macro{\_XOPEN\_SOURCE\_EXTENDED}] definendo questa macro si rendono
-  disponibili le ulteriori funzionalità necessarie ad essere conformi al
+  disponibili le ulteriori funzionalità necessarie ad essere conformi al
   rilascio del marchio \textit{X/Open Unix} corrispondenti allo standard
   Unix95, vale a dire quelle specificate da SUSv1/XPG4v2. Questa macro viene
   definita implicitamente tutte le volte che si imposta
   \macro{\_XOPEN\_SOURCE} ad un valore maggiore o uguale a 500.
 
 \item[\macro{\_ISOC99\_SOURCE}] definendo questa macro si rendono disponibili
-  le funzionalità previste per la revisione delle librerie standard del C
-  introdotte con lo standard ISO C99. La macro è definita a partire dalla
+  le funzionalità previste per la revisione delle librerie standard del C
+  introdotte con lo standard ISO C99. La macro è definita a partire dalla
   versione 2.1.3 delle \acr{glibc}. 
 
   Le precedenti versioni della serie 2.1.x riconoscevano le stesse estensioni
   con la macro \macro{\_ISOC9X\_SOURCE}, dato che lo standard non era stato
-  finalizzato, ma le \acr{glibc} avevano già un'implementazione completa che
-  poteva essere attivata definendo questa macro. Benché questa sia obsoleta
+  finalizzato, ma le \acr{glibc} avevano già un'implementazione completa che
+  poteva essere attivata definendo questa macro. Benché questa sia obsoleta
   viene tuttora riconosciuta come equivalente di \macro{\_ISOC99\_SOURCE} per
-  compatibilità. 
+  compatibilità. 
 
 \item[\macro{\_GNU\_SOURCE}] definendo questa macro si rendono disponibili
-  tutte le funzionalità disponibili nei vari standard oltre a varie estensioni
+  tutte le funzionalità disponibili nei vari standard oltre a varie estensioni
   specifiche presenti solo nelle \acr{glibc} ed in Linux. Gli standard coperti
   sono: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, SUS.
 
-  L'uso di \macro{\_GNU\_SOURCE} è equivalente alla definizione contemporanea
+  L'uso di \macro{\_GNU\_SOURCE} è equivalente alla definizione contemporanea
   delle macro: \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
   \macro{\_POSIX\_SOURCE}, \macro{\_ISOC99\_SOURCE}, inoltre
   \macro{\_POSIX\_C\_SOURCE} con valore ``\texttt{200112L}'' (o
@@ -924,14 +924,14 @@ in esse definite, sono illustrate nel seguente elenco:
  
 \end{basedescript}
 
-Benché Linux supporti in maniera estensiva gli standard più diffusi, esistono
-comunque delle estensioni e funzionalità specifiche, non presenti in altri
+Benché Linux supporti in maniera estensiva gli standard più diffusi, esistono
+comunque delle estensioni e funzionalità specifiche, non presenti in altri
 standard e lo stesso vale per le \acr{glibc} stesse, che definiscono anche
-delle ulteriori funzioni di libreria. Ovviamente l'uso di queste funzionalità
-deve essere evitato se si ha a cuore la portabilità, ma qualora questo non sia
+delle ulteriori funzioni di libreria. Ovviamente l'uso di queste funzionalità
+deve essere evitato se si ha a cuore la portabilità, ma qualora questo non sia
 un requisito esse possono rivelarsi molto utili.
 
-Come per l'aderenza ai vari standard, le funzionalità aggiuntive possono
+Come per l'aderenza ai vari standard, le funzionalità aggiuntive possono
 essere rese esplicitamente disponibili tramite la definizione di opportune
 macro di preprocessore, alcune di queste vengono attivate con la definizione
 di \macro{\_GNU\_SOURCE}, mentre altre devono essere attivate esplicitamente,
@@ -969,13 +969,13 @@ una opportuna macro; queste estensioni sono illustrate nel seguente elenco:
   con le equivalenti a 64 bit, senza dover utilizzare esplicitamente
   l'interfaccia alternativa appena illustrata. In questo modo diventa
   possibile usare le ordinarie funzioni per effettuare operazioni a 64 bit sui
-  file anche su sistemi a 32 bit.\footnote{basterà ricompilare il programma
+  file anche su sistemi a 32 bit.\footnote{basterà ricompilare il programma
     dopo averla definita, e saranno usate in modo trasparente le funzioni a 64
     bit.}
 
-  Se la macro non è definita o è definita con valore \texttt{32} questo
+  Se la macro non è definita o è definita con valore \texttt{32} questo
   comportamento viene disabilitato, e sui sistemi a 32 bit verranno usate le
-  ordinarie funzioni a 32 bit, non avendo più il supporto per file di grandi
+  ordinarie funzioni a 32 bit, non avendo più il supporto per file di grandi
   dimensioni. Su sistemi a 64 bit invece, dove il problema non sussiste, la
   macro non ha nessun effetto.
 
@@ -986,7 +986,7 @@ una opportuna macro; queste estensioni sono illustrate nel seguente elenco:
   sez.~\ref{sec:file_openat}.
 
 \item[\macro{\_REENTRANT}] definendo questa macro, o la equivalente
-  \macro{\_THREAD\_SAFE} (fornita per compatibilità) si rendono disponibili le
+  \macro{\_THREAD\_SAFE} (fornita per compatibilità) si rendono disponibili le
   versioni \index{funzioni!rientranti} rientranti (vedi
   sez.~\ref{sec:proc_reentrant}) di alcune funzioni, necessarie quando si
   usano i \itindex{thread} \textit{thread}.  Alcune di queste funzioni sono
@@ -998,12 +998,12 @@ una opportuna macro; queste estensioni sono illustrate nel seguente elenco:
   l'inserimento di alcuni controlli per alcune funzioni di allocazione e
   manipolazione di memoria e stringhe che consentono di rilevare
   automaticamente alcuni errori di \textit{buffer overflow} nell'uso delle
-  stesse. La funzionalità è stata introdotta a partire dalla versione 2.3.4
+  stesse. La funzionalità è stata introdotta a partire dalla versione 2.3.4
   delle \acr{glibc} e richiede anche il supporto da parte del compilatore, che
-  è disponibile solo a partire dalla versione 4.0 del \texttt{gcc}.
+  è disponibile solo a partire dalla versione 4.0 del \texttt{gcc}.
 
   Le funzioni di libreria che vengono messe sotto controllo quando questa
-  funzionalità viene attivata sono, al momento della stesura di queste note,
+  funzionalità viene attivata sono, al momento della stesura di queste note,
   le seguenti: \func{memcpy}, \func{mempcpy}, \func{memmove}, \func{memset},
   \func{stpcpy}, \func{strcpy}, \func{strncpy}, \func{strcat}, \func{strncat},
   \func{sprintf}, \func{snprintf}, \func{vsprintf}, \func{vsnprintf}, e
@@ -1017,11 +1017,11 @@ una opportuna macro; queste estensioni sono illustrate nel seguente elenco:
 
 \end{basedescript}
 
-Se non è stata specificata esplicitamente nessuna di queste macro il default
-assunto è che siano definite \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
+Se non è stata specificata esplicitamente nessuna di queste macro il default
+assunto è che siano definite \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
 \macro{\_POSIX\_SOURCE}, e \macro{\_POSIX\_C\_SOURCE} con valore
 ``\texttt{200112L}'' (o ``\texttt{199506L}'' per le versioni delle \acr{glibc}
-precedenti la 2.4). Si ricordi infine che perché queste macro abbiano effetto
+precedenti la 2.4). Si ricordi infine che perché queste macro abbiano effetto
 devono essere sempre definite prima dell'inclusione dei file di dichiarazione.
 
 
diff --git a/ipc.tex b/ipc.tex
index 491d29d..bb9e0b0 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -13,15 +13,15 @@
 \label{cha:IPC}
 
 
-Uno degli aspetti fondamentali della programmazione in un sistema unix-like è
+Uno degli aspetti fondamentali della programmazione in un sistema unix-like è
 la comunicazione fra processi. In questo capitolo affronteremo solo i
-meccanismi più elementari che permettono di mettere in comunicazione processi
+meccanismi più elementari che permettono di mettere in comunicazione processi
 diversi, come quelli tradizionali che coinvolgono \textit{pipe} e
 \textit{fifo} e i meccanismi di intercomunicazione di System V e quelli POSIX.
 
 Tralasceremo invece tutte le problematiche relative alla comunicazione
 attraverso la rete (e le relative interfacce) che saranno affrontate in
-dettaglio in un secondo tempo.  Non affronteremo neanche meccanismi più
+dettaglio in un secondo tempo.  Non affronteremo neanche meccanismi più
 complessi ed evoluti come le RPC (\textit{Remote Procedure Calls}) e CORBA
 (\textit{Common Object Request Brocker Architecture}) che in genere sono
 implementati con un ulteriore livello sopra i meccanismi elementari.
@@ -31,45 +31,45 @@ implementati con un ulteriore livello sopra i meccanismi elementari.
 \label{sec:ipc_unix}
 
 Il primo meccanismo di comunicazione fra processi introdotto nei sistemi Unix,
-è quello delle cosiddette \textit{pipe}; esse costituiscono una delle
+è quello delle cosiddette \textit{pipe}; esse costituiscono una delle
 caratteristiche peculiari del sistema, in particolar modo dell'interfaccia a
 linea di comando. In questa sezione descriveremo le sue basi, le funzioni che
-ne gestiscono l'uso e le varie forme in cui si è evoluto.
+ne gestiscono l'uso e le varie forme in cui si è evoluto.
 
 
 \subsection{Le \textit{pipe} standard}
 \label{sec:ipc_pipes}
 
 Le \textit{pipe} nascono sostanzialmente con Unix, e sono il primo, e tuttora
-uno dei più usati, meccanismi di comunicazione fra processi. Si tratta in
+uno dei più usati, meccanismi di comunicazione fra processi. Si tratta in
 sostanza di una coppia di file descriptor\footnote{si tenga presente che
   le pipe sono oggetti creati dal kernel e non risiedono su disco.} connessi
-fra di loro in modo che se quanto scrive su di uno si può rileggere
-dall'altro. Si viene così a costituire un canale di comunicazione tramite i
+fra di loro in modo che se quanto scrive su di uno si può rileggere
+dall'altro. Si viene così a costituire un canale di comunicazione tramite i
 due file descriptor, nella forma di un \textsl{tubo} (da cui il nome)
 attraverso cui fluiscono i dati.
 
 La funzione che permette di creare questa speciale coppia di file descriptor
-associati ad una \textit{pipe} è appunto \funcd{pipe}, ed il suo prototipo è:
+associati ad una \textit{pipe} è appunto \funcd{pipe}, ed il suo prototipo è:
 \begin{prototype}{unistd.h}
 {int pipe(int filedes[2])} 
   
 Crea una coppia di file descriptor associati ad una \textit{pipe}.
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
-    errore, nel qual caso \var{errno} potrà assumere i valori \errval{EMFILE},
+    errore, nel qual caso \var{errno} potrà assumere i valori \errval{EMFILE},
     \errval{ENFILE} e \errval{EFAULT}.}
 \end{prototype}
 
 La funzione restituisce la coppia di file descriptor nel vettore
-\param{filedes}; il primo è aperto in lettura ed il secondo in scrittura. Come
-accennato concetto di funzionamento di una pipe è semplice: quello che si
+\param{filedes}; il primo è aperto in lettura ed il secondo in scrittura. Come
+accennato concetto di funzionamento di una pipe è semplice: quello che si
 scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale
 nel file descriptor aperto in lettura. I file descriptor infatti non sono
 connessi a nessun file reale, ma, come accennato in
 sez.~\ref{sec:file_sendfile_splice}, ad un buffer nel kernel, la cui
-dimensione è specificata dal parametro di sistema \const{PIPE\_BUF}, (vedi
-sez.~\ref{sec:sys_file_limits}). Lo schema di funzionamento di una pipe è
+dimensione è specificata dal parametro di sistema \const{PIPE\_BUF}, (vedi
+sez.~\ref{sec:sys_file_limits}). Lo schema di funzionamento di una pipe è
 illustrato in fig.~\ref{fig:ipc_pipe_singular}, in cui sono illustrati i due
 capi della pipe, associati a ciascun file descriptor, con le frecce che
 indicano la direzione del flusso dei dati.
@@ -82,13 +82,13 @@ indicano la direzione del flusso dei dati.
 \end{figure}
 
 Chiaramente creare una pipe all'interno di un singolo processo non serve a
-niente; se però ricordiamo quanto esposto in sez.~\ref{sec:file_sharing}
-riguardo al comportamento dei file descriptor nei processi figli, è immediato
+niente; se però ricordiamo quanto esposto in sez.~\ref{sec:file_sharing}
+riguardo al comportamento dei file descriptor nei processi figli, è immediato
 capire come una pipe possa diventare un meccanismo di intercomunicazione. Un
 processo figlio infatti condivide gli stessi file descriptor del padre,
 compresi quelli associati ad una pipe (secondo la situazione illustrata in
 fig.~\ref{fig:ipc_pipe_fork}). In questo modo se uno dei processi scrive su un
-capo della pipe, l'altro può leggere.
+capo della pipe, l'altro può leggere.
 
 \begin{figure}[htb]
   \centering
@@ -98,32 +98,32 @@ capo della pipe, l'altro pu
   \label{fig:ipc_pipe_fork}
 \end{figure}
 
-Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
-comunicazione fra processi attraverso una pipe, utilizzando le proprietà
-ordinarie dei file, ma ci mostra anche qual è il principale\footnote{Stevens
-  in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
-  unidirezionale, ma in realtà questo è un limite facilmente superabile usando
-  una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
+Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
+comunicazione fra processi attraverso una pipe, utilizzando le proprietà
+ordinarie dei file, ma ci mostra anche qual è il principale\footnote{Stevens
+  in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
+  unidirezionale, ma in realtà questo è un limite facilmente superabile usando
+  una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
 processi possano condividere i file descriptor della pipe, e per questo essi
-devono comunque essere \textsl{parenti} (dall'inglese \textit{siblings}), cioè
-o derivare da uno stesso processo padre in cui è avvenuta la creazione della
-pipe, o, più comunemente, essere nella relazione padre/figlio.
+devono comunque essere \textsl{parenti} (dall'inglese \textit{siblings}), cioè
+o derivare da uno stesso processo padre in cui è avvenuta la creazione della
+pipe, o, più comunemente, essere nella relazione padre/figlio.
 
-A differenza di quanto avviene con i file normali, la lettura da una pipe può
+A differenza di quanto avviene con i file normali, la lettura da una pipe può
 essere bloccante (qualora non siano presenti dati), inoltre se si legge da una
-pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
-(vale a dire che la funzione \func{read} ritornerà restituendo 0).  Se invece
-si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
-processo riceverà il segnale \const{SIGPIPE}, e la funzione di scrittura
-restituirà un errore di \errcode{EPIPE} (al ritorno del gestore, o qualora il
+pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
+(vale a dire che la funzione \func{read} ritornerà restituendo 0).  Se invece
+si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
+processo riceverà il segnale \const{SIGPIPE}, e la funzione di scrittura
+restituirà un errore di \errcode{EPIPE} (al ritorno del gestore, o qualora il
 segnale sia ignorato o bloccato).
 
-La dimensione del buffer della pipe (\const{PIPE\_BUF}) ci dà inoltre un'altra
+La dimensione del buffer della pipe (\const{PIPE\_BUF}) ci dà inoltre un'altra
 importante informazione riguardo il comportamento delle operazioni di lettura
 e scrittura su di una pipe; esse infatti sono atomiche fintanto che la
-quantità di dati da scrivere non supera questa dimensione. Qualora ad esempio
-si effettui una scrittura di una quantità di dati superiore l'operazione verrà
-effettuata in più riprese, consentendo l'intromissione di scritture effettuate
+quantità di dati da scrivere non supera questa dimensione. Qualora ad esempio
+si effettui una scrittura di una quantità di dati superiore l'operazione verrà
+effettuata in più riprese, consentendo l'intromissione di scritture effettuate
 da altri processi.
 
 
@@ -131,10 +131,10 @@ da altri processi.
 \label{sec:ipc_pipe_use}
 
 Per capire meglio il funzionamento delle pipe faremo un esempio di quello che
-è il loro uso più comune, analogo a quello effettuato della shell, e che
+è il loro uso più comune, analogo a quello effettuato della shell, e che
 consiste nell'inviare l'output di un processo (lo standard output) sull'input
 di un altro. Realizzeremo il programma di esempio nella forma di un
-\textit{CGI}\footnote{un CGI (\textit{Common Gateway Interface}) è un
+\textit{CGI}\footnote{un CGI (\textit{Common Gateway Interface}) è un
   programma che permette la creazione dinamica di un oggetto da inserire
   all'interno di una pagina HTML.}  per Apache, che genera una immagine JPEG
 di un codice a barre, specificato come argomento in ingresso.
@@ -149,15 +149,15 @@ solito ha la forma:
 ed il risultato dell'elaborazione deve essere presentato (con una intestazione
 che ne descrive il mime-type) sullo standard output, in modo che il web-server
 possa reinviarlo al browser che ha effettuato la richiesta, che in questo modo
-è in grado di visualizzarlo opportunamente.
+è in grado di visualizzarlo opportunamente.
 
 Per realizzare quanto voluto useremo in sequenza i programmi \cmd{barcode} e
-\cmd{gs}, il primo infatti è in grado di generare immagini PostScript di
+\cmd{gs}, il primo infatti è in grado di generare immagini PostScript di
 codici a barre corrispondenti ad una qualunque stringa, mentre il secondo
 serve per poter effettuare la conversione della stessa immagine in formato
 JPEG. Usando una pipe potremo inviare l'output del primo sull'input del
 secondo, secondo lo schema mostrato in fig.~\ref{fig:ipc_pipe_use}, in cui la
-direzione del flusso dei dati è data dalle frecce continue.
+direzione del flusso dei dati è data dalle frecce continue.
 
 \begin{figure}[htb]
   \centering
@@ -168,26 +168,26 @@ direzione del flusso dei dati 
   \label{fig:ipc_pipe_use}
 \end{figure}
 
-Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato
-intermedio su un file temporaneo. Questo però non tiene conto del fatto che un
-\textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
+Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato
+intermedio su un file temporaneo. Questo però non tiene conto del fatto che un
+\textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
 evidente \itindex{race~condition} \textit{race condition} in caso di accesso
 simultaneo a detto file.\footnote{il problema potrebbe essere superato
   determinando in anticipo un nome appropriato per il file temporaneo, che
   verrebbe utilizzato dai vari sotto-processi, e cancellato alla fine della
-  loro esecuzione; ma a questo punto le cose non sarebbero più tanto
+  loro esecuzione; ma a questo punto le cose non sarebbero più tanto
   semplici.}  L'uso di una pipe invece permette di risolvere il problema in
-maniera semplice ed elegante, oltre ad essere molto più efficiente, dato che
+maniera semplice ed elegante, oltre ad essere molto più efficiente, dato che
 non si deve scrivere su disco.
 
-Il programma ci servirà anche come esempio dell'uso delle funzioni di
+Il programma ci servirà anche come esempio dell'uso delle funzioni di
 duplicazione dei file descriptor che abbiamo trattato in
-sez.~\ref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
-funzioni infatti che è possibile dirottare gli stream standard dei processi
+sez.~\ref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
+funzioni infatti che è possibile dirottare gli stream standard dei processi
 (che abbiamo visto in sez.~\ref{sec:file_std_descr} e
 sez.~\ref{sec:file_std_stream}) sulla pipe. In
 fig.~\ref{fig:ipc_barcodepage_code} abbiamo riportato il corpo del programma,
-il cui codice completo è disponibile nel file \file{BarCodePage.c} che si
+il cui codice completo è disponibile nel file \file{BarCodePage.c} che si
 trova nella directory dei sorgenti.
 
 \begin{figure}[!htb]
@@ -201,18 +201,18 @@ trova nella directory dei sorgenti.
   \label{fig:ipc_barcodepage_code}
 \end{figure}
 
-La prima operazione del programma (\texttt{\small 4--12}) è quella di creare
+La prima operazione del programma (\texttt{\small 4--12}) è quella di creare
 le due pipe che serviranno per la comunicazione fra i due comandi utilizzati
 per produrre il codice a barre; si ha cura di controllare la riuscita della
 chiamata, inviando in caso di errore un messaggio invece dell'immagine
-richiesta.\footnote{la funzione \func{WriteMess} non è riportata in
+richiesta.\footnote{la funzione \func{WriteMess} non è riportata in
   fig.~\ref{fig:ipc_barcodepage_code}; essa si incarica semplicemente di
   formattare l'uscita alla maniera dei CGI, aggiungendo l'opportuno
   \textit{mime type}, e formattando il messaggio in HTML, in modo che
   quest'ultimo possa essere visualizzato correttamente da un browser.}
 
-Una volta create le pipe, il programma può creare (\texttt{\small 13-17}) il
-primo processo figlio, che si incaricherà (\texttt{\small 19--25}) di eseguire
+Una volta create le pipe, il programma può creare (\texttt{\small 13-17}) il
+primo processo figlio, che si incaricherà (\texttt{\small 19--25}) di eseguire
 \cmd{barcode}. Quest'ultimo legge dallo standard input una stringa di
 caratteri, la converte nell'immagine PostScript del codice a barre ad essa
 corrispondente, e poi scrive il risultato direttamente sullo standard output.
@@ -230,54 +230,54 @@ output (\texttt{\small 23}).
 
 In questo modo all'esecuzione (\texttt{\small 25}) di \cmd{barcode} (cui si
 passa in \var{size} la dimensione della pagina per l'immagine) quest'ultimo
-leggerà dalla prima pipe la stringa da codificare che gli sarà inviata dal
-padre, e scriverà l'immagine PostScript del codice a barre sulla seconda.
+leggerà dalla prima pipe la stringa da codificare che gli sarà inviata dal
+padre, e scriverà l'immagine PostScript del codice a barre sulla seconda.
 
 Al contempo una volta lanciato il primo figlio, il processo padre prima chiude
 (\texttt{\small 26}) il capo inutilizzato della prima pipe (quello in input) e
 poi scrive (\texttt{\small 27}) la stringa da convertire sul capo in output,
-così che \cmd{barcode} possa riceverla dallo standard input. A questo punto
-l'uso della prima pipe da parte del padre è finito ed essa può essere
+così che \cmd{barcode} possa riceverla dallo standard input. A questo punto
+l'uso della prima pipe da parte del padre è finito ed essa può essere
 definitivamente chiusa (\texttt{\small 28}), si attende poi (\texttt{\small
   29}) che l'esecuzione di \cmd{barcode} sia completata.
 
-Alla conclusione della sua esecuzione \cmd{barcode} avrà inviato l'immagine
+Alla conclusione della sua esecuzione \cmd{barcode} avrà inviato l'immagine
 PostScript del codice a barre sul capo in scrittura della seconda pipe; a
-questo punto si può eseguire la seconda conversione, da PS a JPEG, usando il
+questo punto si può eseguire la seconda conversione, da PS a JPEG, usando il
 programma \cmd{gs}. Per questo si crea (\texttt{\small 30--34}) un secondo
-processo figlio, che poi (\texttt{\small 35--42}) eseguirà questo programma
+processo figlio, che poi (\texttt{\small 35--42}) eseguirà questo programma
 leggendo l'immagine PostScript creata da \cmd{barcode} dallo standard input,
 per convertirla in JPEG.
 
-Per fare tutto ciò anzitutto si chiude (\texttt{\small 37}) il capo in
+Per fare tutto ciò anzitutto si chiude (\texttt{\small 37}) il capo in
 scrittura della seconda pipe, e se ne collega (\texttt{\small 38}) il capo in
 lettura allo standard input. Per poter formattare l'output del programma in
 maniera utilizzabile da un browser, si provvede anche \texttt{\small 40}) alla
 scrittura dell'apposita stringa di identificazione del mime-type in testa allo
-standard output. A questo punto si può invocare \texttt{\small 41}) \cmd{gs},
+standard output. A questo punto si può invocare \texttt{\small 41}) \cmd{gs},
 provvedendo gli appositi switch che consentono di leggere il file da
 convertire dallo standard input e di inviare la conversione sullo standard
 output.
 
 Per completare le operazioni il processo padre chiude (\texttt{\small 44}) il
 capo in scrittura della seconda pipe, e attende la conclusione del figlio
-(\texttt{\small 45}); a questo punto può (\texttt{\small 46}) uscire. Si tenga
-conto che l'operazione di chiudere il capo in scrittura della seconda pipe è
+(\texttt{\small 45}); a questo punto può (\texttt{\small 46}) uscire. Si tenga
+conto che l'operazione di chiudere il capo in scrittura della seconda pipe è
 necessaria, infatti, se non venisse chiusa, \cmd{gs}, che legge il suo
 standard input da detta pipe, resterebbe bloccato in attesa di ulteriori dati
-in ingresso (l'unico modo che un programma ha per sapere che l'input è
-terminato è rilevare che lo standard input è stato chiuso), e la \func{wait}
+in ingresso (l'unico modo che un programma ha per sapere che l'input è
+terminato è rilevare che lo standard input è stato chiuso), e la \func{wait}
 non ritornerebbe.
 
 
 \subsection{Le funzioni \func{popen} e \func{pclose}}
 \label{sec:ipc_popen}
 
-Come si è visto la modalità più comune di utilizzo di una pipe è quella di
+Come si è visto la modalità più comune di utilizzo di una pipe è quella di
 utilizzarla per fare da tramite fra output ed input di due programmi invocati
 in sequenza; per questo motivo lo standard POSIX.2 ha introdotto due funzioni
 che permettono di sintetizzare queste operazioni. La prima di esse si chiama
-\funcd{popen} ed il suo prototipo è:
+\funcd{popen} ed il suo prototipo è:
 \begin{prototype}{stdio.h}
 {FILE *popen(const char *command, const char *type)}
 
@@ -287,27 +287,27 @@ stream restituito come valore di ritorno.
   
 \bodydesc{La funzione restituisce l'indirizzo dello stream associato alla pipe
   in caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
-  potrà assumere i valori relativi alle sottostanti invocazioni di \func{pipe}
-  e \func{fork} o \errcode{EINVAL} se \param{type} non è valido.}
+  potrà assumere i valori relativi alle sottostanti invocazioni di \func{pipe}
+  e \func{fork} o \errcode{EINVAL} se \param{type} non è valido.}
 \end{prototype}
 
 La funzione crea una pipe, esegue una \func{fork}, ed invoca il programma
 \param{command} attraverso la shell (in sostanza esegue \file{/bin/sh} con il
 flag \code{-c}); l'argomento \param{type} deve essere una delle due stringhe
-\verb|"w"| o \verb|"r"|, per indicare se la pipe sarà collegata allo standard
+\verb|"w"| o \verb|"r"|, per indicare se la pipe sarà collegata allo standard
 input o allo standard output del comando invocato.
 
 La funzione restituisce il puntatore allo stream associato alla pipe creata,
-che sarà aperto in sola lettura (e quindi associato allo standard output del
+che sarà aperto in sola lettura (e quindi associato allo standard output del
 programma indicato) in caso si sia indicato \code{"r"}, o in sola scrittura (e
 quindi associato allo standard input) in caso di \code{"w"}.
 
-Lo stream restituito da \func{popen} è identico a tutti gli effetti ai file
-stream visti in cap.~\ref{cha:files_std_interface}, anche se è collegato ad
-una pipe e non ad un file, e viene sempre aperto in modalità
+Lo stream restituito da \func{popen} è identico a tutti gli effetti ai file
+stream visti in cap.~\ref{cha:files_std_interface}, anche se è collegato ad
+una pipe e non ad un file, e viene sempre aperto in modalità
 \textit{fully-buffered} (vedi sez.~\ref{sec:file_buffering}); l'unica
-differenza con gli usuali stream è che dovrà essere chiuso dalla seconda delle
-due nuove funzioni, \funcd{pclose}, il cui prototipo è:
+differenza con gli usuali stream è che dovrà essere chiuso dalla seconda delle
+due nuove funzioni, \funcd{pclose}, il cui prototipo è:
 \begin{prototype}{stdio.h}
 {int pclose(FILE *stream)}
 
@@ -324,55 +324,55 @@ attendendo la terminazione del processo ad essa associato.
 
 Per illustrare l'uso di queste due funzioni riprendiamo il problema
 precedente: il programma mostrato in fig.~\ref{fig:ipc_barcodepage_code} per
-quanto funzionante, è (volutamente) codificato in maniera piuttosto complessa,
-inoltre nella pratica sconta un problema di \cmd{gs} che non è in
+quanto funzionante, è (volutamente) codificato in maniera piuttosto complessa,
+inoltre nella pratica sconta un problema di \cmd{gs} che non è in
 grado\footnote{nella versione GNU Ghostscript 6.53 (2002-02-13).} di
 riconoscere correttamente l'Encapsulated PostScript, per cui deve essere usato
 il PostScript e tutte le volte viene generata una pagina intera, invece che
 una immagine delle dimensioni corrispondenti al codice a barre.
 
 Se si vuole generare una immagine di dimensioni appropriate si deve usare un
-approccio diverso. Una possibilità sarebbe quella di ricorrere ad ulteriore
-programma, \cmd{epstopsf}, per convertire in PDF un file EPS (che può essere
+approccio diverso. Una possibilità sarebbe quella di ricorrere ad ulteriore
+programma, \cmd{epstopsf}, per convertire in PDF un file EPS (che può essere
 generato da \cmd{barcode} utilizzando lo switch \cmd{-E}).  Utilizzando un PDF
 al posto di un EPS \cmd{gs} esegue la conversione rispettando le dimensioni
 originarie del codice a barre e produce un JPEG di dimensioni corrette.
 
-Questo approccio però non funziona, per via di una delle caratteristiche
-principali delle pipe. Per poter effettuare la conversione di un PDF infatti è
+Questo approccio però non funziona, per via di una delle caratteristiche
+principali delle pipe. Per poter effettuare la conversione di un PDF infatti è
 necessario, per la struttura del formato, potersi spostare (con \func{lseek})
 all'interno del file da convertire; se si esegue la conversione con \cmd{gs}
-su un file regolare non ci sono problemi, una pipe però è rigidamente
+su un file regolare non ci sono problemi, una pipe però è rigidamente
 sequenziale, e l'uso di \func{lseek} su di essa fallisce sempre con un errore
 di \errcode{ESPIPE}, rendendo impossibile la conversione.  Questo ci dice che
-in generale la concatenazione di vari programmi funzionerà soltanto quando
+in generale la concatenazione di vari programmi funzionerà soltanto quando
 tutti prevedono una lettura sequenziale del loro input.
 
-Per questo motivo si è dovuto utilizzare un procedimento diverso, eseguendo
+Per questo motivo si è dovuto utilizzare un procedimento diverso, eseguendo
 prima la conversione (sempre con \cmd{gs}) del PS in un altro formato
-intermedio, il PPM,\footnote{il \textit{Portable PixMap file format} è un
-  formato usato spesso come formato intermedio per effettuare conversioni, è
+intermedio, il PPM,\footnote{il \textit{Portable PixMap file format} è un
+  formato usato spesso come formato intermedio per effettuare conversioni, è
   infatti molto facile da manipolare, dato che usa caratteri ASCII per
-  memorizzare le immagini, anche se per questo è estremamente inefficiente.}
-dal quale poi si può ottenere un'immagine di dimensioni corrette attraverso
-vari programmi di manipolazione (\cmd{pnmcrop}, \cmd{pnmmargin}) che può
+  memorizzare le immagini, anche se per questo è estremamente inefficiente.}
+dal quale poi si può ottenere un'immagine di dimensioni corrette attraverso
+vari programmi di manipolazione (\cmd{pnmcrop}, \cmd{pnmmargin}) che può
 essere infine trasformata in PNG (con \cmd{pnm2png}).
 
-In questo caso però occorre eseguire in sequenza ben quattro comandi diversi,
+In questo caso però occorre eseguire in sequenza ben quattro comandi diversi,
 inviando l'output di ciascuno all'input del successivo, per poi ottenere il
 risultato finale sullo standard output: un caso classico di utilizzazione
 delle pipe, in cui l'uso di \func{popen} e \func{pclose} permette di
 semplificare notevolmente la stesura del codice.
 
 Nel nostro caso, dato che ciascun processo deve scrivere il suo output sullo
-standard input del successivo, occorrerà usare \func{popen} aprendo la pipe in
-scrittura. Il codice del nuovo programma è riportato in
-fig.~\ref{fig:ipc_barcode_code}.  Come si può notare l'ordine di invocazione
-dei programmi è l'inverso di quello in cui ci si aspetta che vengano
+standard input del successivo, occorrerà usare \func{popen} aprendo la pipe in
+scrittura. Il codice del nuovo programma è riportato in
+fig.~\ref{fig:ipc_barcode_code}.  Come si può notare l'ordine di invocazione
+dei programmi è l'inverso di quello in cui ci si aspetta che vengano
 effettivamente eseguiti. Questo non comporta nessun problema dato che la
-lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
-per primo, si bloccherà in attesa di ricevere sullo standard input il
-risultato dell'elaborazione del precedente, benché quest'ultimo venga invocato
+lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
+per primo, si bloccherà in attesa di ricevere sullo standard input il
+risultato dell'elaborazione del precedente, benché quest'ultimo venga invocato
 dopo.
 
 \begin{figure}[!htb]
@@ -385,26 +385,26 @@ dopo.
   \label{fig:ipc_barcode_code}
 \end{figure}
 
-Nel nostro caso il primo passo (\texttt{\small 14}) è scrivere il mime-type
-sullo standard output; a questo punto il processo padre non necessita più di
-eseguire ulteriori operazioni sullo standard output e può tranquillamente
+Nel nostro caso il primo passo (\texttt{\small 14}) è scrivere il mime-type
+sullo standard output; a questo punto il processo padre non necessita più di
+eseguire ulteriori operazioni sullo standard output e può tranquillamente
 provvedere alla redirezione.
 
-Dato che i vari programmi devono essere lanciati in successione, si è
+Dato che i vari programmi devono essere lanciati in successione, si è
 approntato un ciclo (\texttt{\small 15--19}) che esegue le operazioni in
 sequenza: prima crea una pipe (\texttt{\small 17}) per la scrittura eseguendo
 il programma con \func{popen}, in modo che essa sia collegata allo standard
 input, e poi redirige (\texttt{\small 18}) lo standard output su detta pipe.
 
-In questo modo il primo processo ad essere invocato (che è l'ultimo della
-catena) scriverà ancora sullo standard output del processo padre, ma i
+In questo modo il primo processo ad essere invocato (che è l'ultimo della
+catena) scriverà ancora sullo standard output del processo padre, ma i
 successivi, a causa di questa redirezione, scriveranno sulla pipe associata
 allo standard input del processo invocato nel ciclo precedente.
 
-Alla fine tutto quello che resta da fare è lanciare (\texttt{\small 21}) il
-primo processo della catena, che nel caso è \cmd{barcode}, e scrivere
-(\texttt{\small 23}) la stringa del codice a barre sulla pipe, che è collegata
-al suo standard input, infine si può eseguire (\texttt{\small 24--27}) un
+Alla fine tutto quello che resta da fare è lanciare (\texttt{\small 21}) il
+primo processo della catena, che nel caso è \cmd{barcode}, e scrivere
+(\texttt{\small 23}) la stringa del codice a barre sulla pipe, che è collegata
+al suo standard input, infine si può eseguire (\texttt{\small 24--27}) un
 ciclo che chiuda, nell'ordine inverso rispetto a quello in cui le si sono
 create, tutte le pipe create con \func{pclose}.
 
@@ -412,13 +412,13 @@ create, tutte le pipe create con \func{pclose}.
 \subsection{Le \textit{pipe} con nome, o \textit{fifo}}
 \label{sec:ipc_named_pipe}
 
-Come accennato in sez.~\ref{sec:ipc_pipes} il problema delle \textit{pipe} è
+Come accennato in sez.~\ref{sec:ipc_pipes} il problema delle \textit{pipe} è
 che esse possono essere utilizzate solo da processi con un progenitore comune
 o nella relazione padre/figlio; per superare questo problema lo standard
 POSIX.1 ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
 caratteristiche delle pipe, ma che invece di essere strutture interne del
 kernel, visibili solo attraverso un file descriptor, sono accessibili
-attraverso un \index{inode} inode che risiede sul filesystem, così che i
+attraverso un \index{inode} inode che risiede sul filesystem, così che i
 processi le possono usare senza dovere per forza essere in una relazione di
 \textsl{parentela}.
 
@@ -426,46 +426,46 @@ Utilizzando una \textit{fifo} tutti i dati passeranno, come per le pipe,
 attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
 \index{inode} l'inode allocato sul filesystem serve infatti solo a fornire un
 punto di riferimento per i processi, che permetta loro di accedere alla stessa
-fifo; il comportamento delle funzioni di lettura e scrittura è identico a
+fifo; il comportamento delle funzioni di lettura e scrittura è identico a
 quello illustrato per le pipe in sez.~\ref{sec:ipc_pipes}.
 
-Abbiamo già visto in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
+Abbiamo già visto in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
 \func{mkfifo} che permettono di creare una fifo; per utilizzarne una un
-processo non avrà che da aprire il relativo file speciale o in lettura o
-scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
-leggere, nel secondo al capo di ingresso, e dovrà scrivere.
+processo non avrà che da aprire il relativo file speciale o in lettura o
+scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
+leggere, nel secondo al capo di ingresso, e dovrà scrivere.
 
-Il kernel crea una singola pipe per ciascuna fifo che sia stata aperta, che può
-essere acceduta contemporaneamente da più processi, sia in lettura che in
+Il kernel crea una singola pipe per ciascuna fifo che sia stata aperta, che può
+essere acceduta contemporaneamente da più processi, sia in lettura che in
 scrittura. Dato che per funzionare deve essere aperta in entrambe le
 direzioni, per una fifo di norma la funzione \func{open} si blocca se viene
-eseguita quando l'altro capo non è aperto.
+eseguita quando l'altro capo non è aperto.
 
-Le fifo però possono essere anche aperte in modalità \textsl{non-bloccante},
-nel qual caso l'apertura del capo in lettura avrà successo solo quando anche
-l'altro capo è aperto, mentre l'apertura del capo in scrittura restituirà
-l'errore di \errcode{ENXIO} fintanto che non verrà aperto il capo in lettura.
+Le fifo però possono essere anche aperte in modalità \textsl{non-bloccante},
+nel qual caso l'apertura del capo in lettura avrà successo solo quando anche
+l'altro capo è aperto, mentre l'apertura del capo in scrittura restituirà
+l'errore di \errcode{ENXIO} fintanto che non verrà aperto il capo in lettura.
 
-In Linux è possibile aprire le fifo anche in lettura/scrittura,\footnote{lo
+In Linux è possibile aprire le fifo anche in lettura/scrittura,\footnote{lo
   standard POSIX lascia indefinito il comportamento in questo caso.}
-operazione che avrà sempre successo immediato qualunque sia la modalità di
-apertura (bloccante e non bloccante); questo può essere utilizzato per aprire
+operazione che avrà sempre successo immediato qualunque sia la modalità di
+apertura (bloccante e non bloccante); questo può essere utilizzato per aprire
 comunque una fifo in scrittura anche se non ci sono ancora processi il
-lettura; è possibile anche usare la fifo all'interno di un solo processo, nel
-qual caso però occorre stare molto attenti alla possibili situazioni di
+lettura; è possibile anche usare la fifo all'interno di un solo processo, nel
+qual caso però occorre stare molto attenti alla possibili situazioni di
 stallo.\footnote{se si cerca di leggere da una fifo che non contiene dati si
-  avrà un \itindex{deadlock} deadlock immediato, dato che il processo si
-  blocca e non potrà quindi mai eseguire le funzioni di scrittura.}
+  avrà un \itindex{deadlock} deadlock immediato, dato che il processo si
+  blocca e non potrà quindi mai eseguire le funzioni di scrittura.}
 
-Per la loro caratteristica di essere accessibili attraverso il filesystem, è
+Per la loro caratteristica di essere accessibili attraverso il filesystem, è
 piuttosto frequente l'utilizzo di una fifo come canale di comunicazione nelle
-situazioni un processo deve ricevere informazioni da altri. In questo caso è
+situazioni un processo deve ricevere informazioni da altri. In questo caso è
 fondamentale che le operazioni di scrittura siano atomiche; per questo si deve
-sempre tenere presente che questo è vero soltanto fintanto che non si supera
+sempre tenere presente che questo è vero soltanto fintanto che non si supera
 il limite delle dimensioni di \const{PIPE\_BUF} (si ricordi quanto detto in
 sez.~\ref{sec:ipc_pipes}).
 
-A parte il caso precedente, che resta probabilmente il più comune, Stevens
+A parte il caso precedente, che resta probabilmente il più comune, Stevens
 riporta in \cite{APUE} altre due casistiche principali per l'uso delle fifo:
 \begin{itemize}
 \item Da parte dei comandi di shell, per evitare la creazione di file
@@ -473,25 +473,25 @@ riporta in \cite{APUE} altre due casistiche principali per l'uso delle fifo:
   sull'input di parecchi altri (attraverso l'uso del comando \cmd{tee}).
   
 \item Come canale di comunicazione fra client ed server (il modello
-  \textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}).
+  \textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}).
 \end{itemize}
 
-Nel primo caso quello che si fa è creare tante fifo, da usare come standard
+Nel primo caso quello che si fa è creare tante fifo, da usare come standard
 input, quanti sono i processi a cui i vogliono inviare i dati, questi ultimi
 saranno stati posti in esecuzione ridirigendo lo standard input dalle fifo, si
-potrà poi eseguire il processo che fornisce l'output replicando quest'ultimo,
+potrà poi eseguire il processo che fornisce l'output replicando quest'ultimo,
 con il comando \cmd{tee}, sulle varie fifo.
 
-Il secondo caso è relativamente semplice qualora si debba comunicare con un
+Il secondo caso è relativamente semplice qualora si debba comunicare con un
 processo alla volta (nel qual caso basta usare due fifo, una per leggere ed
-una per scrivere), le cose diventano invece molto più complesse quando si
+una per scrivere), le cose diventano invece molto più complesse quando si
 vuole effettuare una comunicazione fra il server ed un numero imprecisato di
-client; se il primo infatti può ricevere le richieste attraverso una fifo
-``\textsl{nota}'', per le risposte non si può fare altrettanto, dato che, per
+client; se il primo infatti può ricevere le richieste attraverso una fifo
+``\textsl{nota}'', per le risposte non si può fare altrettanto, dato che, per
 la struttura sequenziale delle fifo, i client dovrebbero sapere, prima di
 leggerli, quando i dati inviati sono destinati a loro.
 
-Per risolvere questo problema, si può usare un'architettura come quella
+Per risolvere questo problema, si può usare un'architettura come quella
 illustrata in fig.~\ref{fig:ipc_fifo_server_arch} in cui i client inviano le
 richieste al server su una fifo nota mentre le risposte vengono reinviate dal
 server a ciascuno di essi su una fifo temporanea creata per l'occasione.
@@ -508,12 +508,12 @@ Come esempio di uso questa architettura e dell'uso delle fifo, abbiamo scritto
 un server di \textit{fortunes}, che restituisce, alle richieste di un client,
 un detto a caso estratto da un insieme di frasi; sia il numero delle frasi
 dell'insieme, che i file da cui esse vengono lette all'avvio, sono importabili
-da riga di comando. Il corpo principale del server è riportato in
-fig.~\ref{fig:ipc_fifo_server}, dove si è tralasciata la parte che tratta la
+da riga di comando. Il corpo principale del server è riportato in
+fig.~\ref{fig:ipc_fifo_server}, dove si è tralasciata la parte che tratta la
 gestione delle opzioni a riga di comando, che effettua il settaggio delle
 variabili \var{fortunefilename}, che indica il file da cui leggere le frasi,
 ed \var{n}, che indica il numero di frasi tenute in memoria, ad un valore
-diverso da quelli preimpostati. Il codice completo è nel file
+diverso da quelli preimpostati. Il codice completo è nel file
 \file{FortuneServer.c}.
 
 \begin{figure}[!htb]
@@ -531,9 +531,9 @@ Il server richiede (\texttt{\small 12}) che sia stata impostata una dimensione
 dell'insieme delle frasi non nulla, dato che l'inizializzazione del vettore
 \var{fortune} avviene solo quando questa dimensione viene specificata, la
 presenza di un valore nullo provoca l'uscita dal programma attraverso la
-funzione (non riportata) che ne stampa le modalità d'uso.  Dopo di che
+funzione (non riportata) che ne stampa le modalità d'uso.  Dopo di che
 installa (\texttt{\small 13--15}) la funzione che gestisce i segnali di
-interruzione (anche questa non è riportata in fig.~\ref{fig:ipc_fifo_server})
+interruzione (anche questa non è riportata in fig.~\ref{fig:ipc_fifo_server})
 che si limita a rimuovere dal filesystem la fifo usata dal server per
 comunicare.
 
@@ -541,71 +541,71 @@ Terminata l'inizializzazione (\texttt{\small 16}) si effettua la chiamata alla
 funzione \code{FortuneParse} che legge dal file specificato in
 \var{fortunefilename} le prime \var{n} frasi e le memorizza (allocando
 dinamicamente la memoria necessaria) nel vettore di puntatori \var{fortune}.
-Anche il codice della funzione non è riportato, in quanto non direttamente
+Anche il codice della funzione non è riportato, in quanto non direttamente
 attinente allo scopo dell'esempio.
 
-Il passo successivo (\texttt{\small 17--22}) è quello di creare con
-\func{mkfifo} la fifo nota sulla quale il server ascolterà le richieste,
-qualora si riscontri un errore il server uscirà (escludendo ovviamente il caso
+Il passo successivo (\texttt{\small 17--22}) è quello di creare con
+\func{mkfifo} la fifo nota sulla quale il server ascolterà le richieste,
+qualora si riscontri un errore il server uscirà (escludendo ovviamente il caso
 in cui la funzione \func{mkfifo} fallisce per la precedente esistenza della
 fifo).
 
-Una volta che si è certi che la fifo di ascolto esiste la procedura di
-inizializzazione è completata. A questo punto si può chiamare (\texttt{\small
+Una volta che si è certi che la fifo di ascolto esiste la procedura di
+inizializzazione è completata. A questo punto si può chiamare (\texttt{\small
   23}) la funzione \func{daemon} per far proseguire l'esecuzione del programma
-in background come demone.  Si può quindi procedere (\texttt{\small 24--33})
+in background come demone.  Si può quindi procedere (\texttt{\small 24--33})
 alla apertura della fifo: si noti che questo viene fatto due volte, prima in
 lettura e poi in scrittura, per evitare di dover gestire all'interno del ciclo
-principale il caso in cui il server è in ascolto ma non ci sono client che
-effettuano richieste.  Si ricordi infatti che quando una fifo è aperta solo
+principale il caso in cui il server è in ascolto ma non ci sono client che
+effettuano richieste.  Si ricordi infatti che quando una fifo è aperta solo
 dal capo in lettura, l'esecuzione di \func{read} ritorna con zero byte (si ha
-cioè una condizione di end-of-file).
+cioè una condizione di end-of-file).
 
-Nel nostro caso la prima apertura si bloccherà fintanto che un qualunque
+Nel nostro caso la prima apertura si bloccherà fintanto che un qualunque
 client non apre a sua volta la fifo nota in scrittura per effettuare la sua
-richiesta. Pertanto all'inizio non ci sono problemi, il client però, una volta
-ricevuta la risposta, uscirà, chiudendo tutti i file aperti, compresa la fifo.
+richiesta. Pertanto all'inizio non ci sono problemi, il client però, una volta
+ricevuta la risposta, uscirà, chiudendo tutti i file aperti, compresa la fifo.
 A questo punto il server resta (se non ci sono altri client che stanno
 effettuando richieste) con la fifo chiusa sul lato in lettura, ed in questo
-stato la funzione \func{read} non si bloccherà in attesa di input, ma
-ritornerà in continuazione, restituendo un end-of-file.\footnote{si è usata
-  questa tecnica per compatibilità, Linux infatti supporta l'apertura delle
+stato la funzione \func{read} non si bloccherà in attesa di input, ma
+ritornerà in continuazione, restituendo un end-of-file.\footnote{si è usata
+  questa tecnica per compatibilità, Linux infatti supporta l'apertura delle
   fifo in lettura/scrittura, per cui si sarebbe potuto effettuare una singola
   apertura con \const{O\_RDWR}, la doppia apertura comunque ha il vantaggio
-  che non si può scrivere per errore sul capo aperto in sola lettura.}
+  che non si può scrivere per errore sul capo aperto in sola lettura.}
 
 Per questo motivo, dopo aver eseguito l'apertura in lettura (\texttt{\small
   24--28}),\footnote{di solito si effettua l'apertura del capo in lettura di
-  una fifo in modalità non bloccante, per evitare il rischio di uno stallo: se
-  infatti nessuno apre la fifo in scrittura il processo non ritornerà mai
-  dalla \func{open}. Nel nostro caso questo rischio non esiste, mentre è
+  una fifo in modalità non bloccante, per evitare il rischio di uno stallo: se
+  infatti nessuno apre la fifo in scrittura il processo non ritornerà mai
+  dalla \func{open}. Nel nostro caso questo rischio non esiste, mentre è
   necessario potersi bloccare in lettura in attesa di una richiesta.} si
 esegue una seconda apertura in scrittura (\texttt{\small 29--32}), scartando
-il relativo file descriptor, che non sarà mai usato, in questo modo però la
-fifo resta comunque aperta anche in scrittura, cosicché le successive chiamate
+il relativo file descriptor, che non sarà mai usato, in questo modo però la
+fifo resta comunque aperta anche in scrittura, cosicché le successive chiamate
 a \func{read} possono bloccarsi.
 
-A questo punto si può entrare nel ciclo principale del programma che fornisce
+A questo punto si può entrare nel ciclo principale del programma che fornisce
 le risposte ai client (\texttt{\small 34--50}); questo viene eseguito
 indefinitamente (l'uscita del server viene effettuata inviando un segnale, in
 modo da passare attraverso la funzione di chiusura che cancella la fifo).
 
-Il server è progettato per accettare come richieste dai client delle stringhe
+Il server è progettato per accettare come richieste dai client delle stringhe
 che contengono il nome della fifo sulla quale deve essere inviata la risposta.
 Per cui prima (\texttt{\small 35--39}) si esegue la lettura dalla stringa di
-richiesta dalla fifo nota (che a questo punto si bloccherà tutte le volte che
+richiesta dalla fifo nota (che a questo punto si bloccherà tutte le volte che
 non ci sono richieste). Dopo di che, una volta terminata la stringa
 (\texttt{\small 40}) e selezionato (\texttt{\small 41}) un numero casuale per
-ricavare la frase da inviare, si procederà (\texttt{\small 42--46})
+ricavare la frase da inviare, si procederà (\texttt{\small 42--46})
 all'apertura della fifo per la risposta, che poi \texttt{\small 47--48}) vi
-sarà scritta. Infine (\texttt{\small 49}) si chiude la fifo di risposta che
-non serve più.
+sarà scritta. Infine (\texttt{\small 49}) si chiude la fifo di risposta che
+non serve più.
 
-Il codice del client è invece riportato in fig.~\ref{fig:ipc_fifo_client},
-anche in questo caso si è omessa la gestione delle opzioni e la funzione che
+Il codice del client è invece riportato in fig.~\ref{fig:ipc_fifo_client},
+anche in questo caso si è omessa la gestione delle opzioni e la funzione che
 stampa a video le informazioni di utilizzo ed esce, riportando solo la sezione
 principale del programma e le definizioni delle variabili. Il codice completo
-è nel file \file{FortuneClient.c} dei sorgenti allegati.
+è nel file \file{FortuneClient.c} dei sorgenti allegati.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -618,42 +618,42 @@ principale del programma e le definizioni delle variabili. Il codice completo
   \label{fig:ipc_fifo_client}
 \end{figure}
 
-La prima istruzione (\texttt{\small 12}) compone il nome della fifo che dovrà
+La prima istruzione (\texttt{\small 12}) compone il nome della fifo che dovrà
 essere utilizzata per ricevere la risposta dal server.  Si usa il \acr{pid}
 del processo per essere sicuri di avere un nome univoco; dopo di che
 (\texttt{\small 13-18}) si procede alla creazione del relativo file, uscendo
-in caso di errore (a meno che il file non sia già presente sul filesystem).
+in caso di errore (a meno che il file non sia già presente sul filesystem).
 
-A questo punto il client può effettuare l'interrogazione del server, per
+A questo punto il client può effettuare l'interrogazione del server, per
 questo prima si apre la fifo nota (\texttt{\small 19--23}), e poi ci si scrive
 (\texttt{\small 24}) la stringa composta in precedenza, che contiene il nome
 della fifo da utilizzare per la risposta. Infine si richiude la fifo del
-server che a questo punto non serve più (\texttt{\small 25}).
+server che a questo punto non serve più (\texttt{\small 25}).
 
-Inoltrata la richiesta si può passare alla lettura della risposta; anzitutto
+Inoltrata la richiesta si può passare alla lettura della risposta; anzitutto
 si apre (\texttt{\small 26--30}) la fifo appena creata, da cui si deve
 riceverla, dopo di che si effettua una lettura (\texttt{\small 31})
-nell'apposito buffer; si è supposto, come è ragionevole, che le frasi inviate
+nell'apposito buffer; si è supposto, come è ragionevole, che le frasi inviate
 dal server siano sempre di dimensioni inferiori a \const{PIPE\_BUF},
-tralasciamo la gestione del caso in cui questo non è vero. Infine si stampa
+tralasciamo la gestione del caso in cui questo non è vero. Infine si stampa
 (\texttt{\small 32}) a video la risposta, si chiude (\texttt{\small 33}) la
 fifo e si cancella (\texttt{\small 34}) il relativo file.
 Si noti come la fifo per la risposta sia stata aperta solo dopo aver inviato
-la richiesta, se non si fosse fatto così si avrebbe avuto uno stallo, in
+la richiesta, se non si fosse fatto così si avrebbe avuto uno stallo, in
 quanto senza la richiesta, il server non avrebbe potuto aprirne il capo in
 scrittura e l'apertura si sarebbe bloccata indefinitamente.
 
 Verifichiamo allora il comportamento dei nostri programmi, in questo, come in
 altri esempi precedenti, si fa uso delle varie funzioni di servizio, che sono
 state raccolte nella libreria \file{libgapil.so}, per poter usare quest'ultima
-occorrerà definire la speciale variabile di ambiente \code{LD\_LIBRARY\_PATH}
+occorrerà definire la speciale variabile di ambiente \code{LD\_LIBRARY\_PATH}
 in modo che il linker dinamico possa accedervi.
 
 In generale questa variabile indica il \itindex{pathname} \textit{pathname}
 della directory contenente la libreria. Nell'ipotesi (che daremo sempre per
 verificata) che si facciano le prove direttamente nella directory dei sorgenti
 (dove di norma vengono creati sia i programmi che la libreria), il comando da
-dare sarà \code{export LD\_LIBRARY\_PATH=./}; a questo punto potremo lanciare
+dare sarà \code{export LD\_LIBRARY\_PATH=./}; a questo punto potremo lanciare
 il server, facendogli leggere una decina di frasi, con:
 \begin{Verbatim}
 [piccardi@gont sources]$ ./fortuned -n10
@@ -661,7 +661,7 @@ il server, facendogli leggere una decina di frasi, con:
 %$
 
 Avendo usato \func{daemon} per eseguire il server in background il comando
-ritornerà immediatamente, ma potremo verificare con \cmd{ps} che in effetti il
+ritornerà immediatamente, ma potremo verificare con \cmd{ps} che in effetti il
 programma resta un esecuzione in background, e senza avere associato un
 terminale di controllo (si ricordi quanto detto in sez.~\ref{sec:sess_daemon}):
 \begin{Verbatim}
@@ -671,13 +671,13 @@ piccardi 27489  0.0  0.0  1204  356 ?        S    01:06   0:00 ./fortuned -n10
 piccardi 27492  3.0  0.1  2492  764 pts/2    R    01:08   0:00 ps aux
 \end{Verbatim}
 %$
-e si potrà verificare anche che in \file{/tmp} è stata creata la fifo di
+e si potrà verificare anche che in \file{/tmp} è stata creata la fifo di
 ascolto \file{fortune.fifo}. A questo punto potremo interrogare il server con
-il programma client; otterremo così:
+il programma client; otterremo così:
 \begin{Verbatim}
 [piccardi@gont sources]$ ./fortune
 Linux ext2fs has been stable for a long time, now it's time to break it
-        -- Linuxkongreß '95 in Berlin
+        -- Linuxkongreß '95 in Berlin
 [piccardi@gont sources]$ ./fortune
 Let's call it an accidental feature.
         --Larry Wall
@@ -692,26 +692,26 @@ Let's call it an accidental feature.
         -- William E. Roadcap
 [piccardi@gont sources]$ ./fortune
 Linux ext2fs has been stable for a long time, now it's time to break it
-        -- Linuxkongreß '95 in Berlin
+        -- Linuxkongreß '95 in Berlin
 \end{Verbatim}
 %$
 e ripetendo varie volte il comando otterremo, in ordine casuale, le dieci
 frasi tenute in memoria dal server.
 
-Infine per chiudere il server basterà inviare un segnale di terminazione con
+Infine per chiudere il server basterà inviare un segnale di terminazione con
 \code{killall fortuned} e potremo verificare che il gestore del segnale ha
 anche correttamente cancellato la fifo di ascolto da \file{/tmp}.
 
-Benché il nostro sistema client-server funzioni, la sua struttura è piuttosto
+Benché il nostro sistema client-server funzioni, la sua struttura è piuttosto
 complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens,
   che esamina questa architettura in \cite{APUE}, nota come sia impossibile
-  per il server sapere se un client è andato in crash, con la possibilità di
+  per il server sapere se un client è andato in crash, con la possibilità di
   far restare le fifo temporanee sul filesystem, di come sia necessario
-  intercettare \const{SIGPIPE} dato che un client può terminare dopo aver
+  intercettare \const{SIGPIPE} dato che un client può terminare dopo aver
   fatto una richiesta, ma prima che la risposta sia inviata (cosa che nel
-  nostro esempio non è stata fatta).}; in generale infatti l'interfaccia delle
-fifo non è adatta a risolvere questo tipo di problemi, che possono essere
-affrontati in maniera più semplice ed efficace o usando i socket (che
+  nostro esempio non è stata fatta).}; in generale infatti l'interfaccia delle
+fifo non è adatta a risolvere questo tipo di problemi, che possono essere
+affrontati in maniera più semplice ed efficace o usando i socket (che
 tratteremo in dettaglio a partire da cap.~\ref{cha:socket_intro}) o ricorrendo
 a meccanismi di comunicazione diversi, come quelli che esamineremo in seguito.
 
@@ -721,17 +721,17 @@ a meccanismi di comunicazione diversi, come quelli che esamineremo in seguito.
 \label{sec:ipc_socketpair}
 
 Un meccanismo di comunicazione molto simile alle pipe, ma che non presenta il
-problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti
+problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti
 \textsl{socket locali} (o \textit{Unix domain socket}). Tratteremo l'argomento
 dei socket in cap.~\ref{cha:socket_intro},\footnote{si tratta comunque di
   oggetti di comunicazione che, come le pipe, sono utilizzati attraverso dei
   file descriptor.} nell'ambito dell'interfaccia generale che essi forniscono
 per la programmazione di rete; e vedremo anche
 (in~sez.~\ref{sec:sock_sa_local}) come si possono definire dei file speciali
-(di tipo socket, analoghi a quello associati alle fifo) cui si accede però
-attraverso quella medesima interfaccia; vale però la pena esaminare qui una
-modalità di uso dei socket locali\footnote{la funzione \func{socketpair} è
-  stata introdotta in BSD4.4, ma è supportata in genere da qualunque sistema
+(di tipo socket, analoghi a quello associati alle fifo) cui si accede però
+attraverso quella medesima interfaccia; vale però la pena esaminare qui una
+modalità di uso dei socket locali\footnote{la funzione \func{socketpair} è
+  stata introdotta in BSD4.4, ma è supportata in genere da qualunque sistema
   che fornisca l'interfaccia dei socket.} che li rende sostanzialmente
 identici ad una pipe bidirezionale.
 
@@ -739,8 +739,8 @@ La funzione \funcd{socketpair} infatti consente di creare una coppia di file
 descriptor connessi fra di loro (tramite un socket, appunto), senza dover
 ricorrere ad un file speciale sul filesystem, i descrittori sono del tutto
 analoghi a quelli che si avrebbero con una chiamata a \func{pipe}, con la sola
-differenza è che in questo caso il flusso dei dati può essere effettuato in
-entrambe le direzioni. Il prototipo della funzione è:
+differenza è che in questo caso il flusso dei dati può essere effettuato in
+entrambe le direzioni. Il prototipo della funzione è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/socket.h} 
@@ -750,10 +750,10 @@ entrambe le direzioni. Il prototipo della funzione 
   Crea una coppia di socket connessi fra loro.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
   \item[\errcode{EAFNOSUPPORT}] i socket locali non sono supportati.
-  \item[\errcode{EPROTONOSUPPORT}] il protocollo specificato non è supportato.
+  \item[\errcode{EPROTONOSUPPORT}] il protocollo specificato non è supportato.
   \item[\errcode{EOPNOTSUPP}] il protocollo specificato non supporta la
   creazione di coppie di socket.
   \end{errlist}
@@ -762,37 +762,37 @@ entrambe le direzioni. Il prototipo della funzione 
 \end{functions}
 
 La funzione restituisce in \param{sv} la coppia di descrittori connessi fra di
-loro: quello che si scrive su uno di essi sarà ripresentato in input
+loro: quello che si scrive su uno di essi sarà ripresentato in input
 sull'altro e viceversa. Gli argomenti \param{domain}, \param{type} e
 \param{protocol} derivano dall'interfaccia dei socket (vedi
-sez.~\ref{sec:sock_creation}) che è quella che fornisce il substrato per
+sez.~\ref{sec:sock_creation}) che è quella che fornisce il substrato per
 connettere i due descrittori, ma in questo caso i soli valori validi che
 possono essere specificati sono rispettivamente \const{AF\_UNIX},
 \const{SOCK\_STREAM} e \val{0}.
 
-L'utilità di chiamare questa funzione per evitare due chiamate a \func{pipe}
-può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei socket
+L'utilità di chiamare questa funzione per evitare due chiamate a \func{pipe}
+può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei socket
 locali in generale) permette di trasmettere attraverso le linea non solo dei
-dati, ma anche dei file descriptor: si può cioè passare da un processo ad un
+dati, ma anche dei file descriptor: si può cioè passare da un processo ad un
 altro un file descriptor, con una sorta di duplicazione dello stesso non
 all'interno di uno stesso processo, ma fra processi distinti (torneremo su
-questa funzionalità in sez.~\ref{sec:sock_fd_passing}).
+questa funzionalità in sez.~\ref{sec:sock_fd_passing}).
 
 
 \section{Il sistema di comunicazione fra processi di System V}
 \label{sec:ipc_sysv}
 
-Benché le pipe e le fifo siano ancora ampiamente usate, esse scontano il
-limite fondamentale che il meccanismo di comunicazione che forniscono è
+Benché le pipe e le fifo siano ancora ampiamente usate, esse scontano il
+limite fondamentale che il meccanismo di comunicazione che forniscono è
 rigidamente sequenziale: una situazione in cui un processo scrive qualcosa che
-molti altri devono poter leggere non può essere implementata con una pipe.
+molti altri devono poter leggere non può essere implementata con una pipe.
 
 Per questo nello sviluppo di System V vennero introdotti una serie di nuovi
 oggetti per la comunicazione fra processi ed una nuova interfaccia di
-programmazione, che fossero in grado di garantire una maggiore flessibilità.
+programmazione, che fossero in grado di garantire una maggiore flessibilità.
 In questa sezione esamineremo come Linux supporta quello che viene chiamato il
 \textsl{Sistema di comunicazione fra processi} di System V, cui da qui in
-avanti faremo riferimento come \textit{SysV IPC} (dove IPC è la sigla di
+avanti faremo riferimento come \textit{SysV IPC} (dove IPC è la sigla di
 \textit{Inter-Process Comunication}).
 
 
@@ -800,42 +800,42 @@ avanti faremo riferimento come \textit{SysV IPC} (dove IPC 
 \subsection{Considerazioni generali}
 \label{sec:ipc_sysv_generic}
 
-La principale caratteristica del \textit{SysV IPC} è quella di essere basato
+La principale caratteristica del \textit{SysV IPC} è quella di essere basato
 su oggetti permanenti che risiedono nel kernel. Questi, a differenza di quanto
 avviene per i file descriptor, non mantengono un contatore dei riferimenti, e
-non vengono cancellati dal sistema una volta che non sono più in uso.
+non vengono cancellati dal sistema una volta che non sono più in uso.
 
-Questo comporta due problemi: il primo è che, al contrario di quanto avviene
+Questo comporta due problemi: il primo è che, al contrario di quanto avviene
 per pipe e fifo, la memoria allocata per questi oggetti non viene rilasciata
-automaticamente quando non c'è più nessuno che li utilizzi, ed essi devono
+automaticamente quando non c'è più nessuno che li utilizzi, ed essi devono
 essere cancellati esplicitamente, se non si vuole che restino attivi fino al
-riavvio del sistema. Il secondo problema è che, dato che non c'è, come per i
+riavvio del sistema. Il secondo problema è che, dato che non c'è, come per i
 file, un contatore del numero di riferimenti che ne indichi l'essere in uso,
 essi possono essere cancellati anche se ci sono dei processi che li stanno
 utilizzando, con tutte le conseguenze (negative) del caso.
 
-Un'ulteriore caratteristica negativa è che gli oggetti usati nel \textit{SysV
+Un'ulteriore caratteristica negativa è che gli oggetti usati nel \textit{SysV
   IPC} vengono creati direttamente dal kernel, e sono accessibili solo
-specificando il relativo \textsl{identificatore}. Questo è un numero
+specificando il relativo \textsl{identificatore}. Questo è un numero
 progressivo (un po' come il \acr{pid} dei processi) che il kernel assegna a
 ciascuno di essi quanto vengono creati (sul procedimento di assegnazione
 torneremo in sez.~\ref{sec:ipc_sysv_id_use}). L'identificatore viene restituito
-dalle funzioni che creano l'oggetto, ed è quindi locale al processo che le ha
+dalle funzioni che creano l'oggetto, ed è quindi locale al processo che le ha
 eseguite. Dato che l'identificatore viene assegnato dinamicamente dal kernel
-non è possibile prevedere quale sarà, né utilizzare un qualche valore statico,
-si pone perciò il problema di come processi diversi possono accedere allo
+non è possibile prevedere quale sarà, né utilizzare un qualche valore statico,
+si pone perciò il problema di come processi diversi possono accedere allo
 stesso oggetto.
 
 Per risolvere il problema nella struttura \struct{ipc\_perm} che il kernel
 associa a ciascun oggetto, viene mantenuto anche un campo apposito che
 contiene anche una \textsl{chiave}, identificata da una variabile del tipo
 primitivo \type{key\_t}, da specificare in fase di creazione dell'oggetto, e
-tramite la quale è possibile ricavare l'identificatore.\footnote{in sostanza
+tramite la quale è possibile ricavare l'identificatore.\footnote{in sostanza
   si sposta il problema dell'accesso dalla classificazione in base
   all'identificatore alla classificazione in base alla chiave, una delle tante
   complicazioni inutili presenti nel \textit{SysV IPC}.} Oltre la chiave, la
-struttura, la cui definizione è riportata in fig.~\ref{fig:ipc_ipc_perm},
-mantiene varie proprietà ed informazioni associate all'oggetto.
+struttura, la cui definizione è riportata in fig.~\ref{fig:ipc_ipc_perm},
+mantiene varie proprietà ed informazioni associate all'oggetto.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -849,25 +849,25 @@ mantiene varie propriet
 \end{figure}
 
 Usando la stessa chiave due processi diversi possono ricavare l'identificatore
-associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
+associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
 come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi
-sono \textsl{imparentati} la soluzione è relativamente semplice, in tal caso
-infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
-nuovo oggetto nel processo padre, l'identificatore così ottenuto sarà
-disponibile in tutti i figli, e potrà essere passato come argomento attraverso
+sono \textsl{imparentati} la soluzione è relativamente semplice, in tal caso
+infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
+nuovo oggetto nel processo padre, l'identificatore così ottenuto sarà
+disponibile in tutti i figli, e potrà essere passato come argomento attraverso
 una \func{exec}.
 
-Però quando i processi non sono \textsl{imparentati} (come capita tutte le
-volte che si ha a che fare con un sistema client-server) tutto questo non è
+Però quando i processi non sono \textsl{imparentati} (come capita tutte le
+volte che si ha a che fare con un sistema client-server) tutto questo non è
 possibile; si potrebbe comunque salvare l'identificatore su un file noto, ma
 questo ovviamente comporta lo svantaggio di doverselo andare a rileggere.  Una
-alternativa più efficace è quella che i programmi usino un valore comune per
-la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
-sempre il rischio che questa chiave possa essere stata già utilizzata da
+alternativa più efficace è quella che i programmi usino un valore comune per
+la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
+sempre il rischio che questa chiave possa essere stata già utilizzata da
 qualcun altro.  Dato che non esiste una convenzione su come assegnare queste
 chiavi in maniera univoca l'interfaccia mette a disposizione una funzione
 apposita, \funcd{ftok}, che permette di ottenere una chiave specificando il
-nome di un file ed un numero di versione; il suo prototipo è:
+nome di un file ed un numero di versione; il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/ipc.h} 
@@ -877,7 +877,7 @@ nome di un file ed un numero di versione; il suo prototipo 
   Restituisce una chiave per identificare un oggetto del \textit{SysV IPC}.
   
   \bodydesc{La funzione restituisce la chiave in caso di successo e -1
-    altrimenti, nel qual caso \var{errno} sarà uno dei possibili codici di
+    altrimenti, nel qual caso \var{errno} sarà uno dei possibili codici di
     errore di \func{stat}.}
 \end{functions}
 
@@ -886,36 +886,36 @@ che deve specificare il \itindex{pathname} \textit{pathname} di un file
 effettivamente esistente e di un numero di progetto \param{proj\_id)}, che di
 norma viene specificato come carattere, dato che ne vengono utilizzati solo
 gli 8 bit meno significativi.\footnote{nelle libc4 e libc5, come avviene in
-  SunOS, l'argomento \param{proj\_id} è dichiarato tipo \ctyp{char}, le
+  SunOS, l'argomento \param{proj\_id} è dichiarato tipo \ctyp{char}, le
   \acr{glibc} usano il prototipo specificato da XPG4, ma vengono lo stesso
   utilizzati gli 8 bit meno significativi.}
 
-Il problema è che anche così non c'è la sicurezza che il valore della chiave
-sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
+Il problema è che anche così non c'è la sicurezza che il valore della chiave
+sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
 con i 16 bit meno significativi \index{inode} dell'inode del file
 \param{pathname} (che vengono ottenuti attraverso \func{stat}, da cui derivano
 i possibili errori), e gli 8 bit meno significativi del numero del dispositivo
-su cui è il file.  Diventa perciò relativamente facile ottenere delle
+su cui è il file.  Diventa perciò relativamente facile ottenere delle
 collisioni, specie se i file sono su dispositivi con lo stesso
 \itindex{minor~number} \textit{minor number}, come \file{/dev/hda1} e
 \file{/dev/sda1}.
 
-In genere quello che si fa è utilizzare un file comune usato dai programmi che
+In genere quello che si fa è utilizzare un file comune usato dai programmi che
 devono comunicare (ad esempio un header comune, o uno dei programmi che devono
 usare l'oggetto in questione), utilizzando il numero di progetto per ottenere
 le chiavi che interessano. In ogni caso occorre sempre controllare, prima di
-creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
+creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
 bene in fase di creazione, le cose possono complicarsi per i programmi che
 devono solo accedere, in quanto, a parte gli eventuali controlli sugli altri
-attributi di \struct{ipc\_perm}, non esiste una modalità semplice per essere
+attributi di \struct{ipc\_perm}, non esiste una modalità semplice per essere
 sicuri che l'oggetto associato ad una certa chiave sia stato effettivamente
 creato da chi ci si aspetta.
 
-Questo è, insieme al fatto che gli oggetti sono permanenti e non mantengono un
+Questo è, insieme al fatto che gli oggetti sono permanenti e non mantengono un
 contatore di riferimenti per la cancellazione automatica, il principale
-problema del \textit{SysV IPC}. Non esiste infatti una modalità chiara per
+problema del \textit{SysV IPC}. Non esiste infatti una modalità chiara per
 identificare un oggetto, come sarebbe stato se lo si fosse associato ad in
-file, e tutta l'interfaccia è inutilmente complessa.  Per questo ne è stata
+file, e tutta l'interfaccia è inutilmente complessa.  Per questo ne è stata
 effettuata una revisione completa nello standard POSIX.1b, che tratteremo in
 sez.~\ref{sec:ipc_posix}.
 
@@ -927,21 +927,21 @@ Oltre alle chiavi, abbiamo visto che ad ogni oggetto sono associate in
 \struct{ipc\_perm} ulteriori informazioni, come gli identificatori del creatore
 (nei campi \var{cuid} e \var{cgid}) e del proprietario (nei campi \var{uid} e
 \var{gid}) dello stesso, e un insieme di permessi (nel campo \var{mode}). In
-questo modo è possibile definire un controllo di accesso sugli oggetti di IPC,
+questo modo è possibile definire un controllo di accesso sugli oggetti di IPC,
 simile a quello che si ha per i file (vedi sez.~\ref{sec:file_perm_overview}).
 
-Benché questo controllo di accesso sia molto simile a quello dei file, restano
-delle importanti differenze. La prima è che il permesso di esecuzione non
-esiste (e se specificato viene ignorato), per cui si può parlare solo di
-permessi di lettura e scrittura (nel caso dei semafori poi quest'ultimo è più
+Benché questo controllo di accesso sia molto simile a quello dei file, restano
+delle importanti differenze. La prima è che il permesso di esecuzione non
+esiste (e se specificato viene ignorato), per cui si può parlare solo di
+permessi di lettura e scrittura (nel caso dei semafori poi quest'ultimo è più
 propriamente un permesso di modifica). I valori di \var{mode} sono gli stessi
 ed hanno lo stesso significato di quelli riportati in
-tab.~\ref{tab:file_mode_flags}\footnote{se però si vogliono usare le costanti
-  simboliche ivi definite occorrerà includere il file \file{sys/stat.h},
+tab.~\ref{tab:file_mode_flags}\footnote{se però si vogliono usare le costanti
+  simboliche ivi definite occorrerà includere il file \file{sys/stat.h},
   alcuni sistemi definiscono le costanti \const{MSG\_R} (\texttt{0400}) e
   \const{MSG\_W} (\texttt{0200}) per indicare i permessi base di lettura e
   scrittura per il proprietario, da utilizzare, con gli opportuni shift, pure
-  per il gruppo e gli altri, in Linux, visto la loro scarsa utilità, queste
+  per il gruppo e gli altri, in Linux, visto la loro scarsa utilità, queste
   costanti non sono definite.} e come per i file definiscono gli accessi per
 il proprietario, il suo gruppo e tutti gli altri.
 
@@ -951,36 +951,36 @@ rispettivamente al valore dell'user-ID e del group-ID effettivo del processo
 che ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
 essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi.
 
-Il controllo di accesso è effettuato a due livelli. Il primo livello è nelle
+Il controllo di accesso è effettuato a due livelli. Il primo livello è nelle
 funzioni che richiedono l'identificatore di un oggetto data la chiave. Queste
 specificano tutte un argomento \param{flag}, in tal caso quando viene
 effettuata la ricerca di una chiave, qualora \param{flag} specifichi dei
 permessi, questi vengono controllati e l'identificatore viene restituito solo
 se corrispondono a quelli dell'oggetto. Se ci sono dei permessi non presenti
-in \var{mode} l'accesso sarà negato. Questo controllo però è di utilità
-indicativa, dato che è sempre possibile specificare per \param{flag} un valore
-nullo, nel qual caso l'identificatore sarà restituito comunque.
+in \var{mode} l'accesso sarà negato. Questo controllo però è di utilità
+indicativa, dato che è sempre possibile specificare per \param{flag} un valore
+nullo, nel qual caso l'identificatore sarà restituito comunque.
 
-Il secondo livello di controllo è quello delle varie funzioni che accedono
+Il secondo livello di controllo è quello delle varie funzioni che accedono
 direttamente (in lettura o scrittura) all'oggetto. In tal caso lo schema dei
-controlli è simile a quello dei file, ed avviene secondo questa sequenza:
+controlli è simile a quello dei file, ed avviene secondo questa sequenza:
 \begin{itemize*}
-\item se il processo ha i privilegi di amministratore l'accesso è sempre
+\item se il processo ha i privilegi di amministratore l'accesso è sempre
   consentito. 
 \item se l'user-ID effettivo del processo corrisponde o al valore del campo
   \var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
-  in \var{mode} è appropriato\footnote{per appropriato si intende che è
+  in \var{mode} è appropriato\footnote{per appropriato si intende che è
     impostato il permesso di scrittura per le operazioni di scrittura e quello
-    di lettura per le operazioni di lettura.} l'accesso è consentito.
+    di lettura per le operazioni di lettura.} l'accesso è consentito.
 \item se il group-ID effettivo del processo corrisponde o al
   valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
-  per il gruppo in \var{mode} è appropriato l'accesso è consentito.
-\item se il permesso per gli altri è appropriato l'accesso è consentito.
+  per il gruppo in \var{mode} è appropriato l'accesso è consentito.
+\item se il permesso per gli altri è appropriato l'accesso è consentito.
 \end{itemize*}
-solo se tutti i controlli elencati falliscono l'accesso è negato. Si noti che
+solo se tutti i controlli elencati falliscono l'accesso è negato. Si noti che
 a differenza di quanto avviene per i permessi dei file, fallire in uno dei
 passi elencati non comporta il fallimento dell'accesso. Un'ulteriore
-differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC
+differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC
 il valore di \itindex{umask} \textit{umask} (si ricordi quanto esposto in
 sez.~\ref{sec:file_perm_management}) non ha alcun significato.
 
@@ -988,10 +988,10 @@ sez.~\ref{sec:file_perm_management}) non ha alcun significato.
 \subsection{Gli identificatori ed il loro utilizzo}
 \label{sec:ipc_sysv_id_use}
 
-L'unico campo di \struct{ipc\_perm} del quale non abbiamo ancora parlato è
-\var{seq}, che in fig.~\ref{fig:ipc_ipc_perm} è qualificato con un criptico
-``\textsl{numero di sequenza}'', ne parliamo adesso dato che esso è
-strettamente attinente alle modalità con cui il kernel assegna gli
+L'unico campo di \struct{ipc\_perm} del quale non abbiamo ancora parlato è
+\var{seq}, che in fig.~\ref{fig:ipc_ipc_perm} è qualificato con un criptico
+``\textsl{numero di sequenza}'', ne parliamo adesso dato che esso è
+strettamente attinente alle modalità con cui il kernel assegna gli
 identificatori degli oggetti del sistema di IPC.
 
 Quando il sistema si avvia, alla creazione di ogni nuovo oggetto di IPC viene
@@ -1003,38 +1003,38 @@ dimensioni (inferiori al numero massimo di oggetti disponibili).
 
 Questo va benissimo nel caso dei file descriptor, che sono locali ad un
 processo, ma qui il comportamento varrebbe per tutto il sistema, e per
-processi del tutto scorrelati fra loro. Così si potrebbero avere situazioni
+processi del tutto scorrelati fra loro. Così si potrebbero avere situazioni
 come quella in cui un server esce e cancella le sue code di messaggi, ed il
 relativo identificatore viene immediatamente assegnato a quelle di un altro
-server partito subito dopo, con la possibilità che i client del primo non
+server partito subito dopo, con la possibilità che i client del primo non
 facciano in tempo ad accorgersi dell'avvenuto, e finiscano con l'interagire
 con gli oggetti del secondo, con conseguenze imprevedibili.
 
 Proprio per evitare questo tipo di situazioni il sistema usa il valore di
 \var{seq} per provvedere un meccanismo che porti gli identificatori ad
-assumere tutti i valori possibili, rendendo molto più lungo il periodo in cui
-un identificatore può venire riutilizzato.
+assumere tutti i valori possibili, rendendo molto più lungo il periodo in cui
+un identificatore può venire riutilizzato.
 
 Il sistema dispone sempre di un numero fisso di oggetti di IPC,\footnote{fino
   al kernel 2.2.x questi valori, definiti dalle costanti \const{MSGMNI},
   \const{SEMMNI} e \const{SHMMNI}, potevano essere cambiati (come tutti gli
   altri limiti relativi al \textit{SysV IPC}) solo con una ricompilazione del
   kernel, andando a modificarne la definizione nei relativi header file.  A
-  partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo
+  partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo
   scrivendo sui file \procrelfile{/proc/sys/kernel}{shmmni},
   \procrelfile{/proc/sys/kernel}{msgmni} e \procrelfile{/proc/sys/kernel}{sem}
   di \file{/proc/sys/kernel} o con l'uso di \func{sysctl}.} e per ciascuno di
 essi viene mantenuto in \var{seq} un numero di sequenza progressivo che viene
 incrementato di uno ogni volta che l'oggetto viene cancellato. Quando
-l'oggetto viene creato usando uno spazio che era già stato utilizzato in
+l'oggetto viene creato usando uno spazio che era già stato utilizzato in
 precedenza per restituire l'identificatore al numero di oggetti presenti viene
 sommato il valore di \var{seq} moltiplicato per il numero massimo di oggetti
 di quel tipo,\footnote{questo vale fino ai kernel della serie 2.2.x, dalla
-  serie 2.4.x viene usato lo stesso fattore per tutti gli oggetti, esso è dato
+  serie 2.4.x viene usato lo stesso fattore per tutti gli oggetti, esso è dato
   dalla costante \const{IPCMNI}, definita in \file{include/linux/ipc.h}, che
   indica il limite massimo per il numero di tutti oggetti di IPC, ed il cui
-  valore è 32768.}  si evita così il riutilizzo degli stessi numeri, e si fa
-sì che l'identificatore assuma tutti i valori possibili.
+  valore è 32768.}  si evita così il riutilizzo degli stessi numeri, e si fa
+sì che l'identificatore assuma tutti i valori possibili.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -1047,10 +1047,10 @@ s
   \label{fig:ipc_sysv_idtest}
 \end{figure}
 
-In fig.~\ref{fig:ipc_sysv_idtest} è riportato il codice di un semplice
+In fig.~\ref{fig:ipc_sysv_idtest} è riportato il codice di un semplice
 programma di test che si limita a creare un oggetto (specificato a riga di
 comando), stamparne il numero di identificatore e cancellarlo per un numero
-specificato di volte. Al solito non si è riportato il codice della gestione
+specificato di volte. Al solito non si è riportato il codice della gestione
 delle opzioni a riga di comando, che permette di specificare quante volte
 effettuare il ciclo \var{n}, e su quale tipo di oggetto eseguirlo.
 
@@ -1058,7 +1058,7 @@ La figura non riporta il codice di selezione delle opzioni, che permette di
 inizializzare i valori delle variabili \var{type} al tipo di oggetto voluto, e
 \var{n} al numero di volte che si vuole effettuare il ciclo di creazione,
 stampa, cancellazione. I valori di default sono per l'uso delle code di
-messaggi e un ciclo di 5 volte. Se si lancia il comando si otterrà qualcosa
+messaggi e un ciclo di 5 volte. Se si lancia il comando si otterrà qualcosa
 del tipo:
 \begin{Verbatim}
 piccardi@gont sources]$ ./ipctestid
@@ -1081,21 +1081,21 @@ Identifier Value 262144
 Identifier Value 294912 
 \end{Verbatim}
 %$
-che ci mostra come il valore di \var{seq} sia in effetti una quantità
+che ci mostra come il valore di \var{seq} sia in effetti una quantità
 mantenuta staticamente all'interno del sistema.
 
 
 \subsection{Code di messaggi}
 \label{sec:ipc_sysv_mq}
 
-Il primo oggetto introdotto dal \textit{SysV IPC} è quello delle code di
+Il primo oggetto introdotto dal \textit{SysV IPC} è quello delle code di
 messaggi.  Le code di messaggi sono oggetti analoghi alle pipe o alle fifo,
-anche se la loro struttura è diversa, ed il loro scopo principale è appunto
+anche se la loro struttura è diversa, ed il loro scopo principale è appunto
 quello di permettere a processi diversi di scambiarsi dei dati.
 
 La funzione che permette di richiedere al sistema l'identificatore di una coda
-di messaggi esistente (o di crearne una se questa non esiste) è
-\funcd{msgget}; il suo prototipo è:
+di messaggi esistente (o di crearne una se questa non esiste) è
+\funcd{msgget}; il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/ipc.h} 
@@ -1106,17 +1106,17 @@ di messaggi esistente (o di crearne una se questa non esiste) 
   Restituisce l'identificatore di una coda di messaggi.
   
   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
-    in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+    in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
   \item[\errcode{EACCES}] il processo chiamante non ha i privilegi per accedere
   alla coda richiesta.  
-  \item[\errcode{EEXIST}] si è richiesta la creazione di una coda che già
+  \item[\errcode{EEXIST}] si è richiesta la creazione di una coda che già
   esiste, ma erano specificati sia \const{IPC\_CREAT} che \const{IPC\_EXCL}. 
-  \item[\errcode{EIDRM}] la coda richiesta è marcata per essere cancellata.
-  \item[\errcode{ENOENT}] si è cercato di ottenere l'identificatore di una coda
+  \item[\errcode{EIDRM}] la coda richiesta è marcata per essere cancellata.
+  \item[\errcode{ENOENT}] si è cercato di ottenere l'identificatore di una coda
     di messaggi specificando una chiave che non esiste e \const{IPC\_CREAT}
     non era specificato.
-  \item[\errcode{ENOSPC}] si è cercato di creare una coda di messaggi quando è
+  \item[\errcode{ENOSPC}] si è cercato di creare una coda di messaggi quando è
     stato superato il limite massimo di code (\const{MSGMNI}).
   \end{errlist}
   ed inoltre \errval{ENOMEM}.
@@ -1125,27 +1125,27 @@ di messaggi esistente (o di crearne una se questa non esiste) 
 
 Le funzione (come le analoghe che si usano per gli altri oggetti) serve sia a
 ottenere l'identificatore di una coda di messaggi esistente, che a crearne una
-nuova. L'argomento \param{key} specifica la chiave che è associata
+nuova. L'argomento \param{key} specifica la chiave che è associata
 all'oggetto, eccetto il caso in cui si specifichi il valore
-\const{IPC\_PRIVATE}, nel qual caso la coda è creata ex-novo e non vi è
+\const{IPC\_PRIVATE}, nel qual caso la coda è creata ex-novo e non vi è
 associata alcuna chiave, il processo (ed i suoi eventuali figli) potranno
 farvi riferimento solo attraverso l'identificatore.
 
 Se invece si specifica un valore diverso da \const{IPC\_PRIVATE}\footnote{in
   Linux questo significa un valore diverso da zero.} l'effetto della funzione
-dipende dal valore di \param{flag}, se questo è nullo la funzione si limita ad
+dipende dal valore di \param{flag}, se questo è nullo la funzione si limita ad
 effettuare una ricerca sugli oggetti esistenti, restituendo l'identificatore
 se trova una corrispondenza, o fallendo con un errore di \errcode{ENOENT} se
 non esiste o di \errcode{EACCES} se si sono specificati dei permessi non
 validi.
 
-Se invece si vuole creare una nuova coda di messaggi \param{flag} non può
+Se invece si vuole creare una nuova coda di messaggi \param{flag} non può
 essere nullo e deve essere fornito come maschera binaria, impostando il bit
 corrispondente al valore \const{IPC\_CREAT}. In questo caso i nove bit meno
 significativi di \param{flag} saranno usati come permessi per il nuovo
 oggetto, secondo quanto illustrato in sez.~\ref{sec:ipc_sysv_access_control}.
-Se si imposta anche il bit corrispondente a \const{IPC\_EXCL} la funzione avrà
-successo solo se l'oggetto non esiste già, fallendo con un errore di
+Se si imposta anche il bit corrispondente a \const{IPC\_EXCL} la funzione avrà
+successo solo se l'oggetto non esiste già, fallendo con un errore di
 \errcode{EEXIST} altrimenti.
 
 Si tenga conto che l'uso di \const{IPC\_PRIVATE} non impedisce ad altri
@@ -1180,7 +1180,7 @@ coda.
 
 Le code di messaggi sono caratterizzate da tre limiti fondamentali, definiti
 negli header e corrispondenti alle prime tre costanti riportate in
-tab.~\ref{tab:ipc_msg_limits}, come accennato però in Linux è possibile
+tab.~\ref{tab:ipc_msg_limits}, come accennato però in Linux è possibile
 modificare questi limiti attraverso l'uso di \func{sysctl} o scrivendo nei
 file \procrelfile{/proc/sys/kernel}{msgmax},
 \procrelfile{/proc/sys/kernel}{msgmnb} e
@@ -1193,22 +1193,22 @@ file \procrelfile{/proc/sys/kernel}{msgmax},
 \end{figure}
 
 
-Una coda di messaggi è costituita da una \itindex{linked~list} \textit{linked
-  list};\footnote{una \itindex{linked~list} \textit{linked list} è una tipica
+Una coda di messaggi è costituita da una \itindex{linked~list} \textit{linked
+  list};\footnote{una \itindex{linked~list} \textit{linked list} è una tipica
   struttura di dati, organizzati in una lista in cui ciascun elemento contiene
-  un puntatore al successivo. In questo modo la struttura è veloce
-  nell'estrazione ed immissione dei dati dalle estremità dalla lista (basta
+  un puntatore al successivo. In questo modo la struttura è veloce
+  nell'estrazione ed immissione dei dati dalle estremità dalla lista (basta
   aggiungere un elemento in testa o in coda ed aggiornare un puntatore), e
   relativamente veloce da attraversare in ordine sequenziale (seguendo i
-  puntatori), è invece relativamente lenta nell'accesso casuale e nella
+  puntatori), è invece relativamente lenta nell'accesso casuale e nella
   ricerca.}  i nuovi messaggi vengono inseriti in coda alla lista e vengono
-letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si è riportato lo schema con
+letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si è riportato lo schema con
 cui queste strutture vengono mantenute dal kernel.\footnote{lo schema
-  illustrato in fig.~\ref{fig:ipc_mq_schema} è in realtà una semplificazione
+  illustrato in fig.~\ref{fig:ipc_mq_schema} è in realtà una semplificazione
   di quello usato effettivamente fino ai kernel della serie 2.2.x, nei kernel
-  della serie 2.4.x la gestione delle code di messaggi è stata modificata ed è
+  della serie 2.4.x la gestione delle code di messaggi è stata modificata ed è
   effettuata in maniera diversa; abbiamo mantenuto lo schema precedente in
-  quanto illustra comunque in maniera più che adeguata i principi di
+  quanto illustra comunque in maniera più che adeguata i principi di
   funzionamento delle code di messaggi.}
 
 \begin{figure}[!htb]
@@ -1222,12 +1222,12 @@ cui queste strutture vengono mantenute dal kernel.\footnote{lo schema
   \label{fig:ipc_msqid_ds}
 \end{figure}
 
-A ciascuna coda è associata una struttura \struct{msgid\_ds}, la cui
-definizione, è riportata in fig.~\ref{fig:ipc_msqid_ds}. In questa struttura il
+A ciascuna coda è associata una struttura \struct{msgid\_ds}, la cui
+definizione, è riportata in fig.~\ref{fig:ipc_msqid_ds}. In questa struttura il
 kernel mantiene le principali informazioni riguardo lo stato corrente della
 coda.\footnote{come accennato questo vale fino ai kernel della serie 2.2.x,
-  essa viene usata nei kernel della serie 2.4.x solo per compatibilità in
-  quanto è quella restituita dalle funzioni dell'interfaccia.  Si noti come ci
+  essa viene usata nei kernel della serie 2.4.x solo per compatibilità in
+  quanto è quella restituita dalle funzioni dell'interfaccia.  Si noti come ci
   sia una differenza con i campi mostrati nello schema di
   fig.~\ref{fig:ipc_mq_schema} che sono presi dalla definizione di
   \file{linux/msg.h}, e fanno riferimento alla definizione della omonima
@@ -1247,7 +1247,7 @@ gli altri campi invece:
   rispettivamente il \acr{pid} dell'ultimo processo che ha inviato o ricevuto
   un messaggio sulla coda, sono inizializzati a 0.
 \item i campi \var{msg\_stime} e \var{msg\_rtime}, che esprimono
-  rispettivamente il tempo in cui è stato inviato o ricevuto l'ultimo
+  rispettivamente il tempo in cui è stato inviato o ricevuto l'ultimo
   messaggio sulla coda, sono inizializzati a 0.
 \item il campo \var{msg\_ctime}, che esprime il tempo di creazione della coda,
   viene inizializzato al tempo corrente.
@@ -1256,15 +1256,15 @@ gli altri campi invece:
   del sistema (\const{MSGMNB}).
 \item i campi \var{msg\_first} e \var{msg\_last} che esprimono l'indirizzo del
   primo e ultimo messaggio sono inizializzati a \val{NULL} e
-  \var{msg\_cbytes}, che esprime la dimensione in byte dei messaggi presenti è
+  \var{msg\_cbytes}, che esprime la dimensione in byte dei messaggi presenti è
   inizializzato a zero. Questi campi sono ad uso interno dell'implementazione
   e non devono essere utilizzati da programmi in user space).
 \end{itemize*}
 
 Una volta creata una coda di messaggi le operazioni di controllo vengono
 effettuate con la funzione \funcd{msgctl}, che (come le analoghe \func{semctl}
-e \func{shmctl}) fa le veci di quello che \func{ioctl} è per i file; il suo
-prototipo è:
+e \func{shmctl}) fa le veci di quello che \func{ioctl} è per i file; il suo
+prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/ipc.h} 
@@ -1275,13 +1275,13 @@ prototipo 
   Esegue l'operazione specificata da \param{cmd} sulla coda \param{msqid}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo o $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma processo
+  \item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma processo
     chiamante non ha i privilegi di lettura sulla coda.
-  \item[\errcode{EIDRM}] la coda richiesta è stata cancellata.
-  \item[\errcode{EPERM}] si è richiesto \const{IPC\_SET} o \const{IPC\_RMID} ma
-    il processo non ha i privilegi, o si è richiesto di aumentare il valore di
+  \item[\errcode{EIDRM}] la coda richiesta è stata cancellata.
+  \item[\errcode{EPERM}] si è richiesto \const{IPC\_SET} o \const{IPC\_RMID} ma
+    il processo non ha i privilegi, o si è richiesto di aumentare il valore di
     \var{msg\_qbytes} oltre il limite \const{MSGMNB} senza essere
     amministratore.
   \end{errlist}
@@ -1302,7 +1302,7 @@ eseguire; i valori possibili sono:
   effetto immediato. Tutti i processi che cercheranno di accedere alla coda
   riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su
   funzioni di lettura o di scrittura sulla coda saranno svegliati ricevendo
-  il medesimo errore. Questo comando può essere eseguito solo da un processo
+  il medesimo errore. Questo comando può essere eseguito solo da un processo
   con user-ID effettivo corrispondente al creatore o al proprietario della
   coda, o all'amministratore.
 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
@@ -1311,14 +1311,14 @@ eseguire; i valori possibili sono:
   struttura \struct{msqid\_ds} puntata da \param{buf}.  Per modificare i valori
   di \var{msg\_perm.mode}, \var{msg\_perm.uid} e \var{msg\_perm.gid} occorre
   essere il proprietario o il creatore della coda, oppure l'amministratore; lo
-  stesso vale per \var{msg\_qbytes}, ma l'amministratore ha la facoltà di
+  stesso vale per \var{msg\_qbytes}, ma l'amministratore ha la facoltà di
   incrementarne il valore a limiti superiori a \const{MSGMNB}.
 \end{basedescript}
 
 
 Una volta che si abbia a disposizione l'identificatore, per inviare un
 messaggio su una coda si utilizza la funzione \funcd{msgsnd}; il suo prototipo
-è:
+è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/ipc.h} 
@@ -1330,14 +1330,14 @@ messaggio su una coda si utilizza la funzione \funcd{msgsnd}; il suo prototipo
   Invia un messaggio sulla coda \param{msqid}.
   
   \bodydesc{La funzione restituisce 0, e $-1$ in caso di errore, nel qual caso
-    \var{errno} assumerà uno dei valori:
+    \var{errno} assumerà uno dei valori:
   \begin{errlist}
   \item[\errcode{EACCES}] non si hanno i privilegi di accesso sulla coda.
-  \item[\errcode{EIDRM}] la coda è stata cancellata.
-  \item[\errcode{EAGAIN}] il messaggio non può essere inviato perché si è
+  \item[\errcode{EIDRM}] la coda è stata cancellata.
+  \item[\errcode{EAGAIN}] il messaggio non può essere inviato perché si è
   superato il limite \var{msg\_qbytes} sul numero massimo di byte presenti
-  sulla coda, e si è richiesto \const{IPC\_NOWAIT} in \param{flag}.
-  \item[\errcode{EINVAL}] si è specificato un \param{msgid} invalido, o un
+  sulla coda, e si è richiesto \const{IPC\_NOWAIT} in \param{flag}.
+  \item[\errcode{EINVAL}] si è specificato un \param{msgid} invalido, o un
     valore non positivo per \param{mtype}, o un valore di \param{msgsz}
     maggiore di \const{MSGMAX}.
   \end{errlist}
@@ -1345,35 +1345,35 @@ messaggio su una coda si utilizza la funzione \funcd{msgsnd}; il suo prototipo
 \end{functions}
 
 La funzione inserisce il messaggio sulla coda specificata da \param{msqid}; il
-messaggio ha lunghezza specificata da \param{msgsz} ed è passato attraverso il
+messaggio ha lunghezza specificata da \param{msgsz} ed è passato attraverso il
 l'argomento \param{msgp}.  Quest'ultimo deve venire passato sempre come
 puntatore ad una struttura \struct{msgbuf} analoga a quella riportata in
-fig.~\ref{fig:ipc_msbuf} che è quella che deve contenere effettivamente il
-messaggio.  La dimensione massima per il testo di un messaggio non può
+fig.~\ref{fig:ipc_msbuf} che è quella che deve contenere effettivamente il
+messaggio.  La dimensione massima per il testo di un messaggio non può
 comunque superare il limite \const{MSGMAX}.
 
-La struttura di fig.~\ref{fig:ipc_msbuf} è comunque solo un modello, tanto che
+La struttura di fig.~\ref{fig:ipc_msbuf} è comunque solo un modello, tanto che
 la definizione contenuta in \file{sys/msg.h} usa esplicitamente per il secondo
-campo il valore \code{mtext[1]}, che non è di nessuna utilità ai fini pratici.
-La sola cosa che conta è che la struttura abbia come primo membro un campo
+campo il valore \code{mtext[1]}, che non è di nessuna utilità ai fini pratici.
+La sola cosa che conta è che la struttura abbia come primo membro un campo
 \var{mtype} come nell'esempio; esso infatti serve ad identificare il tipo di
 messaggio e deve essere sempre specificato come intero positivo di tipo
-\ctyp{long}.  Il campo \var{mtext} invece può essere di qualsiasi tipo e
+\ctyp{long}.  Il campo \var{mtext} invece può essere di qualsiasi tipo e
 dimensione, e serve a contenere il testo del messaggio.
 
 In generale pertanto per inviare un messaggio con \func{msgsnd} si usa
 ridefinire una struttura simile a quella di fig.~\ref{fig:ipc_msbuf}, adattando
 alle proprie esigenze il campo \var{mtype}, (o ridefinendo come si vuole il
-corpo del messaggio, anche con più campi o con strutture più complesse) avendo
-però la cura di mantenere nel primo campo un valore di tipo \ctyp{long} che ne
+corpo del messaggio, anche con più campi o con strutture più complesse) avendo
+però la cura di mantenere nel primo campo un valore di tipo \ctyp{long} che ne
 indica il tipo.
 
 Si tenga presente che la lunghezza che deve essere indicata in questo
-argomento è solo quella del messaggio, non quella di tutta la struttura, se
-cioè \var{message} è una propria struttura che si passa alla funzione,
-\param{msgsz} dovrà essere uguale a \code{sizeof(message)-sizeof(long)}, (se
+argomento è solo quella del messaggio, non quella di tutta la struttura, se
+cioè \var{message} è una propria struttura che si passa alla funzione,
+\param{msgsz} dovrà essere uguale a \code{sizeof(message)-sizeof(long)}, (se
 consideriamo il caso dell'esempio in fig.~\ref{fig:ipc_msbuf}, \param{msgsz}
-dovrà essere pari a \const{LENGTH}).
+dovrà essere pari a \const{LENGTH}).
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -1389,11 +1389,11 @@ dovr
 Per capire meglio il funzionamento della funzione riprendiamo in
 considerazione la struttura della coda illustrata in
 fig.~\ref{fig:ipc_mq_schema}. Alla chiamata di \func{msgsnd} il nuovo messaggio
-sarà aggiunto in fondo alla lista inserendo una nuova struttura \struct{msg},
-il puntatore \var{msg\_last} di \struct{msqid\_ds} verrà aggiornato, come pure
+sarà aggiunto in fondo alla lista inserendo una nuova struttura \struct{msg},
+il puntatore \var{msg\_last} di \struct{msqid\_ds} verrà aggiornato, come pure
 il puntatore al messaggio successivo per quello che era il precedente ultimo
-messaggio; il valore di \var{mtype} verrà mantenuto in \var{msg\_type} ed il
-valore di \param{msgsz} in \var{msg\_ts}; il testo del messaggio sarà copiato
+messaggio; il valore di \var{mtype} verrà mantenuto in \var{msg\_type} ed il
+valore di \param{msgsz} in \var{msg\_ts}; il testo del messaggio sarà copiato
 all'indirizzo specificato da \var{msg\_spot}.
 
 Il valore dell'argomento \param{flag} permette di specificare il comportamento
@@ -1402,12 +1402,12 @@ ritorna immediatamente a meno che si sia ecceduto il valore di
 \var{msg\_qbytes}, o il limite di sistema sul numero di messaggi, nel qual
 caso si blocca mandando il processo in stato di \textit{sleep}.  Se si
 specifica per \param{flag} il valore \const{IPC\_NOWAIT} la funzione opera in
-modalità non bloccante, ed in questi casi ritorna immediatamente con un errore
+modalità non bloccante, ed in questi casi ritorna immediatamente con un errore
 di \errcode{EAGAIN}.
 
-Se non si specifica \const{IPC\_NOWAIT} la funzione resterà bloccata fintanto
+Se non si specifica \const{IPC\_NOWAIT} la funzione resterà bloccata fintanto
 che non si liberano risorse sufficienti per poter inserire nella coda il
-messaggio, nel qual caso ritornerà normalmente. La funzione può ritornare, con
+messaggio, nel qual caso ritornerà normalmente. La funzione può ritornare, con
 una condizione di errore anche in due altri casi: quando la coda viene rimossa
 (nel qual caso si ha un errore di \errcode{EIDRM}) o quando la funzione viene
 interrotta da un segnale (nel qual caso si ha un errore di \errcode{EINTR}).
@@ -1422,8 +1422,8 @@ vengono modificati:
 \item Il valore \var{msg\_stime}, che viene impostato al tempo corrente.
 \end{itemize*}
 
-La funzione che viene utilizzata per estrarre un messaggio da una coda è
-\funcd{msgrcv}; il suo prototipo è:
+La funzione che viene utilizzata per estrarre un messaggio da una coda è
+\funcd{msgrcv}; il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/ipc.h} 
@@ -1435,16 +1435,16 @@ La funzione che viene utilizzata per estrarre un messaggio da una coda 
   Legge un messaggio dalla coda \param{msqid}.
   
   \bodydesc{La funzione restituisce il numero di byte letti in caso di
-    successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà uno
+    successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà uno
     dei valori:
   \begin{errlist}
   \item[\errcode{EACCES}] non si hanno i privilegi di accesso sulla coda.
-  \item[\errcode{EIDRM}] la coda è stata cancellata.
-  \item[\errcode{E2BIG}] il testo del messaggio è più lungo di \param{msgsz} e
-    non si è specificato \const{MSG\_NOERROR} in \param{msgflg}.
-  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale mentre
+  \item[\errcode{EIDRM}] la coda è stata cancellata.
+  \item[\errcode{E2BIG}] il testo del messaggio è più lungo di \param{msgsz} e
+    non si è specificato \const{MSG\_NOERROR} in \param{msgflg}.
+  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale mentre
     era in attesa di ricevere un messaggio.
-  \item[\errcode{EINVAL}] si è specificato un \param{msgid} invalido o un
+  \item[\errcode{EINVAL}] si è specificato un \param{msgid} invalido o un
     valore di \param{msgsz} negativo.
   \end{errlist}
   ed inoltre \errval{EFAULT}.
@@ -1452,46 +1452,46 @@ La funzione che viene utilizzata per estrarre un messaggio da una coda 
 \end{functions}
 
 La funzione legge un messaggio dalla coda specificata, scrivendolo sulla
-struttura puntata da \param{msgp}, che dovrà avere un formato analogo a quello
-di fig.~\ref{fig:ipc_msbuf}.  Una volta estratto, il messaggio sarà rimosso
+struttura puntata da \param{msgp}, che dovrà avere un formato analogo a quello
+di fig.~\ref{fig:ipc_msbuf}.  Una volta estratto, il messaggio sarà rimosso
 dalla coda.  L'argomento \param{msgsz} indica la lunghezza massima del testo
 del messaggio (equivalente al valore del parametro \const{LENGTH} nell'esempio
 di fig.~\ref{fig:ipc_msbuf}).
 
 Se il testo del messaggio ha lunghezza inferiore a \param{msgsz} esso viene
-rimosso dalla coda; in caso contrario, se \param{msgflg} è impostato a
+rimosso dalla coda; in caso contrario, se \param{msgflg} è impostato a
 \const{MSG\_NOERROR}, il messaggio viene troncato e la parte in eccesso viene
 perduta, altrimenti il messaggio non viene estratto e la funzione ritorna con
 un errore di \errcode{E2BIG}.
 
 L'argomento \param{msgtyp} permette di restringere la ricerca ad un
-sottoinsieme dei messaggi presenti sulla coda; la ricerca infatti è fatta con
+sottoinsieme dei messaggi presenti sulla coda; la ricerca infatti è fatta con
 una scansione della struttura mostrata in fig.~\ref{fig:ipc_mq_schema},
 restituendo il primo messaggio incontrato che corrisponde ai criteri
 specificati (che quindi, visto come i messaggi vengono sempre inseriti dalla
-coda, è quello meno recente); in particolare:
+coda, è quello meno recente); in particolare:
 \begin{itemize}
-\item se \param{msgtyp} è 0 viene estratto il messaggio in cima alla coda, cioè
-  quello fra i presenti che è stato inserito per primo. 
-\item se \param{msgtyp} è positivo viene estratto il primo messaggio il cui
+\item se \param{msgtyp} è 0 viene estratto il messaggio in cima alla coda, cioè
+  quello fra i presenti che è stato inserito per primo. 
+\item se \param{msgtyp} è positivo viene estratto il primo messaggio il cui
   tipo (il valore del campo \var{mtype}) corrisponde al valore di
   \param{msgtyp}.
-\item se \param{msgtyp} è negativo viene estratto il primo fra i messaggi con
-  il valore più basso del tipo, fra tutti quelli il cui tipo ha un valore
+\item se \param{msgtyp} è negativo viene estratto il primo fra i messaggi con
+  il valore più basso del tipo, fra tutti quelli il cui tipo ha un valore
   inferiore al valore assoluto di \param{msgtyp}.
 \end{itemize}
 
 Il valore di \param{msgflg} permette di controllare il comportamento della
-funzione, esso può essere nullo o una maschera binaria composta da uno o più
+funzione, esso può essere nullo o una maschera binaria composta da uno o più
 valori.  Oltre al precedente \const{MSG\_NOERROR}, sono possibili altri due
-valori: \const{MSG\_EXCEPT}, che permette, quando \param{msgtyp} è positivo,
+valori: \const{MSG\_EXCEPT}, che permette, quando \param{msgtyp} è positivo,
 di leggere il primo messaggio nella coda con tipo diverso da \param{msgtyp}, e
 \const{IPC\_NOWAIT} che causa il ritorno immediato della funzione quando non
 ci sono messaggi sulla coda.
 
 Il comportamento usuale della funzione infatti, se non ci sono messaggi
-disponibili per la lettura, è di bloccare il processo in stato di
-\textit{sleep}. Nel caso però si sia specificato \const{IPC\_NOWAIT} la
+disponibili per la lettura, è di bloccare il processo in stato di
+\textit{sleep}. Nel caso però si sia specificato \const{IPC\_NOWAIT} la
 funzione ritorna immediatamente con un errore \errcode{ENOMSG}. Altrimenti la
 funzione ritorna normalmente non appena viene inserito un messaggio del tipo
 desiderato, oppure ritorna con errore qualora la coda sia rimossa (con
@@ -1510,19 +1510,19 @@ vengono modificati:
 
 Le code di messaggi presentano il solito problema di tutti gli oggetti del
 SysV IPC; essendo questi permanenti restano nel sistema occupando risorse
-anche quando un processo è terminato, al contrario delle pipe per le quali
+anche quando un processo è terminato, al contrario delle pipe per le quali
 tutte le risorse occupate vengono rilasciate quanto l'ultimo processo che le
-utilizzava termina. Questo comporta che in caso di errori si può saturare il
+utilizzava termina. Questo comporta che in caso di errori si può saturare il
 sistema, e che devono comunque essere esplicitamente previste delle funzioni
 di rimozione in caso di interruzioni o uscite dal programma (come vedremo in
 fig.~\ref{fig:ipc_mq_fortune_server}).
 
-L'altro problema è non facendo uso di file descriptor le tecniche di
+L'altro problema è non facendo uso di file descriptor le tecniche di
 \textit{I/O multiplexing} descritte in sez.~\ref{sec:file_multiplexing} non
 possono essere utilizzate, e non si ha a disposizione niente di analogo alle
-funzioni \func{select} e \func{poll}. Questo rende molto scomodo usare più di
-una di queste strutture alla volta; ad esempio non si può scrivere un server
-che aspetti un messaggio su più di una coda senza fare ricorso ad una tecnica
+funzioni \func{select} e \func{poll}. Questo rende molto scomodo usare più di
+una di queste strutture alla volta; ad esempio non si può scrivere un server
+che aspetti un messaggio su più di una coda senza fare ricorso ad una tecnica
 di \itindex{polling} \textit{polling} che esegua un ciclo di attesa su
 ciascuna di esse.
 
@@ -1542,13 +1542,13 @@ in maniera indipendente con client diversi.
   \label{fig:ipc_mq_fortune_server}
 \end{figure}
 
-In fig.~\ref{fig:ipc_mq_fortune_server} si è riportato un estratto delle parti
-principali del codice del nuovo server (il codice completo è nel file
-\file{MQFortuneServer.c} nei sorgenti allegati). Il programma è basato su un
+In fig.~\ref{fig:ipc_mq_fortune_server} si è riportato un estratto delle parti
+principali del codice del nuovo server (il codice completo è nel file
+\file{MQFortuneServer.c} nei sorgenti allegati). Il programma è basato su un
 uso accorto della caratteristica di poter associate un ``tipo'' ai messaggi
 per permettere una comunicazione indipendente fra il server ed i vari client,
-usando il \acr{pid} di questi ultimi come identificativo. Questo è possibile
-in quanto, al contrario di una fifo, la lettura di una coda di messaggi può
+usando il \acr{pid} di questi ultimi come identificativo. Questo è possibile
+in quanto, al contrario di una fifo, la lettura di una coda di messaggi può
 non essere sequenziale, proprio grazie alla classificazione dei messaggi sulla
 base del loro tipo.
 
@@ -1558,12 +1558,12 @@ definisce due strutture appositamente per la comunicazione; con
 \var{msgbuf\_read} (\texttt{\small 8--11}) vengono passate le richieste mentre
 con \var{msgbuf\_write} (\texttt{\small 12--15}) vengono restituite le frasi.
 
-La gestione delle opzioni si è al solito omessa, essa si curerà di impostare
+La gestione delle opzioni si è al solito omessa, essa si curerà di impostare
 in \var{n} il numero di frasi da leggere specificato a linea di comando ed in
 \var{fortunefilename} il file da cui leggerle; dopo aver installato
 (\texttt{\small 19--21}) i gestori dei segnali per trattare l'uscita dal
 server, viene prima controllato (\texttt{\small 22}) il numero di frasi
-richieste abbia senso (cioè sia maggiore di zero), le quali poi
+richieste abbia senso (cioè sia maggiore di zero), le quali poi
 (\texttt{\small 23}) vengono lette nel vettore in memoria con la stessa
 funzione \code{FortuneParse} usata anche per il server basato sulle fifo.
 
@@ -1580,13 +1580,13 @@ la funzione \func{daemon} per andare in background e poi esegue in permanenza
 il ciclo principale (\texttt{\small 33--40}). Questo inizia (\texttt{\small
   34}) con il porsi in attesa di un messaggio di richiesta da parte di un
 client; si noti infatti come \func{msgrcv} richieda un messaggio con
-\var{mtype} uguale a 1: questo è il valore usato per le richieste dato che
-corrisponde al \acr{pid} di \cmd{init}, che non può essere un client. L'uso
-del flag \const{MSG\_NOERROR} è solo per sicurezza, dato che i messaggi di
+\var{mtype} uguale a 1: questo è il valore usato per le richieste dato che
+corrisponde al \acr{pid} di \cmd{init}, che non può essere un client. L'uso
+del flag \const{MSG\_NOERROR} è solo per sicurezza, dato che i messaggi di
 richiesta sono di dimensione fissa (e contengono solo il \acr{pid} del
 client).
 
-Se non sono presenti messaggi di richiesta \func{msgrcv} si bloccherà,
+Se non sono presenti messaggi di richiesta \func{msgrcv} si bloccherà,
 ritornando soltanto in corrispondenza dell'arrivo sulla coda di un messaggio
 di richiesta da parte di un client, in tal caso il ciclo prosegue
 (\texttt{\small 35}) selezionando una frase a caso, copiandola (\texttt{\small
@@ -1596,12 +1596,12 @@ calcolandone (\texttt{\small 37}) la dimensione.
 Per poter permettere a ciascun client di ricevere solo la risposta indirizzata
 a lui il tipo del messaggio in uscita viene inizializzato (\texttt{\small 38})
 al valore del \acr{pid} del client ricevuto nel messaggio di richiesta.
-L'ultimo passo del ciclo (\texttt{\small 39}) è inviare sulla coda il
-messaggio di risposta. Si tenga conto che se la coda è piena anche questa
-funzione potrà bloccarsi fintanto che non venga liberato dello spazio.
+L'ultimo passo del ciclo (\texttt{\small 39}) è inviare sulla coda il
+messaggio di risposta. Si tenga conto che se la coda è piena anche questa
+funzione potrà bloccarsi fintanto che non venga liberato dello spazio.
 
-Si noti che il programma può terminare solo grazie ad una interruzione da
-parte di un segnale; in tal caso verrà eseguito (\texttt{\small 45--48}) il
+Si noti che il programma può terminare solo grazie ad una interruzione da
+parte di un segnale; in tal caso verrà eseguito (\texttt{\small 45--48}) il
 gestore \code{HandSIGTERM}, che semplicemente si limita a cancellare la coda
 (\texttt{\small 46}) ed ad uscire (\texttt{\small 47}).
 
@@ -1616,19 +1616,19 @@ gestore \code{HandSIGTERM}, che semplicemente si limita a cancellare la coda
   \label{fig:ipc_mq_fortune_client}
 \end{figure}
 
-In fig.~\ref{fig:ipc_mq_fortune_client} si è riportato un estratto il codice
-del programma client.  Al solito il codice completo è con i sorgenti allegati,
+In fig.~\ref{fig:ipc_mq_fortune_client} si è riportato un estratto il codice
+del programma client.  Al solito il codice completo è con i sorgenti allegati,
 nel file \file{MQFortuneClient.c}.  Come sempre si sono rimosse le parti
 relative alla gestione delle opzioni, ed in questo caso, anche la
 dichiarazione delle variabili, che, per la parte relative alle strutture usate
 per la comunicazione tramite le code, sono le stesse viste in
 fig.~\ref{fig:ipc_mq_fortune_server}.
 
-Il client in questo caso è molto semplice; la prima parte del programma
-(\texttt{\small 4--9}) si occupa di accedere alla coda di messaggi, ed è
+Il client in questo caso è molto semplice; la prima parte del programma
+(\texttt{\small 4--9}) si occupa di accedere alla coda di messaggi, ed è
 identica a quanto visto per il server, solo che in questo caso \func{msgget}
 non viene chiamata con il flag di creazione in quanto la coda deve essere
-preesistente. In caso di errore (ad esempio se il server non è stato avviato)
+preesistente. In caso di errore (ad esempio se il server non è stato avviato)
 il programma termina immediatamente. 
 
 Una volta acquisito l'identificatore della coda il client compone il
@@ -1640,7 +1640,7 @@ immettere la richiesta sulla coda.
 A questo punto non resta che (\texttt{\small 16}) rileggere dalla coda la
 risposta del server richiedendo a \func{msgrcv} di selezionare i messaggi di
 tipo corrispondente al valore del \acr{pid} inviato nella richiesta. L'ultimo
-passo (\texttt{\small 17}) prima di uscire è quello di stampare a video il
+passo (\texttt{\small 17}) prima di uscire è quello di stampare a video il
 messaggio ricevuto.
  
 Proviamo allora il nostro nuovo sistema, al solito occorre definire
@@ -1651,8 +1651,8 @@ fifo, potremo far partire il server con:
 [piccardi@gont sources]$ ./mqfortuned -n10
 \end{verbatim}%$
 come nel caso precedente, avendo eseguito il server in background, il comando
-ritornerà immediatamente; potremo però verificare con \cmd{ps} che il
-programma è effettivamente in esecuzione, e che ha creato una coda di
+ritornerà immediatamente; potremo però verificare con \cmd{ps} che il
+programma è effettivamente in esecuzione, e che ha creato una coda di
 messaggi:
 \begin{verbatim}
 [piccardi@gont sources]$ ipcs
@@ -1671,7 +1671,7 @@ a questo punto potremo usare il client per ottenere le nostre frasi:
 \begin{verbatim}
 [piccardi@gont sources]$ ./mqfortune
 Linux ext2fs has been stable for a long time, now it's time to break it
-        -- Linuxkongreß '95 in Berlin
+        -- Linuxkongreß '95 in Berlin
 [piccardi@gont sources]$ ./mqfortune
 Let's call it an accidental feature.
         --Larry Wall
@@ -1680,14 +1680,14 @@ con un risultato del tutto equivalente al precedente. Infine potremo chiudere
 il server inviando il segnale di terminazione con il comando \code{killall
   mqfortuned} verificando che effettivamente la coda di messaggi viene rimossa.
 
-Benché funzionante questa architettura risente dello stesso inconveniente
+Benché funzionante questa architettura risente dello stesso inconveniente
 visto anche nel caso del precedente server basato sulle fifo; se il client
 viene interrotto dopo l'invio del messaggio di richiesta e prima della lettura
-della risposta, quest'ultima resta nella coda (così come per le fifo si aveva
-il problema delle fifo che restavano nel filesystem). In questo caso però il
-problemi sono maggiori, sia perché è molto più facile esaurire la memoria
+della risposta, quest'ultima resta nella coda (così come per le fifo si aveva
+il problema delle fifo che restavano nel filesystem). In questo caso però il
+problemi sono maggiori, sia perché è molto più facile esaurire la memoria
 dedicata ad una coda di messaggi che gli \index{inode} inode di un filesystem,
-sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client
+sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client
 eseguito in un momento successivo potrebbe ricevere un messaggio non
 indirizzato a lui.
 
@@ -1702,43 +1702,43 @@ dati fra processi, ma servono piuttosto come meccanismi di sincronizzazione o
 di protezione per le \index{sezione~critica} \textsl{sezioni critiche} del
 codice (si ricordi quanto detto in sez.~\ref{sec:proc_race_cond}).
 
-Un semaforo è uno speciale contatore, mantenuto nel kernel, che permette, a
+Un semaforo è uno speciale contatore, mantenuto nel kernel, che permette, a
 seconda del suo valore, di consentire o meno la prosecuzione dell'esecuzione
-di un programma. In questo modo l'accesso ad una risorsa condivisa da più
-processi può essere controllato, associando ad essa un semaforo che consente
-di assicurare che non più di un processo alla volta possa usarla.
-
-Il concetto di semaforo è uno dei concetti base nella programmazione ed è
-assolutamente generico, così come del tutto generali sono modalità con cui lo
-si utilizza. Un processo che deve accedere ad una risorsa eseguirà un
-controllo del semaforo: se questo è positivo il suo valore sarà decrementato,
-indicando che si è consumato una unità della risorsa, ed il processo potrà
+di un programma. In questo modo l'accesso ad una risorsa condivisa da più
+processi può essere controllato, associando ad essa un semaforo che consente
+di assicurare che non più di un processo alla volta possa usarla.
+
+Il concetto di semaforo è uno dei concetti base nella programmazione ed è
+assolutamente generico, così come del tutto generali sono modalità con cui lo
+si utilizza. Un processo che deve accedere ad una risorsa eseguirà un
+controllo del semaforo: se questo è positivo il suo valore sarà decrementato,
+indicando che si è consumato una unità della risorsa, ed il processo potrà
 proseguire nell'utilizzo di quest'ultima, provvedendo a rilasciarla, una volta
 completate le operazioni volute, reincrementando il semaforo.
 
-Se al momento del controllo il valore del semaforo è nullo, siamo invece in
-una situazione in cui la risorsa non è disponibile, ed il processo si
-bloccherà in stato di \textit{sleep} fin quando chi la sta utilizzando non la
-rilascerà, incrementando il valore del semaforo. Non appena il semaforo torna
-positivo, indicando che la risorsa è disponibile, il processo sarà svegliato,
-e si potrà operare come nel caso precedente (decremento del semaforo, accesso
+Se al momento del controllo il valore del semaforo è nullo, siamo invece in
+una situazione in cui la risorsa non è disponibile, ed il processo si
+bloccherà in stato di \textit{sleep} fin quando chi la sta utilizzando non la
+rilascerà, incrementando il valore del semaforo. Non appena il semaforo torna
+positivo, indicando che la risorsa è disponibile, il processo sarà svegliato,
+e si potrà operare come nel caso precedente (decremento del semaforo, accesso
 alla risorsa, incremento del semaforo).
 
 Per poter implementare questo tipo di logica le operazioni di controllo e
 decremento del contatore associato al semaforo devono essere atomiche,
-pertanto una realizzazione di un oggetto di questo tipo è necessariamente
-demandata al kernel. La forma più semplice di semaforo è quella del
+pertanto una realizzazione di un oggetto di questo tipo è necessariamente
+demandata al kernel. La forma più semplice di semaforo è quella del
 \textsl{semaforo binario}, o \textit{mutex}, in cui un valore diverso da zero
-(normalmente 1) indica la libertà di accesso, e un valore nullo l'occupazione
-della risorsa. In generale però si possono usare semafori con valori interi,
+(normalmente 1) indica la libertà di accesso, e un valore nullo l'occupazione
+della risorsa. In generale però si possono usare semafori con valori interi,
 utilizzando il valore del contatore come indicatore del ``numero di risorse''
 ancora disponibili.
 
 Il sistema di comunicazione inter-processo di \textit{SysV IPC} prevede anche i
 semafori, ma gli oggetti utilizzati non sono semafori singoli, ma gruppi di
 semafori detti \textsl{insiemi} (o \textit{semaphore set}); la funzione che
-permette di creare o ottenere l'identificatore di un insieme di semafori è
-\funcd{semget}, ed il suo prototipo è:
+permette di creare o ottenere l'identificatore di un insieme di semafori è
+\funcd{semget}, ed il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/ipc.h} 
@@ -1749,15 +1749,15 @@ permette di creare o ottenere l'identificatore di un insieme di semafori 
   Restituisce l'identificatore di un insieme di semafori.
   
   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
-    in caso di errore, nel qual caso \var{errno} assumerà i valori:
+    in caso di errore, nel qual caso \var{errno} assumerà i valori:
     \begin{errlist}
-    \item[\errcode{ENOSPC}] si è cercato di creare una insieme di semafori
-      quando è stato superato o il limite per il numero totale di semafori
+    \item[\errcode{ENOSPC}] si è cercato di creare una insieme di semafori
+      quando è stato superato o il limite per il numero totale di semafori
       (\const{SEMMNS}) o quello per il numero totale degli insiemi
       (\const{SEMMNI}) nel sistema.
-    \item[\errcode{EINVAL}] l'argomento \param{nsems} è minore di zero o
+    \item[\errcode{EINVAL}] l'argomento \param{nsems} è minore di zero o
       maggiore del limite sul numero di semafori per ciascun insieme
-      (\const{SEMMSL}), o se l'insieme già esiste, maggiore del numero di
+      (\const{SEMMSL}), o se l'insieme già esiste, maggiore del numero di
       semafori che contiene.
     \item[\errcode{ENOMEM}] il sistema non ha abbastanza memoria per poter
       contenere le strutture per un nuovo insieme di semafori.
@@ -1766,31 +1766,31 @@ permette di creare o ottenere l'identificatore di un insieme di semafori 
     \errval{EIDRM}, con lo stesso significato che hanno per \func{msgget}.}
 \end{functions}
 
-La funzione è del tutto analoga a \func{msgget}, solo che in questo caso
-restituisce l'identificatore di un insieme di semafori, in particolare è
+La funzione è del tutto analoga a \func{msgget}, solo che in questo caso
+restituisce l'identificatore di un insieme di semafori, in particolare è
 identico l'uso degli argomenti \param{key} e \param{flag}, per cui non
 ripeteremo quanto detto al proposito in sez.~\ref{sec:ipc_sysv_mq}. L'argomento
 \param{nsems} permette di specificare quanti semafori deve contenere l'insieme
 quando se ne richieda la creazione, e deve essere nullo quando si effettua una
-richiesta dell'identificatore di un insieme già esistente.
+richiesta dell'identificatore di un insieme già esistente.
 
 Purtroppo questa implementazione complica inutilmente lo schema elementare che
-abbiamo descritto, dato che non è possibile definire un singolo semaforo, ma
-se ne deve creare per forza un insieme.  Ma questa in definitiva è solo una
-complicazione inutile, il problema è che i semafori del \textit{SysV IPC}
-soffrono di altri due, ben più gravi, difetti.
+abbiamo descritto, dato che non è possibile definire un singolo semaforo, ma
+se ne deve creare per forza un insieme.  Ma questa in definitiva è solo una
+complicazione inutile, il problema è che i semafori del \textit{SysV IPC}
+soffrono di altri due, ben più gravi, difetti.
 
-Il primo difetto è che non esiste una funzione che permetta di creare ed
+Il primo difetto è che non esiste una funzione che permetta di creare ed
 inizializzare un semaforo in un'unica chiamata; occorre prima creare l'insieme
 dei semafori con \func{semget} e poi inizializzarlo con \func{semctl}, si
-perde così ogni possibilità di eseguire l'operazione atomicamente.
+perde così ogni possibilità di eseguire l'operazione atomicamente.
 
 Il secondo difetto deriva dalla caratteristica generale degli oggetti del
 \textit{SysV IPC} di essere risorse globali di sistema, che non vengono
-cancellate quando nessuno le usa più; ci si così a trova a dover affrontare
+cancellate quando nessuno le usa più; ci si così a trova a dover affrontare
 esplicitamente il caso in cui un processo termina per un qualche errore,
-lasciando un semaforo occupato, che resterà tale fino al successivo riavvio
-del sistema. Come vedremo esistono delle modalità per evitare tutto ciò, ma
+lasciando un semaforo occupato, che resterà tale fino al successivo riavvio
+del sistema. Come vedremo esistono delle modalità per evitare tutto ciò, ma
 diventa necessario indicare esplicitamente che si vuole il ripristino del
 semaforo all'uscita del processo.
 
@@ -1805,7 +1805,7 @@ semaforo all'uscita del processo.
   \label{fig:ipc_semid_ds}
 \end{figure}
 
-A ciascun insieme di semafori è associata una struttura \struct{semid\_ds},
+A ciascun insieme di semafori è associata una struttura \struct{semid\_ds},
 riportata in fig.~\ref{fig:ipc_semid_ds}.\footnote{non si sono riportati i
   campi ad uso interno del kernel, che vedremo in
   fig.~\ref{fig:ipc_sem_schema}, che dipendono dall'implementazione.} Come nel
@@ -1813,7 +1813,7 @@ caso delle code di messaggi quando si crea un nuovo insieme di semafori con
 \func{semget} questa struttura viene inizializzata, in particolare il campo
 \var{sem\_perm} viene inizializzato come illustrato in
 sez.~\ref{sec:ipc_sysv_access_control} (si ricordi che in questo caso il
-permesso di scrittura è in realtà permesso di alterare il semaforo), per
+permesso di scrittura è in realtà permesso di alterare il semaforo), per
 quanto riguarda gli altri campi invece:
 \begin{itemize*}
 \item il campo \var{sem\_nsems}, che esprime il numero di semafori
@@ -1824,15 +1824,15 @@ quanto riguarda gli altri campi invece:
   effettuata, viene inizializzato a zero.
 \end{itemize*}
 
-Ciascun semaforo dell'insieme è realizzato come una struttura di tipo
+Ciascun semaforo dell'insieme è realizzato come una struttura di tipo
 \struct{sem} che ne contiene i dati essenziali, la sua definizione\footnote{si
-  è riportata la definizione originaria del kernel 1.0, che contiene la prima
-  realizzazione del \textit{SysV IPC} in Linux. In realtà questa struttura
-  ormai è ridotta ai soli due primi membri, e gli altri vengono calcolati
-  dinamicamente. La si è utilizzata a scopo di esempio, perché indica tutti i
+  è riportata la definizione originaria del kernel 1.0, che contiene la prima
+  realizzazione del \textit{SysV IPC} in Linux. In realtà questa struttura
+  ormai è ridotta ai soli due primi membri, e gli altri vengono calcolati
+  dinamicamente. La si è utilizzata a scopo di esempio, perché indica tutti i
   valori associati ad un semaforo, restituiti dalle funzioni di controllo, e
-  citati dalle pagine di manuale.} è riportata in fig.~\ref{fig:ipc_sem}.
-Questa struttura, non è accessibile in user space, ma i valori in essa
+  citati dalle pagine di manuale.} è riportata in fig.~\ref{fig:ipc_sem}.
+Questa struttura, non è accessibile in user space, ma i valori in essa
 specificati possono essere letti in maniera indiretta, attraverso l'uso delle
 funzioni di controllo.
 
@@ -1891,8 +1891,8 @@ al solito accessibili e modificabili attraverso \func{sysctl} o scrivendo
 direttamente nel file \procfile{/proc/sys/kernel/sem}.
 
 La funzione che permette di effettuare le varie operazioni di controllo sui
-semafori (fra le quali, come accennato, è impropriamente compresa anche la
-loro inizializzazione) è \funcd{semctl}; il suo prototipo è:
+semafori (fra le quali, come accennato, è impropriamente compresa anche la
+loro inizializzazione) è \funcd{semctl}; il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/ipc.h} 
@@ -1905,23 +1905,23 @@ loro inizializzazione) 
   
   \bodydesc{La funzione restituisce in caso di successo un valore positivo
     quanto usata con tre argomenti ed un valore nullo quando usata con
-    quattro. In caso di errore restituisce -1, ed \var{errno} assumerà uno dei
+    quattro. In caso di errore restituisce -1, ed \var{errno} assumerà uno dei
     valori:
     \begin{errlist}
     \item[\errcode{EACCES}] il processo non ha i privilegi per eseguire
       l'operazione richiesta.
-    \item[\errcode{EIDRM}] l'insieme di semafori è stato cancellato.
-    \item[\errcode{EPERM}] si è richiesto \const{IPC\_SET} o \const{IPC\_RMID}
+    \item[\errcode{EIDRM}] l'insieme di semafori è stato cancellato.
+    \item[\errcode{EPERM}] si è richiesto \const{IPC\_SET} o \const{IPC\_RMID}
       ma il processo non ha privilegi sufficienti ad eseguire l'operazione.
-    \item[\errcode{ERANGE}] si è richiesto \const{SETALL} \const{SETVAL} ma il
-      valore a cui si vuole impostare il semaforo è minore di zero o maggiore
+    \item[\errcode{ERANGE}] si è richiesto \const{SETALL} \const{SETVAL} ma il
+      valore a cui si vuole impostare il semaforo è minore di zero o maggiore
       di \const{SEMVMX}.
   \end{errlist}
   ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
 }
 \end{functions}
 
-La funzione può avere tre o quattro argomenti, a seconda dell'operazione
+La funzione può avere tre o quattro argomenti, a seconda dell'operazione
 specificata con \param{cmd}, ed opera o sull'intero insieme specificato da
 \param{semid} o sul singolo semaforo di un insieme, specificato da
 \param{semnum}. 
@@ -1938,16 +1938,16 @@ specificata con \param{cmd}, ed opera o sull'intero insieme specificato da
   \label{fig:ipc_semun}
 \end{figure}
 
-Qualora la funzione operi con quattro argomenti \param{arg} è un argomento
-generico, che conterrà un dato diverso a seconda dell'azione richiesta; per
+Qualora la funzione operi con quattro argomenti \param{arg} è un argomento
+generico, che conterrà un dato diverso a seconda dell'azione richiesta; per
 unificare l'argomento esso deve essere passato come una \struct{semun}, la cui
-definizione, con i possibili valori che può assumere, è riportata in
+definizione, con i possibili valori che può assumere, è riportata in
 fig.~\ref{fig:ipc_semun}.
 
-Come già accennato sia il comportamento della funzione che il numero di
+Come già accennato sia il comportamento della funzione che il numero di
 argomenti con cui deve essere invocata dipendono dal valore dell'argomento
 \param{cmd}, che specifica l'azione da intraprendere; i valori validi (che
-cioè non causano un errore di \errcode{EINVAL}) per questo argomento sono i
+cioè non causano un errore di \errcode{EINVAL}) per questo argomento sono i
 seguenti:
 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
 \item[\const{IPC\_STAT}] Legge i dati dell'insieme di semafori, copiando il
@@ -2026,14 +2026,14 @@ tutti i semafori il cui valore viene modificato.
 
 Il valore di ritorno della funzione in caso di successo dipende
 dall'operazione richiesta; per tutte le operazioni che richiedono quattro
-argomenti esso è sempre nullo, per le altre operazioni, elencate in
+argomenti esso è sempre nullo, per le altre operazioni, elencate in
 tab.~\ref{tab:ipc_semctl_returns} viene invece restituito il valore richiesto,
 corrispondente al campo della struttura \struct{sem} indicato nella seconda
 colonna della tabella.
 
 Le operazioni ordinarie sui semafori, come l'acquisizione o il rilascio degli
 stessi (in sostanza tutte quelle non comprese nell'uso di \func{semctl})
-vengono effettuate con la funzione \funcd{semop}, il cui prototipo è:
+vengono effettuate con la funzione \funcd{semop}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/ipc.h} 
@@ -2044,18 +2044,18 @@ vengono effettuate con la funzione \funcd{semop}, il cui prototipo 
   Esegue le operazioni ordinarie su un semaforo o un insieme di semafori.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
     \item[\errcode{EACCES}] il processo non ha i privilegi per eseguire
       l'operazione richiesta.
-    \item[\errcode{EIDRM}] l'insieme di semafori è stato cancellato.
-    \item[\errcode{ENOMEM}] si è richiesto un \const{SEM\_UNDO} ma il sistema
+    \item[\errcode{EIDRM}] l'insieme di semafori è stato cancellato.
+    \item[\errcode{ENOMEM}] si è richiesto un \const{SEM\_UNDO} ma il sistema
       non ha le risorse per allocare la struttura di ripristino.
     \item[\errcode{EAGAIN}] un'operazione comporterebbe il blocco del processo,
-      ma si è specificato \const{IPC\_NOWAIT} in \var{sem\_flg}.
+      ma si è specificato \const{IPC\_NOWAIT} in \var{sem\_flg}.
     \item[\errcode{EINTR}] la funzione, bloccata in attesa dell'esecuzione
       dell'operazione, viene interrotta da un segnale.
-    \item[\errcode{E2BIG}] l'argomento \param{nsops} è maggiore del numero
+    \item[\errcode{E2BIG}] l'argomento \param{nsops} è maggiore del numero
       massimo di operazioni \const{SEMOPM}.
     \item[\errcode{ERANGE}] per alcune operazioni il valore risultante del
       semaforo viene a superare il limite massimo \const{SEMVMX}.
@@ -2070,7 +2070,7 @@ un insieme. La funzione richiede come primo argomento l'identificatore
 effettuare viene specificato con l'argomento \param{nsop}, mentre il loro
 contenuto viene passato con un puntatore ad un vettore di strutture
 \struct{sembuf} nell'argomento \param{sops}. Le operazioni richieste vengono
-effettivamente eseguite se e soltanto se è possibile effettuarle tutte quante.
+effettivamente eseguite se e soltanto se è possibile effettuarle tutte quante.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -2084,7 +2084,7 @@ effettivamente eseguite se e soltanto se 
 \end{figure}
 
 Il contenuto di ciascuna operazione deve essere specificato attraverso una
-opportuna struttura \struct{sembuf} (la cui definizione è riportata in
+opportuna struttura \struct{sembuf} (la cui definizione è riportata in
 fig.~\ref{fig:ipc_sembuf}) che il programma chiamante deve avere cura di
 allocare in un opportuno vettore. La struttura permette di indicare il
 semaforo su cui operare, il tipo di operazione, ed un flag di controllo.
@@ -2093,7 +2093,7 @@ riferimento l'operazione; si ricordi che i semafori sono numerati come in un
 vettore, per cui il primo semaforo corrisponde ad un valore nullo di
 \var{sem\_num}.
 
-Il campo \var{sem\_flg} è un flag, mantenuto come maschera binaria, per il
+Il campo \var{sem\_flg} è un flag, mantenuto come maschera binaria, per il
 quale possono essere impostati i due valori \const{IPC\_NOWAIT} e
 \const{SEM\_UNDO}.  Impostando \const{IPC\_NOWAIT} si fa si che, invece di
 bloccarsi (in tutti quei casi in cui l'esecuzione di una operazione richiede
@@ -2102,7 +2102,7 @@ immediatamente con un errore di \errcode{EAGAIN}.  Impostando \const{SEM\_UNDO}
 si richiede invece che l'operazione venga registrata in modo che il valore del
 semaforo possa essere ripristinato all'uscita del processo.
 
-Infine \var{sem\_op} è il campo che controlla l'operazione che viene eseguita
+Infine \var{sem\_op} è il campo che controlla l'operazione che viene eseguita
 e determina il comportamento della chiamata a \func{semop}; tre sono i casi
 possibili:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
@@ -2111,12 +2111,12 @@ possibili:
   immediatamente (con un errore di \errcode{ERANGE} qualora si sia superato il
   limite \const{SEMVMX}) ed il processo non viene bloccato in nessun caso.
   Specificando \const{SEM\_UNDO} si aggiorna il contatore per il ripristino
-  del valore del semaforo. Al processo chiamante è richiesto il privilegio di
+  del valore del semaforo. Al processo chiamante è richiesto il privilegio di
   alterazione (scrittura) sull'insieme di semafori.
   
 \item[\var{sem\_op}$=0$] Nel caso \var{semval} sia zero l'esecuzione procede
-  immediatamente. Se \var{semval} è diverso da zero il comportamento è
-  controllato da \var{sem\_flg}, se è stato impostato \const{IPC\_NOWAIT} la
+  immediatamente. Se \var{semval} è diverso da zero il comportamento è
+  controllato da \var{sem\_flg}, se è stato impostato \const{IPC\_NOWAIT} la
   funzione ritorna con un errore di \errcode{EAGAIN}, altrimenti viene
   incrementato \var{semzcnt} di uno ed il processo resta in stato di
   \textit{sleep} fintanto che non si ha una delle condizioni seguenti:
@@ -2129,16 +2129,16 @@ possibili:
     viene decrementato di uno e \func{semop} ritorna un errore di
     \errcode{EINTR}.
   \end{itemize*}
-  Al processo chiamante è richiesto il privilegio di lettura dell'insieme dei
+  Al processo chiamante è richiesto il privilegio di lettura dell'insieme dei
   semafori.
   
-\item[\var{sem\_op}$<0$] Nel caso in cui \var{semval} è maggiore o uguale del
-  valore assoluto di \var{sem\_op} (se cioè la somma dei due valori resta
+\item[\var{sem\_op}$<0$] Nel caso in cui \var{semval} è maggiore o uguale del
+  valore assoluto di \var{sem\_op} (se cioè la somma dei due valori resta
   positiva o nulla) i valori vengono sommati e la funzione ritorna
   immediatamente; qualora si sia impostato \const{SEM\_UNDO} viene anche
   aggiornato il contatore per il ripristino del valore del semaforo. In caso
-  contrario (quando cioè la somma darebbe luogo ad un valore di \var{semval}
-  negativo) se si è impostato \const{IPC\_NOWAIT} la funzione ritorna con un
+  contrario (quando cioè la somma darebbe luogo ad un valore di \var{semval}
+  negativo) se si è impostato \const{IPC\_NOWAIT} la funzione ritorna con un
   errore di \errcode{EAGAIN}, altrimenti viene incrementato di uno
   \var{semncnt} ed il processo resta in stato di \textit{sleep} fintanto che
   non si ha una delle condizioni seguenti:
@@ -2154,7 +2154,7 @@ possibili:
     viene decrementato di uno e \func{semop} ritorna un errore di
     \errcode{EINTR}.
   \end{itemize*}    
-  Al processo chiamante è richiesto il privilegio di alterazione (scrittura)
+  Al processo chiamante è richiesto il privilegio di alterazione (scrittura)
   sull'insieme di semafori.
 \end{basedescript}
 
@@ -2163,10 +2163,10 @@ ogni semaforo modificato al valore del \acr{pid} del processo chiamante;
 inoltre vengono pure aggiornati al tempo corrente i campi \var{sem\_otime} e
 \var{sem\_ctime}.
 
-Dato che, come già accennato in precedenza, in caso di uscita inaspettata i
+Dato che, come già accennato in precedenza, in caso di uscita inaspettata i
 semafori possono restare occupati, abbiamo visto come \func{semop} permetta di
 attivare un meccanismo di ripristino attraverso l'uso del flag
-\const{SEM\_UNDO}. Il meccanismo è implementato tramite una apposita struttura
+\const{SEM\_UNDO}. Il meccanismo è implementato tramite una apposita struttura
 \struct{sem\_undo}, associata ad ogni processo per ciascun semaforo che esso
 ha modificato; all'uscita i semafori modificati vengono ripristinati, e le
 strutture disallocate.  Per mantenere coerente il comportamento queste
@@ -2174,13 +2174,13 @@ strutture non vengono ereditate attraverso una \func{fork} (altrimenti si
 avrebbe un doppio ripristino), mentre passano inalterate nell'esecuzione di
 una \func{exec} (altrimenti non si avrebbe ripristino).
 
-Tutto questo però ha un problema di fondo. Per capire di cosa si tratta
-occorre fare riferimento all'implementazione usata in Linux, che è riportata
-in maniera semplificata nello schema di fig.~\ref{fig:ipc_sem_schema}.  Si è
-presa come riferimento l'architettura usata fino al kernel 2.2.x che è più
+Tutto questo però ha un problema di fondo. Per capire di cosa si tratta
+occorre fare riferimento all'implementazione usata in Linux, che è riportata
+in maniera semplificata nello schema di fig.~\ref{fig:ipc_sem_schema}.  Si è
+presa come riferimento l'architettura usata fino al kernel 2.2.x che è più
 semplice (ed illustrata in dettaglio in \cite{tlk}); nel kernel 2.4.x la
-struttura del \textit{SysV IPC} è stata modificata, ma le definizioni relative
-a queste strutture restano per compatibilità.\footnote{in particolare con le
+struttura del \textit{SysV IPC} è stata modificata, ma le definizioni relative
+a queste strutture restano per compatibilità.\footnote{in particolare con le
   vecchie versioni delle librerie del C, come le libc5.}
 
 \begin{figure}[htb]
@@ -2199,7 +2199,7 @@ coda di attesa associata a ciascun insieme di semafori\footnote{che viene
   di \struct{semid\_ds}.}. 
 
 Nella struttura viene memorizzato il riferimento alle operazioni richieste
-(nel campo \var{sops}, che è un puntatore ad una struttura \struct{sembuf}) e
+(nel campo \var{sops}, che è un puntatore ad una struttura \struct{sembuf}) e
 al processo corrente (nel campo \var{sleeper}) poi quest'ultimo viene messo
 stato di attesa e viene invocato lo \itindex{scheduler} scheduler per passare
 all'esecuzione di un altro processo.
@@ -2207,12 +2207,12 @@ all'esecuzione di un altro processo.
 Se invece tutte le operazioni possono avere successo queste vengono eseguite
 immediatamente, dopo di che il kernel esegue una scansione della coda di
 attesa (a partire da \var{sem\_pending}) per verificare se qualcuna delle
-operazioni sospese in precedenza può essere eseguita, nel qual caso la
+operazioni sospese in precedenza può essere eseguita, nel qual caso la
 struttura \struct{sem\_queue} viene rimossa e lo stato del processo associato
 all'operazione (\var{sleeper}) viene riportato a \textit{running}; il tutto
-viene ripetuto fin quando non ci sono più operazioni eseguibili o si è
+viene ripetuto fin quando non ci sono più operazioni eseguibili o si è
 svuotata la coda.  Per gestire il meccanismo del ripristino tutte le volte che
-per un'operazione si è specificato il flag \const{SEM\_UNDO} viene mantenuta
+per un'operazione si è specificato il flag \const{SEM\_UNDO} viene mantenuta
 per ciascun insieme di semafori una apposita struttura \struct{sem\_undo} che
 contiene (nel vettore puntato dal campo \var{semadj}) un valore di
 aggiustamento per ogni semaforo cui viene sommato l'opposto del valore usato
@@ -2221,34 +2221,34 @@ per l'operazione.
 Queste strutture sono mantenute in due liste,\footnote{rispettivamente
   attraverso i due campi \var{id\_next} e \var{proc\_next}.} una associata
 all'insieme di cui fa parte il semaforo, che viene usata per invalidare le
-strutture se questo viene cancellato o per azzerarle se si è eseguita una
+strutture se questo viene cancellato o per azzerarle se si è eseguita una
 operazione con \func{semctl}; l'altra associata al processo che ha eseguito
 l'operazione;\footnote{attraverso il campo \var{semundo} di
   \struct{task\_struct}, come mostrato in \ref{fig:ipc_sem_schema}.} quando un
 processo termina, la lista ad esso associata viene scandita e le operazioni
-applicate al semaforo.  Siccome un processo può accumulare delle richieste di
+applicate al semaforo.  Siccome un processo può accumulare delle richieste di
 ripristino per semafori differenti chiamate attraverso diverse chiamate a
 \func{semop}, si pone il problema di come eseguire il ripristino dei semafori
-all'uscita del processo, ed in particolare se questo può essere fatto
+all'uscita del processo, ed in particolare se questo può essere fatto
 atomicamente.
 
-Il punto è cosa succede quando una delle operazioni previste per il ripristino
-non può essere eseguita immediatamente perché ad esempio il semaforo è
+Il punto è cosa succede quando una delle operazioni previste per il ripristino
+non può essere eseguita immediatamente perché ad esempio il semaforo è
 occupato; in tal caso infatti, se si pone il processo in stato di
-\textit{sleep} aspettando la disponibilità del semaforo (come faceva
-l'implementazione originaria) si perde l'atomicità dell'operazione. La scelta
-fatta dal kernel è pertanto quella di effettuare subito le operazioni che non
+\textit{sleep} aspettando la disponibilità del semaforo (come faceva
+l'implementazione originaria) si perde l'atomicità dell'operazione. La scelta
+fatta dal kernel è pertanto quella di effettuare subito le operazioni che non
 prevedono un blocco del processo e di ignorare silenziosamente le altre;
-questo però comporta il fatto che il ripristino non è comunque garantito in
+questo però comporta il fatto che il ripristino non è comunque garantito in
 tutte le occasioni.
 
 Come esempio di uso dell'interfaccia dei semafori vediamo come implementare
-con essa dei semplici \textit{mutex} (cioè semafori binari), tutto il codice
-in questione, contenuto nel file \file{Mutex.c} allegato ai sorgenti, è
+con essa dei semplici \textit{mutex} (cioè semafori binari), tutto il codice
+in questione, contenuto nel file \file{Mutex.c} allegato ai sorgenti, è
 riportato in fig.~\ref{fig:ipc_mutex_create}. Utilizzeremo l'interfaccia per
 creare un insieme contenente un singolo semaforo, per il quale poi useremo un
-valore unitario per segnalare la disponibilità della risorsa, ed un valore
-nullo per segnalarne l'indisponibilità. 
+valore unitario per segnalare la disponibilità della risorsa, ed un valore
+nullo per segnalarne l'indisponibilità. 
 
 \begin{figure}[!bht]
   \footnotesize \centering
@@ -2261,33 +2261,33 @@ nullo per segnalarne l'indisponibilit
   \label{fig:ipc_mutex_create}
 \end{figure}
 
-La prima funzione (\texttt{\small 2--15}) è \func{MutexCreate} che data una
+La prima funzione (\texttt{\small 2--15}) è \func{MutexCreate} che data una
 chiave crea il semaforo usato per il mutex e lo inizializza, restituendone
-l'identificatore. Il primo passo (\texttt{\small 6}) è chiamare \func{semget}
+l'identificatore. Il primo passo (\texttt{\small 6}) è chiamare \func{semget}
 con \const{IPC\_CREATE} per creare il semaforo qualora non esista,
 assegnandogli i privilegi di lettura e scrittura per tutti. In caso di errore
 (\texttt{\small 7--9}) si ritorna subito il risultato di \func{semget},
 altrimenti (\texttt{\small 10}) si inizializza il semaforo chiamando
 \func{semctl} con il comando \const{SETVAL}, utilizzando l'unione
 \struct{semunion} dichiarata ed avvalorata in precedenza (\texttt{\small 4})
-ad 1 per significare che risorsa è libera. In caso di errore (\texttt{\small
+ad 1 per significare che risorsa è libera. In caso di errore (\texttt{\small
   11--13}) si restituisce il valore di ritorno di \func{semctl}, altrimenti
 (\texttt{\small 14}) si ritorna l'identificatore del semaforo.
 
-La seconda funzione (\texttt{\small 17--20}) è \func{MutexFind}, che, data una
+La seconda funzione (\texttt{\small 17--20}) è \func{MutexFind}, che, data una
 chiave, restituisce l'identificatore del semaforo ad essa associato. La
-comprensione del suo funzionamento è immediata in quanto essa è soltanto un
-\textit{wrapper}\footnote{si chiama così una funzione usata per fare da
+comprensione del suo funzionamento è immediata in quanto essa è soltanto un
+\textit{wrapper}\footnote{si chiama così una funzione usata per fare da
   \textsl{involucro} alla chiamata di un altra, usata in genere per
   semplificare un'interfaccia (come in questo caso) o per utilizzare con la
   stessa funzione diversi substrati (librerie, ecc.)  che possono fornire le
-  stesse funzionalità.} di una chiamata a \func{semget} per cercare
+  stesse funzionalità.} di una chiamata a \func{semget} per cercare
 l'identificatore associato alla chiave, il valore di ritorno di quest'ultima
 viene passato all'indietro al chiamante.
 
-La terza funzione (\texttt{\small 22--25}) è \func{MutexRead} che, dato un
+La terza funzione (\texttt{\small 22--25}) è \func{MutexRead} che, dato un
 identificatore, restituisce il valore del semaforo associato al mutex. Anche
-in questo caso la funzione è un \textit{wrapper} per una chiamata a
+in questo caso la funzione è un \textit{wrapper} per una chiamata a
 \func{semctl} con il comando \const{GETVAL}, che permette di restituire il
 valore del semaforo.
 
@@ -2299,21 +2299,21 @@ strutture \var{sem\_lock} e \var{sem\_unlock} definite in precedenza
 dell'opzione \const{SEM\_UNDO} per evitare che il semaforo resti bloccato in
 caso di terminazione imprevista del processo.
 
-L'ultima funzione (\texttt{\small 46--49}) della serie, è \func{MutexRemove},
+L'ultima funzione (\texttt{\small 46--49}) della serie, è \func{MutexRemove},
 che rimuove il mutex. Anche in questo caso si ha un wrapper per una chiamata a
 \func{semctl} con il comando \const{IPC\_RMID}, che permette di cancellare il
 semaforo; il valore di ritorno di quest'ultima viene passato all'indietro.
 
-Chiamare \func{MutexLock} decrementa il valore del semaforo: se questo è
-libero (ha già valore 1) sarà bloccato (valore nullo), se è bloccato la
-chiamata a \func{semop} si bloccherà fintanto che la risorsa non venga
-rilasciata. Chiamando \func{MutexUnlock} il valore del semaforo sarà
+Chiamare \func{MutexLock} decrementa il valore del semaforo: se questo è
+libero (ha già valore 1) sarà bloccato (valore nullo), se è bloccato la
+chiamata a \func{semop} si bloccherà fintanto che la risorsa non venga
+rilasciata. Chiamando \func{MutexUnlock} il valore del semaforo sarà
 incrementato di uno, sbloccandolo qualora fosse bloccato.  
 
 Si noti che occorre eseguire sempre prima \func{MutexLock} e poi
-\func{MutexUnlock}, perché se per un qualche errore si esegue più volte
+\func{MutexUnlock}, perché se per un qualche errore si esegue più volte
 quest'ultima il valore del semaforo crescerebbe oltre 1, e \func{MutexLock}
-non avrebbe più l'effetto aspettato (bloccare la risorsa quando questa è
+non avrebbe più l'effetto aspettato (bloccare la risorsa quando questa è
 considerata libera).  Infine si tenga presente che usare \func{MutexRead} per
 controllare il valore dei mutex prima di proseguire in una operazione di
 sblocco non servirebbe comunque, dato che l'operazione non sarebbe atomica.
@@ -2325,9 +2325,9 @@ problemi, usando il \index{file!locking} \textit{file locking}.
 \subsection{Memoria condivisa}
 \label{sec:ipc_sysv_shm}
 
-Il terzo oggetto introdotto dal \textit{SysV IPC} è quello dei segmenti di
-memoria condivisa. La funzione che permette di ottenerne uno è \funcd{shmget},
-ed il suo prototipo è:
+Il terzo oggetto introdotto dal \textit{SysV IPC} è quello dei segmenti di
+memoria condivisa. La funzione che permette di ottenerne uno è \funcd{shmget},
+ed il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/ipc.h} 
@@ -2338,15 +2338,15 @@ ed il suo prototipo 
   Restituisce l'identificatore di una memoria condivisa.
   
   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
-    in caso di errore, nel qual caso \var{errno} assumerà i valori:
+    in caso di errore, nel qual caso \var{errno} assumerà i valori:
     \begin{errlist}
-    \item[\errcode{ENOSPC}] si è superato il limite (\const{SHMMNI}) sul numero
+    \item[\errcode{ENOSPC}] si è superato il limite (\const{SHMMNI}) sul numero
       di segmenti di memoria nel sistema, o cercato di allocare un segmento le
       cui dimensioni fanno superare il limite di sistema (\const{SHMALL}) per
       la memoria ad essi riservata.
-    \item[\errcode{EINVAL}] si è richiesta una dimensione per un nuovo segmento
+    \item[\errcode{EINVAL}] si è richiesta una dimensione per un nuovo segmento
       maggiore di \const{SHMMAX} o minore di \const{SHMMIN}, o se il segmento
-      già esiste \param{size} è maggiore delle sue dimensioni.
+      già esiste \param{size} è maggiore delle sue dimensioni.
     \item[\errcode{ENOMEM}] il sistema non ha abbastanza memoria per poter
       contenere le strutture per un nuovo segmento di memoria condivisa.
     \end{errlist}
@@ -2354,21 +2354,21 @@ ed il suo prototipo 
     \errval{EIDRM}, con lo stesso significato che hanno per \func{msgget}.}
 \end{functions}
 
-La funzione, come \func{semget}, è del tutto analoga a \func{msgget}, ed
-identico è l'uso degli argomenti \param{key} e \param{flag} per cui non
+La funzione, come \func{semget}, è del tutto analoga a \func{msgget}, ed
+identico è l'uso degli argomenti \param{key} e \param{flag} per cui non
 ripeteremo quanto detto al proposito in sez.~\ref{sec:ipc_sysv_mq}. L'argomento
 \param{size} specifica invece la dimensione, in byte, del segmento, che viene
 comunque arrotondata al multiplo superiore di \const{PAGE\_SIZE}.
 
-La memoria condivisa è la forma più veloce di comunicazione fra due processi,
+La memoria condivisa è la forma più veloce di comunicazione fra due processi,
 in quanto permette agli stessi di vedere nel loro spazio di indirizzi una
-stessa sezione di memoria.  Pertanto non è necessaria nessuna operazione di
-copia per trasmettere i dati da un processo all'altro, in quanto ciascuno può
+stessa sezione di memoria.  Pertanto non è necessaria nessuna operazione di
+copia per trasmettere i dati da un processo all'altro, in quanto ciascuno può
 accedervi direttamente con le normali operazioni di lettura e scrittura dei
 dati in memoria.
 
 Ovviamente tutto questo ha un prezzo, ed il problema fondamentale della
-memoria condivisa è la sincronizzazione degli accessi. È evidente infatti che
+memoria condivisa è la sincronizzazione degli accessi. È evidente infatti che
 se un processo deve scambiare dei dati con un altro, si deve essere sicuri che
 quest'ultimo non acceda al segmento di memoria condivisa prima che il primo
 non abbia completato le operazioni di scrittura, inoltre nel corso di una
@@ -2389,7 +2389,7 @@ norma, significa insieme a dei semafori.
   \label{fig:ipc_shmid_ds}
 \end{figure}
 
-A ciascun segmento di memoria condivisa è associata una struttura
+A ciascun segmento di memoria condivisa è associata una struttura
 \struct{shmid\_ds}, riportata in fig.~\ref{fig:ipc_shmid_ds}.  Come nel caso
 delle code di messaggi quando si crea un nuovo segmento di memoria condivisa
 con \func{shmget} questa struttura viene inizializzata, in particolare il
@@ -2403,7 +2403,7 @@ invece:
 \item il campo \var{shm\_ctime}, che esprime il tempo di creazione del
   segmento, viene inizializzato al tempo corrente.
 \item i campi \var{shm\_atime} e \var{shm\_dtime}, che esprimono
-  rispettivamente il tempo dell'ultima volta che il segmento è stato
+  rispettivamente il tempo dell'ultima volta che il segmento è stato
   agganciato o sganciato da un processo, vengono inizializzati a zero.
 \item il campo \var{shm\_lpid}, che esprime il \acr{pid} del processo che ha
   eseguito l'ultima operazione, viene inizializzato a zero.
@@ -2464,7 +2464,7 @@ che permettono di cambiarne il valore.
 \end{table}
 
 Al solito la funzione che permette di effettuare le operazioni di controllo su
-un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è:
+un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è:
 \begin{functions}
   \headdecl{sys/ipc.h} 
   \headdecl{sys/shm.h}
@@ -2474,27 +2474,27 @@ un segmento di memoria condivisa 
   Esegue le operazioni di controllo su un segmento di memoria condivisa.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
     \begin{errlist}
-    \item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma i permessi non
+    \item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma i permessi non
       consentono l'accesso in lettura al segmento.
-    \item[\errcode{EINVAL}] o \param{shmid} non è un identificatore valido o
-      \param{cmd} non è un comando valido.
+    \item[\errcode{EINVAL}] o \param{shmid} non è un identificatore valido o
+      \param{cmd} non è un comando valido.
     \item[\errcode{EIDRM}] l'argomento \param{shmid} fa riferimento ad un
-      segmento che è stato cancellato.
-    \item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o
+      segmento che è stato cancellato.
+    \item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o
       \const{IPC\_RMID} senza i permessi necessari.
-    \item[\errcode{EOVERFLOW}] si è tentato il comando \const{IPC\_STAT} ma il
-      valore del group-ID o dell'user-ID è troppo grande per essere
+    \item[\errcode{EOVERFLOW}] si è tentato il comando \const{IPC\_STAT} ma il
+      valore del group-ID o dell'user-ID è troppo grande per essere
       memorizzato nella struttura puntata da \param{buf}.
-    \item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è
+    \item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è
       valido.
     \end{errlist}
 }
 \end{functions}
 
 Il comando specificato attraverso l'argomento \param{cmd} determina i diversi
-effetti della funzione; i possibili valori che esso può assumere, ed il
+effetti della funzione; i possibili valori che esso può assumere, ed il
 corrispondente comportamento della funzione, sono i seguenti:
 
 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
@@ -2502,8 +2502,8 @@ corrispondente comportamento della funzione, sono i seguenti:
   condivisa nella struttura \struct{shmid\_ds} puntata da \param{buf}. Occorre
   che il processo chiamante abbia il permesso di lettura sulla segmento.
 \item[\const{IPC\_RMID}] Marca il segmento di memoria condivisa per la
-  rimozione, questo verrà cancellato effettivamente solo quando l'ultimo
-  processo ad esso agganciato si sarà staccato. Questo comando può essere
+  rimozione, questo verrà cancellato effettivamente solo quando l'ultimo
+  processo ad esso agganciato si sarà staccato. Questo comando può essere
   eseguito solo da un processo con user-ID effettivo corrispondente o al
   creatore del segmento, o al proprietario del segmento, o all'amministratore.
 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
@@ -2512,31 +2512,31 @@ corrispondente comportamento della funzione, sono i seguenti:
   il creatore del segmento, oppure l'amministratore. Compiuta l'operazione
   aggiorna anche il valore del campo \var{shm\_ctime}.
 \item[\const{SHM\_LOCK}] Abilita il \itindex{memory~locking} \textit{memory
-    locking}\footnote{impedisce cioè che la memoria usata per il segmento
+    locking}\footnote{impedisce cioè che la memoria usata per il segmento
     venga salvata su disco dal meccanismo della \index{memoria~virtuale}
     memoria virtuale; si ricordi quanto trattato in
     sez.~\ref{sec:proc_mem_lock}.} sul segmento di memoria condivisa. Solo
-  l'amministratore può utilizzare questo comando.
+  l'amministratore può utilizzare questo comando.
 \item[\const{SHM\_UNLOCK}] Disabilita il \itindex{memory~locking}
   \textit{memory locking} sul segmento di memoria condivisa.  Solo
-  l'amministratore può utilizzare questo comando.
+  l'amministratore può utilizzare questo comando.
 \end{basedescript}
-i primi tre comandi sono gli stessi già visti anche per le code di messaggi e
+i primi tre comandi sono gli stessi già visti anche per le code di messaggi e
 gli insiemi di semafori, gli ultimi due sono delle estensioni specifiche
 previste da Linux, che permettono di abilitare e disabilitare il meccanismo
 della \index{memoria~virtuale} memoria virtuale per il segmento.
 
 L'argomento \param{buf} viene utilizzato solo con i comandi \const{IPC\_STAT}
-e \const{IPC\_SET} nel qual caso esso dovrà puntare ad una struttura
+e \const{IPC\_SET} nel qual caso esso dovrà puntare ad una struttura
 \struct{shmid\_ds} precedentemente allocata, in cui nel primo caso saranno
 scritti i dati del segmento di memoria restituiti dalla funzione e da cui, nel
 secondo caso, verranno letti i dati da impostare sul segmento.
 
-Una volta che lo si è creato, per utilizzare un segmento di memoria condivisa
+Una volta che lo si è creato, per utilizzare un segmento di memoria condivisa
 l'interfaccia prevede due funzioni, \funcd{shmat} e \func{shmdt}. La prima di
 queste serve ad agganciare un segmento al processo chiamante, in modo che
 quest'ultimo possa inserirlo nel suo spazio di indirizzi per potervi accedere;
-il suo prototipo è:
+il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/shm.h}
@@ -2545,12 +2545,12 @@ il suo prototipo 
   Aggancia al processo un segmento di memoria condivisa.
   
   \bodydesc{La funzione restituisce l'indirizzo del segmento in caso di
-    successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
+    successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
     valori:
     \begin{errlist}
     \item[\errcode{EACCES}] il processo non ha i privilegi per accedere al
-      segmento nella modalità richiesta.
-    \item[\errcode{EINVAL}] si è specificato un identificatore invalido per
+      segmento nella modalità richiesta.
+    \item[\errcode{EINVAL}] si è specificato un identificatore invalido per
       \param{shmid}, o un indirizzo non allineato sul confine di una pagina
       per \param{shmaddr}.
     \end{errlist}
@@ -2559,37 +2559,37 @@ il suo prototipo 
 
 La funzione inserisce un segmento di memoria condivisa all'interno dello
 spazio di indirizzi del processo, in modo che questo possa accedervi
-direttamente, la situazione dopo l'esecuzione di \func{shmat} è illustrata in
+direttamente, la situazione dopo l'esecuzione di \func{shmat} è illustrata in
 fig.~\ref{fig:ipc_shmem_layout} (per la comprensione del resto dello schema si
 ricordi quanto illustrato al proposito in sez.~\ref{sec:proc_mem_layout}). In
 particolare l'indirizzo finale del segmento dati (quello impostato da
 \func{brk}, vedi sez.~\ref{sec:proc_mem_alloc}) non viene influenzato.
-Si tenga presente infine che la funzione ha successo anche se il segmento è
+Si tenga presente infine che la funzione ha successo anche se il segmento è
 stato marcato per la cancellazione.
 
 \begin{figure}[htb]
   \centering
   \includegraphics[height=10cm]{img/sh_memory_layout}
-  \caption{Disposizione dei segmenti di memoria di un processo quando si è
+  \caption{Disposizione dei segmenti di memoria di un processo quando si è
     agganciato un segmento di memoria condivisa.}
   \label{fig:ipc_shmem_layout}
 \end{figure}
 
 L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{lo standard
-  SVID prevede che l'argomento \param{shmaddr} sia di tipo \ctyp{char *}, così
-  come il valore di ritorno della funzione; in Linux è stato così con le
+  SVID prevede che l'argomento \param{shmaddr} sia di tipo \ctyp{char *}, così
+  come il valore di ritorno della funzione; in Linux è stato così con le
   \acr{libc4} e le \acr{libc5}, con il passaggio alle \acr{glibc} il tipo di
-  \param{shmaddr} è divenuto un \ctyp{const void *} e quello del valore di
+  \param{shmaddr} è divenuto un \ctyp{const void *} e quello del valore di
   ritorno un \ctyp{void *}.} deve essere associato il segmento, se il valore
-specificato è \val{NULL} è il sistema a scegliere opportunamente un'area di
-memoria libera (questo è il modo più portabile e sicuro di usare la funzione).
+specificato è \val{NULL} è il sistema a scegliere opportunamente un'area di
+memoria libera (questo è il modo più portabile e sicuro di usare la funzione).
 Altrimenti il kernel aggancia il segmento all'indirizzo specificato da
-\param{shmaddr}; questo però può avvenire solo se l'indirizzo coincide con il
-limite di una pagina, cioè se è un multiplo esatto del parametro di sistema
-\const{SHMLBA}, che in Linux è sempre uguale \const{PAGE\_SIZE}. 
+\param{shmaddr}; questo però può avvenire solo se l'indirizzo coincide con il
+limite di una pagina, cioè se è un multiplo esatto del parametro di sistema
+\const{SHMLBA}, che in Linux è sempre uguale \const{PAGE\_SIZE}. 
 
-Si tenga presente però che quando si usa \val{NULL} come valore di
-\param{shmaddr}, l'indirizzo restituito da \func{shmat} può cambiare da
+Si tenga presente però che quando si usa \val{NULL} come valore di
+\param{shmaddr}, l'indirizzo restituito da \func{shmat} può cambiare da
 processo a processo; pertanto se nell'area di memoria condivisa si salvano
 anche degli indirizzi, si deve avere cura di usare valori relativi (in genere
 riferiti all'indirizzo di partenza del segmento).
@@ -2599,19 +2599,19 @@ funzione; esso va specificato come maschera binaria, i bit utilizzati sono
 solo due e sono identificati dalle costanti \const{SHM\_RND} e
 \const{SHM\_RDONLY}, che vanno combinate con un OR aritmetico.  Specificando
 \const{SHM\_RND} si evita che \func{shmat} ritorni un errore quando
-\param{shmaddr} non è allineato ai confini di una pagina. Si può quindi usare
-un valore qualunque per \param{shmaddr}, e il segmento verrà comunque
-agganciato, ma al più vicino multiplo di \const{SHMLBA} (il nome della
+\param{shmaddr} non è allineato ai confini di una pagina. Si può quindi usare
+un valore qualunque per \param{shmaddr}, e il segmento verrà comunque
+agganciato, ma al più vicino multiplo di \const{SHMLBA} (il nome della
 costante sta infatti per \textit{rounded}, e serve per specificare un
-indirizzo come arrotondamento, in Linux è equivalente a \const{PAGE\_SIZE}).
+indirizzo come arrotondamento, in Linux è equivalente a \const{PAGE\_SIZE}).
 
 L'uso di \const{SHM\_RDONLY} permette di agganciare il segmento in sola
 lettura (si ricordi che anche le pagine di memoria hanno dei permessi), in tal
-caso un tentativo di scrivere sul segmento comporterà una
+caso un tentativo di scrivere sul segmento comporterà una
 \itindex{segment~violation} violazione di accesso con l'emissione di un
-segnale di \const{SIGSEGV}. Il comportamento usuale di \func{shmat} è quello
+segnale di \const{SIGSEGV}. Il comportamento usuale di \func{shmat} è quello
 di agganciare il segmento con l'accesso in lettura e scrittura (ed il processo
-deve aver questi permessi in \var{shm\_perm}), non è prevista la possibilità
+deve aver questi permessi in \var{shm\_perm}), non è prevista la possibilità
 di agganciare un segmento in sola scrittura.
 
 In caso di successo la funzione aggiorna anche i seguenti campi di
@@ -2634,9 +2634,9 @@ diverso, tutti i segmenti agganciati al processo originario vengono
 automaticamente sganciati. Lo stesso avviene all'uscita del processo
 attraverso una \func{exit}.
 
-Una volta che un segmento di memoria condivisa non serve più, si può
+Una volta che un segmento di memoria condivisa non serve più, si può
 sganciarlo esplicitamente dal processo usando l'altra funzione
-dell'interfaccia, \funcd{shmdt}, il cui prototipo è:
+dell'interfaccia, \funcd{shmdt}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/shm.h}
@@ -2645,7 +2645,7 @@ dell'interfaccia, \funcd{shmdt}, il cui prototipo 
   Sgancia dal processo un segmento di memoria condivisa.
   
   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
-    errore, la funzione fallisce solo quando non c'è un segmento agganciato
+    errore, la funzione fallisce solo quando non c'è un segmento agganciato
     all'indirizzo \param{shmaddr}, con \var{errno} che assume il valore
     \errval{EINVAL}.}
 \end{functions}
@@ -2681,10 +2681,10 @@ viene tolta dallo spazio di indirizzi del processo.
 
 Come esempio di uso di queste funzioni vediamo come implementare una serie di
 funzioni di libreria che ne semplifichino l'uso, automatizzando le operazioni
-più comuni; il codice, contenuto nel file \file{SharedMem.c}, è riportato in
+più comuni; il codice, contenuto nel file \file{SharedMem.c}, è riportato in
 fig.~\ref{fig:ipc_sysv_shm_func}.
 
-La prima funzione (\texttt{\small 3--16}) è \func{ShmCreate} che, data una
+La prima funzione (\texttt{\small 3--16}) è \func{ShmCreate} che, data una
 chiave, crea il segmento di memoria condivisa restituendo il puntatore allo
 stesso. La funzione comincia (\texttt{\small 6}) con il chiamare
 \func{shmget}, usando il flag \const{IPC\_CREATE} per creare il segmento
@@ -2698,7 +2698,7 @@ memoria condivisa al processo con \func{shmat}. In caso di errore
 segmento al valore costante specificato dall'argomento \var{fill}, e poi si
 ritorna il puntatore al segmento stesso.
 
-La seconda funzione (\texttt{\small 17--31}) è \func{ShmFind}, che, data una
+La seconda funzione (\texttt{\small 17--31}) è \func{ShmFind}, che, data una
 chiave, restituisce l'indirizzo del segmento ad essa associato. Anzitutto
 (\texttt{\small 22}) si richiede l'identificatore del segmento con
 \func{shmget}, ritornando (\texttt{\small 23--25}) un puntatore nullo in caso
@@ -2707,33 +2707,33 @@ processo con \func{shmat}, restituendo (\texttt{\small 27--29}) di nuovo un
 puntatore nullo in caso di errore, se invece non ci sono errori si restituisce
 il puntatore ottenuto da \func{shmat}.
 
-La terza funzione (\texttt{\small 32--51}) è \func{ShmRemove} che, data la
+La terza funzione (\texttt{\small 32--51}) è \func{ShmRemove} che, data la
 chiave ed il puntatore associati al segmento di memoria condivisa, prima lo
-sgancia dal processo e poi lo rimuove. Il primo passo (\texttt{\small 37}) è
+sgancia dal processo e poi lo rimuove. Il primo passo (\texttt{\small 37}) è
 la chiamata a \func{shmdt} per sganciare il segmento, restituendo
 (\texttt{\small 38--39}) un valore -1 in caso di errore. Il passo successivo
-(\texttt{\small 41}) è utilizzare \func{shmget} per ottenere l'identificatore
+(\texttt{\small 41}) è utilizzare \func{shmget} per ottenere l'identificatore
 associato al segmento data la chiave \var{key}. Al solito si restituisce un
 valore di -1 (\texttt{\small 42--45}) in caso di errore, mentre se tutto va
 bene si conclude restituendo un valore nullo.
 
-Benché la memoria condivisa costituisca il meccanismo di intercomunicazione
-fra processi più veloce, essa non è sempre il più appropriato, dato che, come
-abbiamo visto, si avrà comunque la necessità di una sincronizzazione degli
-accessi.  Per questo motivo, quando la comunicazione fra processi è
+Benché la memoria condivisa costituisca il meccanismo di intercomunicazione
+fra processi più veloce, essa non è sempre il più appropriato, dato che, come
+abbiamo visto, si avrà comunque la necessità di una sincronizzazione degli
+accessi.  Per questo motivo, quando la comunicazione fra processi è
 sequenziale, altri meccanismi come le pipe, le fifo o i socket, che non
 necessitano di sincronizzazione esplicita, sono da preferire. Essa diventa
-l'unico meccanismo possibile quando la comunicazione non è
+l'unico meccanismo possibile quando la comunicazione non è
 sequenziale\footnote{come accennato in sez.~\ref{sec:ipc_sysv_mq} per la
   comunicazione non sequenziale si possono usare le code di messaggi,
-  attraverso l'uso del campo \var{mtype}, ma solo se quest'ultima può essere
-  effettuata in forma di messaggio.} o quando non può avvenire secondo una
-modalità predefinita.
+  attraverso l'uso del campo \var{mtype}, ma solo se quest'ultima può essere
+  effettuata in forma di messaggio.} o quando non può avvenire secondo una
+modalità predefinita.
 
-Un esempio classico di uso della memoria condivisa è quello del
+Un esempio classico di uso della memoria condivisa è quello del
 ``\textit{monitor}'', in cui viene per scambiare informazioni fra un processo
 server, che vi scrive dei dati di interesse generale che ha ottenuto, e i
-processi client interessati agli stessi dati che così possono leggerli in
+processi client interessati agli stessi dati che così possono leggerli in
 maniera completamente asincrona.  Con questo schema di funzionamento da una
 parte si evita che ciascun processo client debba compiere l'operazione,
 potenzialmente onerosa, di ricavare e trattare i dati, e dall'altra si evita
@@ -2742,13 +2742,13 @@ al processo server di dover gestire l'invio a tutti i client di tutti i dati
 client).
 
 Nel nostro caso implementeremo un ``\textsl{monitor}'' di una directory: un
-processo si incaricherà di tenere sotto controllo alcuni parametri relativi ad
+processo si incaricherà di tenere sotto controllo alcuni parametri relativi ad
 una directory (il numero dei file contenuti, la dimensione totale, quante
 directory, link simbolici, file normali, ecc.) che saranno salvati in un
 segmento di memoria condivisa cui altri processi potranno accedere per
 ricavare la parte di informazione che interessa.
 
-In fig.~\ref{fig:ipc_dirmonitor_main} si è riportata la sezione principale del
+In fig.~\ref{fig:ipc_dirmonitor_main} si è riportata la sezione principale del
 corpo del programma server, insieme alle definizioni delle altre funzioni
 usate nel programma e delle variabili globali, omettendo tutto quello che
 riguarda la gestione delle opzioni e la stampa delle istruzioni di uso a
@@ -2766,15 +2766,15 @@ video; al solito il codice completo si trova con i sorgenti allegati nel file
 \end{figure}
 
 Il programma usa delle variabili globali (\texttt{\small 2--14}) per mantenere
-i valori relativi agli oggetti usati per la comunicazione inter-processo; si è
+i valori relativi agli oggetti usati per la comunicazione inter-processo; si è
 definita inoltre una apposita struttura \struct{DirProp} che contiene i dati
-relativi alle proprietà che si vogliono mantenere nella memoria condivisa, per
+relativi alle proprietà che si vogliono mantenere nella memoria condivisa, per
 l'accesso da parte dei client.
 
 Il programma, dopo la sezione, omessa, relativa alla gestione delle opzioni da
 riga di comando (che si limitano alla eventuale stampa di un messaggio di
 aiuto a video ed all'impostazione della durata dell'intervallo con cui viene
-ripetuto il calcolo delle proprietà della directory) controlla (\texttt{\small
+ripetuto il calcolo delle proprietà della directory) controlla (\texttt{\small
   20--23}) che sia stato specificato l'argomento necessario contenente il nome
 della directory da tenere sotto controllo, senza il quale esce immediatamente
 con un messaggio di errore.
@@ -2784,7 +2784,7 @@ si esegue (\texttt{\small 24--26}) su di esso una \func{chdir}, uscendo
 immediatamente in caso di errore.  Questa funzione serve anche per impostare
 la directory di lavoro del programma nella directory da tenere sotto
 controllo, in vista del successivo uso della funzione
-\func{daemon}.\footnote{si noti come si è potuta fare questa scelta,
+\func{daemon}.\footnote{si noti come si è potuta fare questa scelta,
   nonostante le indicazioni illustrate in sez.~\ref{sec:sess_daemon}, per il
   particolare scopo del programma, che necessita comunque di restare
   all'interno di una directory.} Infine (\texttt{\small 27--29}) si installano
@@ -2792,21 +2792,21 @@ i gestori per i vari segnali di terminazione che, avendo a che fare con un
 programma che deve essere eseguito come server, sono il solo strumento
 disponibile per concluderne l'esecuzione.
 
-Il passo successivo (\texttt{\small 30--39}) è quello di creare gli oggetti di
+Il passo successivo (\texttt{\small 30--39}) è quello di creare gli oggetti di
 intercomunicazione necessari. Si inizia costruendo (\texttt{\small 30}) la
-chiave da usare come riferimento con il nome del programma,\footnote{si è
+chiave da usare come riferimento con il nome del programma,\footnote{si è
   usato un riferimento relativo alla home dell'utente, supposto che i sorgenti
   di GaPiL siano stati installati direttamente in essa. Qualora si effettui
-  una installazione diversa si dovrà correggere il programma.} dopo di che si
+  una installazione diversa si dovrà correggere il programma.} dopo di che si
 richiede (\texttt{\small 31}) la creazione di un segmento di memoria condivisa
 con usando la funzione \func{ShmCreate} illustrata in precedenza (una pagina
-di memoria è sufficiente per i dati che useremo), uscendo (\texttt{\small
+di memoria è sufficiente per i dati che useremo), uscendo (\texttt{\small
   32--35}) qualora la creazione ed il successivo agganciamento al processo non
-abbia successo. Con l'indirizzo \var{shmptr} così ottenuto potremo poi
+abbia successo. Con l'indirizzo \var{shmptr} così ottenuto potremo poi
 accedere alla memoria condivisa, che, per come abbiamo lo abbiamo definito,
-sarà vista nella forma data da \struct{DirProp}. Infine (\texttt{\small
+sarà vista nella forma data da \struct{DirProp}. Infine (\texttt{\small
   36--39}) utilizzando sempre la stessa chiave, si crea, tramite le funzioni
-di interfaccia già descritte in sez.~\ref{sec:ipc_sysv_sem}, anche un mutex,
+di interfaccia già descritte in sez.~\ref{sec:ipc_sysv_sem}, anche un mutex,
 che utilizzeremo per regolare l'accesso alla memoria condivisa.
 
 \begin{figure}[!htb]
@@ -2821,15 +2821,15 @@ che utilizzeremo per regolare l'accesso alla memoria condivisa.
 
 Completata l'inizializzazione e la creazione degli oggetti di
 intercomunicazione il programma entra nel ciclo principale (\texttt{\small
-  40--49}) dove vengono eseguite indefinitamente le attività di monitoraggio.
-Il primo passo (\texttt{\small 41}) è eseguire \func{daemon} per proseguire
+  40--49}) dove vengono eseguite indefinitamente le attività di monitoraggio.
+Il primo passo (\texttt{\small 41}) è eseguire \func{daemon} per proseguire
 con l'esecuzione in background come si conviene ad un programma demone; si
-noti che si è mantenuta, usando un valore non nullo del primo argomento, la
-directory di lavoro corrente.  Una volta che il programma è andato in
+noti che si è mantenuta, usando un valore non nullo del primo argomento, la
+directory di lavoro corrente.  Una volta che il programma è andato in
 background l'esecuzione prosegue (\texttt{\small 42--48}) all'interno di un
 ciclo infinito: si inizia (\texttt{\small 43}) bloccando il mutex con
 \func{MutexLock} per poter accedere alla memoria condivisa (la funzione si
-bloccherà automaticamente se qualche client sta leggendo), poi (\texttt{\small
+bloccherà automaticamente se qualche client sta leggendo), poi (\texttt{\small
   44}) si cancellano i valori precedentemente immagazzinati nella memoria
 condivisa con \func{memset}, e si esegue (\texttt{\small 45}) un nuovo calcolo
 degli stessi utilizzando la funzione \func{DirScan}; infine (\texttt{\small
@@ -2838,31 +2838,31 @@ degli stessi utilizzando la funzione \func{DirScan}; infine (\texttt{\small
 l'opzione \code{-p} con una \func{sleep}.
 
 Si noti come per il calcolo dei valori da mantenere nella memoria condivisa si
-sia usata ancora una volta la funzione \func{DirScan}, già utilizzata (e
+sia usata ancora una volta la funzione \func{DirScan}, già utilizzata (e
 descritta in dettaglio) in sez.~\ref{sec:file_dir_read}, che ci permette di
 effettuare la scansione delle voci della directory, chiamando per ciascuna di
 esse la funzione \func{ComputeValues}, che esegue tutti i calcoli necessari.
 
-Il codice di quest'ultima è riportato in fig.~\ref{fig:ipc_dirmonitor_sub}.
-Come si vede la funzione (\texttt{\small 2--16}) è molto semplice e si limita
+Il codice di quest'ultima è riportato in fig.~\ref{fig:ipc_dirmonitor_sub}.
+Come si vede la funzione (\texttt{\small 2--16}) è molto semplice e si limita
 a chiamare (\texttt{\small 5}) la funzione \func{stat} sul file indicato da
 ciascuna voce, per ottenerne i dati, che poi utilizza per incrementare i vari
 contatori nella memoria condivisa, cui accede grazie alla variabile globale
 \var{shmptr}.
 
-Dato che la funzione è chiamata da \func{DirScan}, si è all'interno del ciclo
-principale del programma, con un mutex acquisito, perciò non è necessario
-effettuare nessun controllo e si può accedere direttamente alla memoria
+Dato che la funzione è chiamata da \func{DirScan}, si è all'interno del ciclo
+principale del programma, con un mutex acquisito, perciò non è necessario
+effettuare nessun controllo e si può accedere direttamente alla memoria
 condivisa usando \var{shmptr} per riempire i campi della struttura
-\struct{DirProp}; così prima (\texttt{\small 6--7}) si sommano le dimensioni
+\struct{DirProp}; così prima (\texttt{\small 6--7}) si sommano le dimensioni
 dei file ed il loro numero, poi, utilizzando le macro di
 tab.~\ref{tab:file_type_macro}, si contano (\texttt{\small 8--14}) quanti ce
 ne sono per ciascun tipo.
 
-In fig.~\ref{fig:ipc_dirmonitor_sub} è riportato anche il codice
+In fig.~\ref{fig:ipc_dirmonitor_sub} è riportato anche il codice
 (\texttt{\small 17--23}) del gestore dei segnali di terminazione, usato per
 chiudere il programma. Esso, oltre a provocare l'uscita del programma, si
-incarica anche di cancellare tutti gli oggetti di intercomunicazione non più
+incarica anche di cancellare tutti gli oggetti di intercomunicazione non più
 necessari.  Per questo anzitutto (\texttt{\small 19}) acquisisce il mutex con
 \func{MutexLock}, per evitare di operare mentre un client sta ancora leggendo
 i dati, dopo di che (\texttt{\small 20}) distacca e rimuove il segmento di
@@ -2875,15 +2875,15 @@ rimuove il mutex con \func{MutexRemove} ed esce (\texttt{\small 22}).
     \includecodesample{listati/ReadMonitor.c}
   \end{minipage} 
   \normalsize 
-  \caption{Codice del programma client del monitor delle proprietà di una
+  \caption{Codice del programma client del monitor delle proprietà di una
     directory, \file{ReadMonitor.c}.}
   \label{fig:ipc_dirmonitor_client}
 \end{figure}
 
 Il codice del client usato per leggere le informazioni mantenute nella memoria
-condivisa è riportato in fig.~\ref{fig:ipc_dirmonitor_client}. Al solito si è
+condivisa è riportato in fig.~\ref{fig:ipc_dirmonitor_client}. Al solito si è
 omessa la sezione di gestione delle opzioni e la funzione che stampa a video
-le istruzioni; il codice completo è nei sorgenti allegati, nel file
+le istruzioni; il codice completo è nei sorgenti allegati, nel file
 \file{ReadMonitor.c}.
 
 Una volta conclusa la gestione delle opzioni a riga di comando il programma
@@ -2896,20 +2896,20 @@ mutex.  Completata l'inizializzazione ed ottenuti i riferimenti agli oggetti
 di intercomunicazione necessari viene eseguito il corpo principale del
 programma (\texttt{\small 21--33}); si comincia (\texttt{\small 22})
 acquisendo il mutex con \func{MutexLock}; qui avviene il blocco del processo
-se la memoria condivisa non è disponibile.  Poi (\texttt{\small 23--31}) si
+se la memoria condivisa non è disponibile.  Poi (\texttt{\small 23--31}) si
 stampano i vari valori mantenuti nella memoria condivisa attraverso l'uso di
 \var{shmptr}.  Infine (\texttt{\small 41}) con \func{MutexUnlock} si rilascia
 il mutex, prima di uscire.
 
 Verifichiamo allora il funzionamento dei nostri programmi; al solito, usando
 le funzioni di libreria occorre definire opportunamente
-\code{LD\_LIBRARY\_PATH}; poi si potrà lanciare il server con:
+\code{LD\_LIBRARY\_PATH}; poi si potrà lanciare il server con:
 \begin{Verbatim}
 [piccardi@gont sources]$ ./dirmonitor ./
 \end{Verbatim}
 %$
-ed avendo usato \func{daemon} il comando ritornerà immediatamente. Una volta
-che il server è in esecuzione, possiamo passare ad invocare il client per
+ed avendo usato \func{daemon} il comando ritornerà immediatamente. Una volta
+che il server è in esecuzione, possiamo passare ad invocare il client per
 verificarne i risultati, in tal caso otterremo:
 \begin{Verbatim}
 [piccardi@gont sources]$ ./readmon 
@@ -2924,7 +2924,7 @@ Totale  71 file, per 489831 byte
 \end{Verbatim}
 %$
 ed un rapido calcolo (ad esempio con \code{ls -a | wc} per contare i file) ci
-permette di verificare che il totale dei file è giusto. Un controllo con
+permette di verificare che il totale dei file è giusto. Un controllo con
 \cmd{ipcs} ci permette inoltre di verificare la presenza di un segmento di
 memoria condivisa e di un semaforo:
 \begin{Verbatim}
@@ -2984,7 +2984,7 @@ key        msqid      owner      perms      used-bytes   messages
 
 %% Per capire meglio il funzionamento delle funzioni facciamo ancora una volta
 %% riferimento alle strutture con cui il kernel implementa i segmenti di memoria
-%% condivisa; uno schema semplificato della struttura è illustrato in
+%% condivisa; uno schema semplificato della struttura è illustrato in
 %% fig.~\ref{fig:ipc_shm_struct}. 
 
 %% \begin{figure}[htb]
@@ -3005,7 +3005,7 @@ Come abbiamo detto in sez.~\ref{sec:ipc_sysv_generic}, e ripreso nella
 descrizione dei singoli oggetti che ne fan parte, il \textit{SysV IPC}
 presenta numerosi problemi; in \cite{APUE}\footnote{in particolare nel
   capitolo 14.}  Stevens ne effettua una accurata analisi (alcuni dei concetti
-sono già stati accennati in precedenza) ed elenca alcune possibili tecniche
+sono già stati accennati in precedenza) ed elenca alcune possibili tecniche
 alternative, che vogliamo riprendere in questa sezione.
 
 
@@ -3015,17 +3015,17 @@ alternative, che vogliamo riprendere in questa sezione.
 Le code di messaggi sono probabilmente il meno usato degli oggetti del
 \textit{SysV IPC}; esse infatti nacquero principalmente come meccanismo di
 comunicazione bidirezionale quando ancora le pipe erano unidirezionali; con la
-disponibilità di \func{socketpair} (vedi sez.~\ref{sec:ipc_socketpair}) o
-utilizzando una coppia di pipe, si può ottenere questo risultato senza
+disponibilità di \func{socketpair} (vedi sez.~\ref{sec:ipc_socketpair}) o
+utilizzando una coppia di pipe, si può ottenere questo risultato senza
 incorrere nelle complicazioni introdotte dal \textit{SysV IPC}.
 
-In realtà, grazie alla presenza del campo \var{mtype}, le code di messaggi
+In realtà, grazie alla presenza del campo \var{mtype}, le code di messaggi
 hanno delle caratteristiche ulteriori, consentendo una classificazione dei
 messaggi ed un accesso non rigidamente sequenziale; due caratteristiche che
 sono impossibili da ottenere con le pipe e i socket di \func{socketpair}.  A
-queste esigenze però si può comunque ovviare in maniera diversa con un uso
+queste esigenze però si può comunque ovviare in maniera diversa con un uso
 combinato della memoria condivisa e dei meccanismi di sincronizzazione, per
-cui alla fine l'uso delle code di messaggi classiche è relativamente poco
+cui alla fine l'uso delle code di messaggi classiche è relativamente poco
 diffuso.
 
 \subsection{I \textsl{file di lock}}
@@ -3037,32 +3037,32 @@ Come illustrato in sez.~\ref{sec:ipc_sysv_sem} i semafori del \textit{SysV IPC}
 presentano una interfaccia inutilmente complessa e con alcuni difetti
 strutturali, per questo quando si ha una semplice esigenza di sincronizzazione
 per la quale basterebbe un semaforo binario (quello che abbiamo definito come
-\textit{mutex}), per indicare la disponibilità o meno di una risorsa, senza la
-necessità di un contatore come i semafori, si possono utilizzare metodi
+\textit{mutex}), per indicare la disponibilità o meno di una risorsa, senza la
+necessità di un contatore come i semafori, si possono utilizzare metodi
 alternativi.
 
-La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare
+La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare
 dei \textsl{file di lock} (per i quali esiste anche una opportuna directory,
 \file{/var/lock}, nel filesystem standard). Per questo si usa la
 caratteristica della funzione \func{open} (illustrata in
-sez.~\ref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo
-  standard POSIX.1, ciò non toglie che in alcune implementazioni questa
+sez.~\ref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo
+  standard POSIX.1, ciò non toglie che in alcune implementazioni questa
   tecnica possa non funzionare; in particolare per Linux, nel caso di NFS, si
-  è comunque soggetti alla possibilità di una \itindex{race~condition}
+  è comunque soggetti alla possibilità di una \itindex{race~condition}
   \textit{race condition}.} che essa ritorni un errore quando usata con i
 flag di \const{O\_CREAT} e \const{O\_EXCL}. In tal modo la creazione di un
-\textsl{file di lock} può essere eseguita atomicamente, il processo che crea
-il file con successo si può considerare come titolare del lock (e della
-risorsa ad esso associata) mentre il rilascio si può eseguire con una chiamata
+\textsl{file di lock} può essere eseguita atomicamente, il processo che crea
+il file con successo si può considerare come titolare del lock (e della
+risorsa ad esso associata) mentre il rilascio si può eseguire con una chiamata
 ad \func{unlink}.
 
-Un esempio dell'uso di questa funzione è mostrato dalle funzioni
+Un esempio dell'uso di questa funzione è mostrato dalle funzioni
 \func{LockFile} ed \func{UnlockFile} riportate in fig.~\ref{fig:ipc_file_lock}
 (sono contenute in \file{LockFile.c}, un altro dei sorgenti allegati alla
 guida) che permettono rispettivamente di creare e rimuovere un \textsl{file di
-  lock}. Come si può notare entrambe le funzioni sono elementari; la prima
+  lock}. Come si può notare entrambe le funzioni sono elementari; la prima
 (\texttt{\small 4--10}) si limita ad aprire il file di lock (\texttt{\small
-  9}) nella modalità descritta, mentre la seconda (\texttt{\small 11--17}) lo
+  9}) nella modalità descritta, mentre la seconda (\texttt{\small 11--17}) lo
 cancella con \func{unlink}.
 
 \begin{figure}[!htb]
@@ -3076,33 +3076,33 @@ cancella con \func{unlink}.
   \label{fig:ipc_file_lock}
 \end{figure}
 
-Uno dei limiti di questa tecnica è che, come abbiamo già accennato in
-sez.~\ref{sec:file_open}, questo comportamento di \func{open} può non
-funzionare (la funzione viene eseguita, ma non è garantita l'atomicità
-dell'operazione) se il filesystem su cui si va ad operare è su NFS; in tal
-caso si può adottare una tecnica alternativa che prevede l'uso della
+Uno dei limiti di questa tecnica è che, come abbiamo già accennato in
+sez.~\ref{sec:file_open}, questo comportamento di \func{open} può non
+funzionare (la funzione viene eseguita, ma non è garantita l'atomicità
+dell'operazione) se il filesystem su cui si va ad operare è su NFS; in tal
+caso si può adottare una tecnica alternativa che prevede l'uso della
 \func{link} per creare come \textsl{file di lock} un hard link ad un file
-esistente; se il link esiste già e la funzione fallisce, significa che la
-risorsa è bloccata e potrà essere sbloccata solo con un \func{unlink},
-altrimenti il link è creato ed il lock acquisito; il controllo e l'eventuale
+esistente; se il link esiste già e la funzione fallisce, significa che la
+risorsa è bloccata e potrà essere sbloccata solo con un \func{unlink},
+altrimenti il link è creato ed il lock acquisito; il controllo e l'eventuale
 acquisizione sono atomici; la soluzione funziona anche su NFS, ma ha un altro
-difetto è che è quello di poterla usare solo se si opera all'interno di uno
+difetto è che è quello di poterla usare solo se si opera all'interno di uno
 stesso filesystem.
 
 In generale comunque l'uso di un \textsl{file di lock} presenta parecchi
 problemi che non lo rendono una alternativa praticabile per la
 sincronizzazione: anzitutto in caso di terminazione imprevista del processo,
 si lascia allocata la risorsa (il \textsl{file di lock}) e questa deve essere
-sempre cancellata esplicitamente.  Inoltre il controllo della disponibilità
-può essere eseguito solo con una tecnica di \itindex{polling}
-\textit{polling}, ed è quindi molto inefficiente.
+sempre cancellata esplicitamente.  Inoltre il controllo della disponibilità
+può essere eseguito solo con una tecnica di \itindex{polling}
+\textit{polling}, ed è quindi molto inefficiente.
 
-La tecnica dei file di lock ha comunque una sua utilità, e può essere usata
-con successo quando l'esigenza è solo quella di segnalare l'occupazione di una
-risorsa, senza necessità di attendere che questa si liberi; ad esempio la si
+La tecnica dei file di lock ha comunque una sua utilità, e può essere usata
+con successo quando l'esigenza è solo quella di segnalare l'occupazione di una
+risorsa, senza necessità di attendere che questa si liberi; ad esempio la si
 usa spesso per evitare interferenze sull'uso delle porte seriali da parte di
-più programmi: qualora si trovi un file di lock il programma che cerca di
-accedere alla seriale si limita a segnalare che la risorsa non è disponibile.
+più programmi: qualora si trovi un file di lock il programma che cerca di
+accedere alla seriale si limita a segnalare che la risorsa non è disponibile.
 
 \index{file!di lock|)}
 
@@ -3111,23 +3111,23 @@ accedere alla seriale si limita a segnalare che la risorsa non 
 \label{sec:ipc_lock_file}
 
 Dato che i \index{file!di lock} file di lock presentano gli inconvenienti
-illustrati in precedenza, la tecnica alternativa di sincronizzazione più
-comune è quella di fare ricorso al \index{file!locking} \textit{file locking}
+illustrati in precedenza, la tecnica alternativa di sincronizzazione più
+comune è quella di fare ricorso al \index{file!locking} \textit{file locking}
 (trattato in sez.~\ref{sec:file_locking}) usando \func{fcntl} su un file
 creato per l'occasione per ottenere un write lock. In questo modo potremo
-usare il lock come un \textit{mutex}: per bloccare la risorsa basterà
-acquisire il lock, per sbloccarla basterà rilasciare il lock. Una richiesta
-fatta con un write lock metterà automaticamente il processo in stato di
-attesa, senza necessità di ricorrere al \itindex{polling} \textit{polling} per
-determinare la disponibilità della risorsa, e al rilascio della stessa da
-parte del processo che la occupava si otterrà il nuovo lock atomicamente.
+usare il lock come un \textit{mutex}: per bloccare la risorsa basterà
+acquisire il lock, per sbloccarla basterà rilasciare il lock. Una richiesta
+fatta con un write lock metterà automaticamente il processo in stato di
+attesa, senza necessità di ricorrere al \itindex{polling} \textit{polling} per
+determinare la disponibilità della risorsa, e al rilascio della stessa da
+parte del processo che la occupava si otterrà il nuovo lock atomicamente.
 
 Questo approccio presenta il notevole vantaggio che alla terminazione di un
 processo tutti i lock acquisiti vengono rilasciati automaticamente (alla
 chiusura dei relativi file) e non ci si deve preoccupare di niente; inoltre
-non consuma risorse permanentemente allocate nel sistema. Lo svantaggio è che,
-dovendo fare ricorso a delle operazioni sul filesystem, esso è in genere
-leggermente più lento.
+non consuma risorse permanentemente allocate nel sistema. Lo svantaggio è che,
+dovendo fare ricorso a delle operazioni sul filesystem, esso è in genere
+leggermente più lento.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -3141,75 +3141,75 @@ leggermente pi
 \end{figure}
 
 Il codice delle varie funzioni usate per implementare un mutex utilizzando il
-\textit{file locking} \index{file!locking} è riportato in
-fig.~\ref{fig:ipc_flock_mutex}; si è mantenuta volutamente una struttura
+\textit{file locking} \index{file!locking} è riportato in
+fig.~\ref{fig:ipc_flock_mutex}; si è mantenuta volutamente una struttura
 analoga alle precedenti funzioni che usano i semafori, anche se le due
 interfacce non possono essere completamente equivalenti, specie per quanto
 riguarda la rimozione del mutex.
 
-La prima funzione (\texttt{\small 1--5}) è \func{CreateMutex}, e serve a
-creare il mutex; la funzione è estremamente semplice, e si limita
+La prima funzione (\texttt{\small 1--5}) è \func{CreateMutex}, e serve a
+creare il mutex; la funzione è estremamente semplice, e si limita
 (\texttt{\small 4}) a creare, con una opportuna chiamata ad \func{open}, il
-file che sarà usato per il successivo \textit{file locking}, assicurandosi che
-non esista già (nel qual caso segnala un errore); poi restituisce il file
-descriptor che sarà usato dalle altre funzioni per acquisire e rilasciare il
+file che sarà usato per il successivo \textit{file locking}, assicurandosi che
+non esista già (nel qual caso segnala un errore); poi restituisce il file
+descriptor che sarà usato dalle altre funzioni per acquisire e rilasciare il
 mutex.
 
-La seconda funzione (\texttt{\small 6--10}) è \func{FindMutex}, che, come la
-precedente, è stata definita per mantenere una analogia con la corrispondente
+La seconda funzione (\texttt{\small 6--10}) è \func{FindMutex}, che, come la
+precedente, è stata definita per mantenere una analogia con la corrispondente
 funzione basata sui semafori. Anch'essa si limita (\texttt{\small 9}) ad
 aprire il file da usare per il \index{file!locking} \textit{file locking},
 solo che in questo caso le opzioni di \func{open} sono tali che il file in
-questione deve esistere di già.
+questione deve esistere di già.
 
-La terza funzione (\texttt{\small 11--22}) è \func{LockMutex} e serve per
+La terza funzione (\texttt{\small 11--22}) è \func{LockMutex} e serve per
 acquisire il mutex. La funzione definisce (\texttt{\small 14}) e inizializza
 (\texttt{\small 16--19}) la struttura \var{lock} da usare per acquisire un
 write lock sul file, che poi (\texttt{\small 21}) viene richiesto con
-\func{fcntl}, restituendo il valore di ritorno di quest'ultima. Se il file è
+\func{fcntl}, restituendo il valore di ritorno di quest'ultima. Se il file è
 libero il lock viene acquisito e la funzione ritorna immediatamente;
-altrimenti \func{fcntl} si bloccherà (si noti che la si è chiamata con
+altrimenti \func{fcntl} si bloccherà (si noti che la si è chiamata con
 \const{F\_SETLKW}) fino al rilascio del lock.
 
-La quarta funzione (\texttt{\small 24--34}) è \func{UnlockMutex} e serve a
-rilasciare il mutex. La funzione è analoga alla precedente, solo che in questo
+La quarta funzione (\texttt{\small 24--34}) è \func{UnlockMutex} e serve a
+rilasciare il mutex. La funzione è analoga alla precedente, solo che in questo
 caso si inizializza (\texttt{\small 28--31}) la struttura \var{lock} per il
 rilascio del lock, che viene effettuato (\texttt{\small 33}) con la opportuna
 chiamata a \func{fcntl}. Avendo usato il \index{file!locking} \textit{file
   locking} in semantica POSIX (si riveda quanto detto
 sez.~\ref{sec:file_posix_lock}) solo il processo che ha precedentemente
-eseguito il lock può sbloccare il mutex.
+eseguito il lock può sbloccare il mutex.
 
-La quinta funzione (\texttt{\small 36--39}) è \func{RemoveMutex} e serve a
-cancellare il mutex. Anche questa funzione è stata definita per mantenere una
+La quinta funzione (\texttt{\small 36--39}) è \func{RemoveMutex} e serve a
+cancellare il mutex. Anche questa funzione è stata definita per mantenere una
 analogia con le funzioni basate sui semafori, e si limita a cancellare
 (\texttt{\small 38}) il file con una chiamata ad \func{unlink}. Si noti che in
-questo caso la funzione non ha effetto sui mutex già ottenuti con precedenti
+questo caso la funzione non ha effetto sui mutex già ottenuti con precedenti
 chiamate a \func{FindMutex} o \func{CreateMutex}, che continueranno ad essere
 disponibili fintanto che i relativi file descriptor restano aperti. Pertanto
-per rilasciare un mutex occorrerà prima chiamare \func{UnlockMutex} oppure
+per rilasciare un mutex occorrerà prima chiamare \func{UnlockMutex} oppure
 chiudere il file usato per il lock.
 
-La sesta funzione (\texttt{\small 41--55}) è \func{ReadMutex} e serve a
+La sesta funzione (\texttt{\small 41--55}) è \func{ReadMutex} e serve a
 leggere lo stato del mutex. In questo caso si prepara (\texttt{\small 46--49})
 la solita struttura \var{lock} come l'acquisizione del lock, ma si effettua
 (\texttt{\small 51}) la chiamata a \func{fcntl} usando il comando
 \const{F\_GETLK} per ottenere lo stato del lock, e si restituisce
 (\texttt{\small 52}) il valore di ritorno in caso di errore, ed il valore del
 campo \var{l\_type} (che descrive lo stato del lock) altrimenti
-(\texttt{\small 54}). Per questo motivo la funzione restituirà -1 in caso di
+(\texttt{\small 54}). Per questo motivo la funzione restituirà -1 in caso di
 errore e uno dei due valori \const{F\_UNLCK} o \const{F\_WRLCK}\footnote{non
   si dovrebbe mai avere il terzo valore possibile, \const{F\_RDLCK}, dato che
-  la nostra interfaccia usa solo i write lock. Però è sempre possibile che
+  la nostra interfaccia usa solo i write lock. Però è sempre possibile che
   siano richiesti altri lock sul file al di fuori dell'interfaccia, nel qual
   caso si potranno avere, ovviamente, interferenze indesiderate.} in caso di
-successo, ad indicare che il mutex è, rispettivamente, libero o occupato.
+successo, ad indicare che il mutex è, rispettivamente, libero o occupato.
 
 Basandosi sulla semantica dei file lock POSIX valgono tutte le considerazioni
 relative al comportamento di questi ultimi fatte in
 sez.~\ref{sec:file_posix_lock}; questo significa ad esempio che, al contrario
 di quanto avveniva con l'interfaccia basata sui semafori, chiamate multiple a
-\func{UnlockMutex} o \func{LockMutex} non si cumulano e non danno perciò
+\func{UnlockMutex} o \func{LockMutex} non si cumulano e non danno perciò
 nessun inconveniente.
 
 
@@ -3217,9 +3217,9 @@ nessun inconveniente.
 \label{sec:ipc_mmap_anonymous}
 
 \itindbeg{memory~mapping}
-Abbiamo già visto che quando i processi sono \textsl{correlati}\footnote{se
-  cioè hanno almeno un progenitore comune.} l'uso delle pipe può costituire
-una valida alternativa alle code di messaggi; nella stessa situazione si può
+Abbiamo già visto che quando i processi sono \textsl{correlati}\footnote{se
+  cioè hanno almeno un progenitore comune.} l'uso delle pipe può costituire
+una valida alternativa alle code di messaggi; nella stessa situazione si può
 evitare l'uso di una memoria condivisa facendo ricorso al cosiddetto
 \textit{memory mapping} anonimo.
 
@@ -3227,23 +3227,23 @@ In sez.~\ref{sec:file_memory_map} abbiamo visto come sia possibile mappare il
 contenuto di un file nella memoria di un processo, e che, quando viene usato
 il flag \const{MAP\_SHARED}, le modifiche effettuate al contenuto del file
 vengono viste da tutti i processi che lo hanno mappato. Utilizzare questa
-tecnica per creare una memoria condivisa fra processi diversi è estremamente
-inefficiente, in quanto occorre passare attraverso il disco. Però abbiamo
+tecnica per creare una memoria condivisa fra processi diversi è estremamente
+inefficiente, in quanto occorre passare attraverso il disco. Però abbiamo
 visto anche che se si esegue la mappatura con il flag \const{MAP\_ANONYMOUS}
 la regione mappata non viene associata a nessun file, anche se quanto scritto
-rimane in memoria e può essere riletto; allora, dato che un processo figlio
-mantiene nel suo spazio degli indirizzi anche le regioni mappate, esso sarà
-anche in grado di accedere a quanto in esse è contenuto.
+rimane in memoria e può essere riletto; allora, dato che un processo figlio
+mantiene nel suo spazio degli indirizzi anche le regioni mappate, esso sarà
+anche in grado di accedere a quanto in esse è contenuto.
 
 In questo modo diventa possibile creare una memoria condivisa fra processi
-diversi, purché questi abbiano almeno un progenitore comune che ha effettuato
+diversi, purché questi abbiano almeno un progenitore comune che ha effettuato
 il \textit{memory mapping} anonimo.\footnote{nei sistemi derivati da SysV una
-  funzionalità simile a questa viene implementata mappando il file speciale
+  funzionalità simile a questa viene implementata mappando il file speciale
   \file{/dev/zero}. In tal caso i valori scritti nella regione mappata non
   vengono ignorati (come accade qualora si scriva direttamente sul file), ma
-  restano in memoria e possono essere riletti secondo le stesse modalità usate
+  restano in memoria e possono essere riletti secondo le stesse modalità usate
   nel \textit{memory mapping} anonimo.} Vedremo come utilizzare questa tecnica
-più avanti, quando realizzeremo una nuova versione del monitor visto in
+più avanti, quando realizzeremo una nuova versione del monitor visto in
 sez.~\ref{sec:ipc_sysv_shm} che possa restituisca i risultati via rete.
 \itindend{memory~mapping}
 
@@ -3263,23 +3263,23 @@ una interfaccia completamente nuova, che tratteremo in questa sezione.
 \label{sec:ipc_posix_generic}
 
 Oggi Linux supporta tutti gli oggetti definito nello standard POSIX per l'IPC,
-ma a lungo non è stato così; la memoria condivisa è presente a partire dal
+ma a lungo non è stato così; la memoria condivisa è presente a partire dal
 kernel 2.4.x, i semafori sono forniti dalle \acr{glibc} nella sezione che
 implementa i \itindex{thread} \textit{thread} POSIX di nuova generazione che
 richiedono il kernel 2.6, le code di messaggi sono supportate a partire dal
 kernel 2.6.6.
 
-La caratteristica fondamentale dell'interfaccia POSIX è l'abbandono dell'uso
+La caratteristica fondamentale dell'interfaccia POSIX è l'abbandono dell'uso
 degli identificatori e delle chiavi visti nel SysV IPC, per passare ai
 \itindex{POSIX~IPC~names} \textit{POSIX IPC names}, che sono sostanzialmente
 equivalenti ai nomi dei file. Tutte le funzioni che creano un oggetto di IPC
 POSIX prendono come primo argomento una stringa che indica uno di questi nomi;
-lo standard è molto generico riguardo l'implementazione, ed i nomi stessi
-possono avere o meno una corrispondenza sul filesystem; tutto quello che è
-richiesto è che:
+lo standard è molto generico riguardo l'implementazione, ed i nomi stessi
+possono avere o meno una corrispondenza sul filesystem; tutto quello che è
+richiesto è che:
 \begin{itemize*}
 \item i nomi devono essere conformi alle regole che caratterizzano i
-  \itindex{pathname} \textit{pathname}, in particolare non essere più lunghi di
+  \itindex{pathname} \textit{pathname}, in particolare non essere più lunghi di
   \const{PATH\_MAX} byte e terminati da un carattere nullo.
 \item se il nome inizia per una \texttt{/} chiamate differenti allo stesso
   nome fanno riferimento allo stesso oggetto, altrimenti l'interpretazione del
@@ -3288,8 +3288,8 @@ richiesto 
   dall'implementazione.
 \end{itemize*}
 
-Data la assoluta genericità delle specifiche, il comportamento delle funzioni
-è subordinato in maniera quasi completa alla relativa
+Data la assoluta genericità delle specifiche, il comportamento delle funzioni
+è subordinato in maniera quasi completa alla relativa
 implementazione.\footnote{tanto che Stevens in \cite{UNP2} cita questo caso
   come un esempio della maniera standard usata dallo standard POSIX per
   consentire implementazioni non standardizzabili.} Nel caso di Linux, sia per
@@ -3302,11 +3302,11 @@ specificati nelle relative funzioni sono considerati come un
 \itindsub{pathname}{assoluto} \textit{pathname} assoluto (comprendente
 eventuali sottodirectory) rispetto a queste radici.
 
-Il vantaggio degli oggetti di IPC POSIX è comunque che essi vengono inseriti
+Il vantaggio degli oggetti di IPC POSIX è comunque che essi vengono inseriti
 nell'albero dei file, e possono essere maneggiati con le usuali funzioni e
-comandi di accesso ai file,\footnote{questo è vero nel caso di Linux, che usa
-  una implementazione che lo consente, non è detto che altrettanto valga per
-  altri kernel; in particolare, come si può facilmente verificare con uno
+comandi di accesso ai file,\footnote{questo è vero nel caso di Linux, che usa
+  una implementazione che lo consente, non è detto che altrettanto valga per
+  altri kernel; in particolare, come si può facilmente verificare con uno
   \cmd{strace}, sia per la memoria condivisa che per le code di messaggi le
   system call utilizzate da Linux sono le stesse di quelle dei file, essendo
   detti oggetti realizzati come tali in appositi filesystem.}  che funzionano
@@ -3319,7 +3319,7 @@ quella particolare (si ricordi quanto visto in
 sez.~\ref{sec:ipc_sysv_access_control}) che viene usata per gli oggetti del
 SysV IPC.  Per quanto riguarda l'attribuzione dell'utente e del gruppo
 proprietari dell'oggetto alla creazione di quest'ultimo essa viene effettuata
-secondo la semantica SysV: corrispondono cioè a user-ID e group-ID effettivi
+secondo la semantica SysV: corrispondono cioè a user-ID e group-ID effettivi
 del processo che esegue la creazione.
 
 
@@ -3327,34 +3327,34 @@ del processo che esegue la creazione.
 \label{sec:ipc_posix_mq}
 
 Le code di messaggi POSIX sono supportate da Linux a partire dalla versione
-2.6.6-rc1 del kernel,\footnote{l'implementazione è dovuta a Michal Wronski e
+2.6.6-rc1 del kernel,\footnote{l'implementazione è dovuta a Michal Wronski e
   Krzysztof Benedyczak, e le relative informazioni si possono trovare su
   \href{http://www.geocities.com/wronski12/posix_ipc/index.html}
   {\textsf{http://www.geocities.com/wronski12/posix\_ipc/index.html}}.} In
 generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
-usate, dato che i socket, nei casi in cui sono sufficienti, sono più comodi, e
-che in casi più complessi la comunicazione può essere gestita direttamente con
-mutex (o semafori) e memoria condivisa con tutta la flessibilità che occorre.
+usate, dato che i socket, nei casi in cui sono sufficienti, sono più comodi, e
+che in casi più complessi la comunicazione può essere gestita direttamente con
+mutex (o semafori) e memoria condivisa con tutta la flessibilità che occorre.
 
 Per poter utilizzare le code di messaggi, oltre ad utilizzare un kernel
 superiore al 2.6.6 (o precedente, se sono stati opportunamente applicati i
 relativi patch) occorre utilizzare la libreria \file{libmqueue}\footnote{i
-  programmi che usano le code di messaggi cioè devono essere compilati
+  programmi che usano le code di messaggi cioè devono essere compilati
   aggiungendo l'opzione \code{-lmqueue} al comando \cmd{gcc}; in
   corrispondenza all'inclusione del supporto nel kernel ufficiale anche
-  \file{libmqueue} è stata inserita nelle \acr{glibc}, a partire dalla
+  \file{libmqueue} è stata inserita nelle \acr{glibc}, a partire dalla
   versione 2.3.4 delle medesime.} che contiene le funzioni dell'interfaccia
-POSIX.\footnote{in realtà l'implementazione è realizzata tramite delle
+POSIX.\footnote{in realtà l'implementazione è realizzata tramite delle
   opportune chiamate ad \func{ioctl} sui file del filesystem speciale su cui
   vengono mantenuti questi oggetti di IPC.}
 
 La libreria inoltre richiede la presenza dell'apposito filesystem di tipo
-\texttt{mqueue} montato su \file{/dev/mqueue}; questo può essere fatto
+\texttt{mqueue} montato su \file{/dev/mqueue}; questo può essere fatto
 aggiungendo ad \conffile{/etc/fstab} una riga come:
 \begin{verbatim}
 mqueue   /dev/mqueue       mqueue    defaults        0      0
 \end{verbatim}
-ed esso sarà utilizzato come radice sulla quale vengono risolti i nomi delle
+ed esso sarà utilizzato come radice sulla quale vengono risolti i nomi delle
 code di messaggi che iniziano con una ``\texttt{/}''. Le opzioni di mount
 accettate sono \texttt{uid}, \texttt{gid} e \texttt{mode} che permettono
 rispettivamente di impostare l'utente, il gruppo ed i permessi associati al
@@ -3362,7 +3362,7 @@ filesystem.
 
 
 La funzione che permette di aprire (e crearla se non esiste ancora) una coda
-di messaggi POSIX è \funcd{mq\_open}, ed il suo prototipo è:
+di messaggi POSIX è \funcd{mq\_open}, ed il suo prototipo è:
 \begin{functions}
   \headdecl{mqueue.h} 
   
@@ -3374,17 +3374,17 @@ di messaggi POSIX 
   Apre una coda di messaggi POSIX impostandone le caratteristiche.
   
   \bodydesc{La funzione restituisce il descrittore associato alla coda in caso
-    di successo e -1 per un errore; nel quel caso \var{errno} assumerà i
+    di successo e -1 per un errore; nel quel caso \var{errno} assumerà i
     valori:
     \begin{errlist}
     \item[\errcode{EACCES}] il processo non ha i privilegi per accedere al
       alla memoria secondo quanto specificato da \param{oflag}.
-    \item[\errcode{EEXIST}] si è specificato \const{O\_CREAT} e
-      \const{O\_EXCL} ma la coda già esiste.
-    \item[\errcode{EINVAL}] il file non supporta la funzione, o si è
+    \item[\errcode{EEXIST}] si è specificato \const{O\_CREAT} e
+      \const{O\_EXCL} ma la coda già esiste.
+    \item[\errcode{EINVAL}] il file non supporta la funzione, o si è
       specificato \const{O\_CREAT} con una valore non nullo di \param{attr} e
       valori non validi di \var{mq\_maxmsg} e \var{mq\_msgsize}.
-    \item[\errcode{ENOENT}] non si è specificato \const{O\_CREAT} ma la coda
+    \item[\errcode{ENOENT}] non si è specificato \const{O\_CREAT} ma la coda
       non esiste.
     \end{errlist}
     ed inoltre \errval{ENOMEM}, \errval{ENOSPC}, \errval{EFAULT},
@@ -3396,25 +3396,25 @@ La funzione apre la coda di messaggi identificata dall'argomento \param{name}
 restituendo il descrittore ad essa associato, del tutto analogo ad un file
 descriptor, con l'unica differenza che lo standard prevede un apposito tipo
 \type{mqd\_t}.\footnote{nel caso di Linux si tratta in effetti proprio di un
-  normale file descriptor; pertanto, anche se questo comportamento non è
-  portabile, lo si può tenere sotto osservazione con le funzioni dell'I/O
+  normale file descriptor; pertanto, anche se questo comportamento non è
+  portabile, lo si può tenere sotto osservazione con le funzioni dell'I/O
   multiplexing (vedi sez.~\ref{sec:file_multiplexing}) come possibile
   alternativa all'uso dell'interfaccia di notifica di \func{mq\_notify} (che
-  vedremo a breve).} Se la coda esiste già il descrittore farà riferimento
-allo stesso oggetto, consentendo così la comunicazione fra due processi
+  vedremo a breve).} Se la coda esiste già il descrittore farà riferimento
+allo stesso oggetto, consentendo così la comunicazione fra due processi
 diversi.
 
-La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
+La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
 possono essere specificati per \param{oflag}, che deve essere specificato come
 maschera binaria; i valori possibili per i vari bit sono quelli visti in
-tab.~\ref{tab:file_open_flags} dei quali però \func{mq\_open} riconosce solo i
+tab.~\ref{tab:file_open_flags} dei quali però \func{mq\_open} riconosce solo i
 seguenti:
 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
 \item[\const{O\_RDONLY}] Apre la coda solo per la ricezione di messaggi. Il
-  processo potrà usare il descrittore con \func{mq\_receive} ma non con
+  processo potrà usare il descrittore con \func{mq\_receive} ma non con
   \func{mq\_send}.
 \item[\const{O\_WRONLY}] Apre la coda solo per la trasmissione di messaggi. Il
-  processo potrà usare il descrittore con \func{mq\_send} ma non con
+  processo potrà usare il descrittore con \func{mq\_send} ma non con
   \func{mq\_receive}.
 \item[\const{O\_RDWR}] Apre la coda solo sia per la trasmissione che per la
   ricezione. 
@@ -3422,17 +3422,17 @@ seguenti:
   presenza di questo bit richiede la presenza degli ulteriori argomenti
   \param{mode} e \param{attr}.
 \item[\const{O\_EXCL}] Se usato insieme a \const{O\_CREAT} fa fallire la
-  chiamata se la coda esiste già, altrimenti esegue la creazione atomicamente.
-\item[\const{O\_NONBLOCK}] Imposta la coda in modalità non bloccante, le
+  chiamata se la coda esiste già, altrimenti esegue la creazione atomicamente.
+\item[\const{O\_NONBLOCK}] Imposta la coda in modalità non bloccante, le
   funzioni di ricezione e trasmissione non si bloccano quando non ci sono le
   risorse richieste, ma ritornano immediatamente con un errore di
   \errcode{EAGAIN}.
 \end{basedescript}
 
-I primi tre bit specificano la modalità di apertura della coda, e sono fra
-loro esclusivi. Ma qualunque sia la modalità in cui si è aperta una coda,
-questa potrà essere riaperta più volte in una modalità diversa, e vi si potrà
-sempre accedere attraverso descrittori diversi, esattamente come si può fare
+I primi tre bit specificano la modalità di apertura della coda, e sono fra
+loro esclusivi. Ma qualunque sia la modalità in cui si è aperta una coda,
+questa potrà essere riaperta più volte in una modalità diversa, e vi si potrà
+sempre accedere attraverso descrittori diversi, esattamente come si può fare
 per i file normali.
 
 Se la coda non esiste e la si vuole creare si deve specificare
@@ -3443,8 +3443,8 @@ creazione con l'argomento \param{mode};\footnote{fino al 2.6.14 per un bug i
 \func{open}, anche se per le code di messaggi han senso solo i permessi di
 lettura e scrittura. Oltre ai permessi di creazione possono essere specificati
 anche gli attributi specifici della coda tramite l'argomento \param{attr};
-quest'ultimo è un puntatore ad una apposita struttura \struct{mq\_attr}, la
-cui definizione è riportata in fig.~\ref{fig:ipc_mq_attr}.
+quest'ultimo è un puntatore ad una apposita struttura \struct{mq\_attr}, la
+cui definizione è riportata in fig.~\ref{fig:ipc_mq_attr}.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -3459,67 +3459,67 @@ cui definizione 
 
 Per la creazione della coda i campi della struttura che devono essere
 specificati sono \var{mq\_maxmsg} e \var{mq\_msgsize}, che indicano
-rispettivamente il numero massimo di messaggi che può contenere e la
-dimensione massima di un messaggio. Il valore dovrà essere positivo e minore
+rispettivamente il numero massimo di messaggi che può contenere e la
+dimensione massima di un messaggio. Il valore dovrà essere positivo e minore
 dei rispettivi limiti di sistema \const{MQ\_MAXMSG} e \const{MQ\_MSGSIZE},
-altrimenti la funzione fallirà con un errore di \errcode{EINVAL}.
-Se \param{attr} è un puntatore nullo gli attributi della coda saranno
+altrimenti la funzione fallirà con un errore di \errcode{EINVAL}.
+Se \param{attr} è un puntatore nullo gli attributi della coda saranno
 impostati ai valori predefiniti.
 
-Quando l'accesso alla coda non è più necessario si può chiudere il relativo
-descrittore con la funzione \funcd{mq\_close}, il cui prototipo è:
+Quando l'accesso alla coda non è più necessario si può chiudere il relativo
+descrittore con la funzione \funcd{mq\_close}, il cui prototipo è:
 \begin{prototype}{mqueue.h}
 {int mq\_close(mqd\_t mqdes)}
 
 Chiude la coda \param{mqdes}.
   
 \bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore;
-  nel quel caso \var{errno} assumerà i valori \errval{EBADF} o
+  nel quel caso \var{errno} assumerà i valori \errval{EBADF} o
   \errval{EINTR}.}
 \end{prototype}
 
-La funzione è analoga a \func{close},\footnote{in Linux, dove le code sono
-  implementate come file su un filesystem dedicato, è esattamente la stessa
-  funzione.} dopo la sua esecuzione il processo non sarà più in grado di usare
-il descrittore della coda, ma quest'ultima continuerà ad esistere nel sistema
-e potrà essere acceduta con un'altra chiamata a \func{mq\_open}. All'uscita di
-un processo tutte le code aperte, così come i file, vengono chiuse
+La funzione è analoga a \func{close},\footnote{in Linux, dove le code sono
+  implementate come file su un filesystem dedicato, è esattamente la stessa
+  funzione.} dopo la sua esecuzione il processo non sarà più in grado di usare
+il descrittore della coda, ma quest'ultima continuerà ad esistere nel sistema
+e potrà essere acceduta con un'altra chiamata a \func{mq\_open}. All'uscita di
+un processo tutte le code aperte, così come i file, vengono chiuse
 automaticamente. Inoltre se il processo aveva agganciato una richiesta di
-notifica sul descrittore che viene chiuso, questa sarà rilasciata e potrà
+notifica sul descrittore che viene chiuso, questa sarà rilasciata e potrà
 essere richiesta da qualche altro processo.
 
 
 Quando si vuole effettivamente rimuovere una coda dal sistema occorre usare la
-funzione \funcd{mq\_unlink}, il cui prototipo è:
+funzione \funcd{mq\_unlink}, il cui prototipo è:
 \begin{prototype}{mqueue.h}
 {int mq\_unlink(const char *name)}
 
 Rimuove una coda di messaggi.
   
 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-  errore; nel quel caso \var{errno} assumerà gli stessi valori riportati da
+  errore; nel quel caso \var{errno} assumerà gli stessi valori riportati da
   \func{unlink}.}
 \end{prototype}
 
-Anche in questo caso il comportamento della funzione è analogo a quello di
+Anche in questo caso il comportamento della funzione è analogo a quello di
 \func{unlink} per i file,\footnote{di nuovo l'implementazione di Linux usa
-  direttamente \func{unlink}.} la funzione rimuove la coda \param{name}, così
+  direttamente \func{unlink}.} la funzione rimuove la coda \param{name}, così
 che una successiva chiamata a \func{mq\_open} fallisce o crea una coda
 diversa. 
 
 Come per i file ogni coda di messaggi ha un contatore di riferimenti, per cui
 la coda non viene effettivamente rimossa dal sistema fin quando questo non si
 annulla. Pertanto anche dopo aver eseguito con successo \func{mq\_unlink} la
-coda resterà accessibile a tutti i processi che hanno un descrittore aperto su
+coda resterà accessibile a tutti i processi che hanno un descrittore aperto su
 di essa.  Allo stesso modo una coda ed i suoi contenuti resteranno disponibili
-all'interno del sistema anche quando quest'ultima non è aperta da nessun
-processo (questa è una delle differenze più rilevanti nei confronti di pipe e
-fifo).  La sola differenza fra code di messaggi POSIX e file normali è che,
+all'interno del sistema anche quando quest'ultima non è aperta da nessun
+processo (questa è una delle differenze più rilevanti nei confronti di pipe e
+fifo).  La sola differenza fra code di messaggi POSIX e file normali è che,
 essendo il filesystem delle code di messaggi virtuale e basato su oggetti
 interni al kernel, il suo contenuto viene perduto con il riavvio del sistema.
 
-Come accennato ad ogni coda di messaggi è associata una struttura
-\struct{mq\_attr}, che può essere letta e modificata attraverso le due
+Come accennato ad ogni coda di messaggi è associata una struttura
+\struct{mq\_attr}, che può essere letta e modificata attraverso le due
 funzioni \funcd{mq\_getattr} e \funcd{mq\_setattr}, i cui prototipi sono:
 \begin{functions}
   \headdecl{mqueue.h} 
@@ -3532,24 +3532,24 @@ funzioni \funcd{mq\_getattr} e \funcd{mq\_setattr}, i cui prototipi sono:
   Modifica gli attributi di una coda di messaggi POSIX.
   
   \bodydesc{Entrambe le funzioni restituiscono 0 in caso di successo e -1 in
-    caso di errore; nel quel caso \var{errno} assumerà i valori \errval{EBADF}
+    caso di errore; nel quel caso \var{errno} assumerà i valori \errval{EBADF}
     o \errval{EINVAL}.}
 \end{functions}
 
 La funzione \func{mq\_getattr} legge i valori correnti degli attributi della
 coda nella struttura puntata da \param{mqstat}; di questi l'unico relativo
-allo stato corrente della coda è \var{mq\_curmsgs} che indica il numero di
+allo stato corrente della coda è \var{mq\_curmsgs} che indica il numero di
 messaggi da essa contenuti, gli altri indicano le caratteristiche generali
 della stessa.
 
 La funzione \func{mq\_setattr} permette di modificare gli attributi di una
 coda tramite i valori contenuti nella struttura puntata da \param{mqstat}, ma
-può essere modificato solo il campo \var{mq\_flags}, gli altri campi vengono
+può essere modificato solo il campo \var{mq\_flags}, gli altri campi vengono
 ignorati. In particolare i valori di \var{mq\_maxmsg} e \var{mq\_msgsize}
 possono essere specificati solo in fase ci creazione della coda.  Inoltre i
 soli valori possibili per \var{mq\_flags} sono 0 e \const{O\_NONBLOCK}, per
-cui alla fine la funzione può essere utilizzata solo per abilitare o
-disabilitare la modalità non bloccante. L'argomento \param{omqstat} viene
+cui alla fine la funzione può essere utilizzata solo per abilitare o
+disabilitare la modalità non bloccante. L'argomento \param{omqstat} viene
 usato, quando diverso da \val{NULL}, per specificare l'indirizzo di una
 struttura su cui salvare i valori degli attributi precedenti alla chiamata
 della funzione.
@@ -3570,16 +3570,16 @@ Per inserire messaggi su di una coda sono previste due funzioni,
 
   
   \bodydesc{Le funzioni restituiscono 0 in caso di successo e $-1$ per un
-    errore; nel quel caso \var{errno} assumerà i valori:
+    errore; nel quel caso \var{errno} assumerà i valori:
     \begin{errlist}
-    \item[\errcode{EAGAIN}] si è aperta la coda con \const{O\_NONBLOCK}, e la
-      coda è piena.
+    \item[\errcode{EAGAIN}] si è aperta la coda con \const{O\_NONBLOCK}, e la
+      coda è piena.
     \item[\errcode{EMSGSIZE}] la lunghezza del messaggio \param{msg\_len}
       eccede il limite impostato per la coda.
-    \item[\errcode{EINVAL}] si è specificato un valore nullo per
+    \item[\errcode{EINVAL}] si è specificato un valore nullo per
       \param{msg\_len}, o un valore di \param{msg\_prio} fuori dai limiti, o
       un valore non valido per \param{abs\_timeout}.
-    \item[\errcode{ETIMEDOUT}] l'inserimento del messaggio non è stato
+    \item[\errcode{ETIMEDOUT}] l'inserimento del messaggio non è stato
       effettuato entro il tempo stabilito.
     \end{errlist}    
     ed inoltre \errval{EBADF}, \errval{ENOMEM} ed \errval{EINTR}.}
@@ -3590,24 +3590,24 @@ nell'argomento \param{msg\_ptr} e la relativa lunghezza in \param{msg\_len}.
 Se quest'ultima eccede la dimensione massima specificata da \var{mq\_msgsize}
 le funzioni ritornano immediatamente con un errore di \errcode{EMSGSIZE}.
 
-L'argomento \param{msg\_prio} indica la priorità dell'argomento; i messaggi di
-priorità maggiore vengono inseriti davanti a quelli di priorità inferiore (e
-quindi saranno riletti per primi). A parità del valore della priorità il
-messaggio sarà inserito in coda a tutti quelli con la stessa priorità. Il
-valore della priorità non può eccedere il limite di sistema
-\const{MQ\_PRIO\_MAX}, che nel caso è pari a 32768.
+L'argomento \param{msg\_prio} indica la priorità dell'argomento; i messaggi di
+priorità maggiore vengono inseriti davanti a quelli di priorità inferiore (e
+quindi saranno riletti per primi). A parità del valore della priorità il
+messaggio sarà inserito in coda a tutti quelli con la stessa priorità. Il
+valore della priorità non può eccedere il limite di sistema
+\const{MQ\_PRIO\_MAX}, che nel caso è pari a 32768.
 
 Qualora la coda sia piena, entrambe le funzioni si bloccano, a meno che non
-sia stata selezionata in fase di apertura la modalità non
+sia stata selezionata in fase di apertura la modalità non
 bloccante,\footnote{o si sia impostato il flag \const{O\_NONBLOCK} sul file
   descriptor della coda.} nel qual caso entrambe ritornano \errcode{EAGAIN}.
-La sola differenza fra le due funzioni è che la seconda, passato il tempo
+La sola differenza fra le due funzioni è che la seconda, passato il tempo
 massimo impostato con l'argomento \param{abs\_timeout},\footnote{deve essere
   specificato un tempo assoluto tramite una struttura \struct{timespec} (vedi
   fig.~\ref{fig:sys_timespec_struct}) indicato in numero di secondi e
   nanosecondi a partire dal 1 gennaio 1970.} ritorna comunque con un errore di
-\errcode{ETIMEDOUT}, se invece il tempo è già scaduto al momento della
-chiamata e la coda è vuota la funzione ritorna immediatamente.
+\errcode{ETIMEDOUT}, se invece il tempo è già scaduto al momento della
+chiamata e la coda è vuota la funzione ritorna immediatamente.
 
 Come per l'inserimento, anche per l'estrazione dei messaggi da una coda sono
 previste due funzioni, \funcd{mq\_receive} e \funcd{mq\_timedreceive}, i cui
@@ -3625,106 +3625,106 @@ prototipi sono:
   \param{abs\_timeout}.
   
   \bodydesc{Le funzioni restituiscono il numero di byte del messaggio in caso
-    di successo e -1 in caso di errore; nel quel caso \var{errno} assumerà i
+    di successo e -1 in caso di errore; nel quel caso \var{errno} assumerà i
     valori:
     \begin{errlist}
-    \item[\errcode{EAGAIN}] si è aperta la coda con \const{O\_NONBLOCK}, e la
-      coda è vuota.
+    \item[\errcode{EAGAIN}] si è aperta la coda con \const{O\_NONBLOCK}, e la
+      coda è vuota.
     \item[\errcode{EMSGSIZE}] la lunghezza del messaggio sulla coda eccede il
       valore \param{msg\_len} specificato per la ricezione.
-    \item[\errcode{EINVAL}] si è specificato un valore nullo per
+    \item[\errcode{EINVAL}] si è specificato un valore nullo per
       \param{msg\_ptr}, o un valore non valido per \param{abs\_timeout}.
-    \item[\errcode{ETIMEDOUT}] la ricezione del messaggio non è stata
+    \item[\errcode{ETIMEDOUT}] la ricezione del messaggio non è stata
       effettuata entro il tempo stabilito.
     \end{errlist}    
     ed inoltre \errval{EBADF}, \errval{EINTR}, \errval{ENOMEM}, o
     \errval{EINVAL}.}
 \end{functions}
 
-La funzione estrae dalla coda il messaggio a priorità più alta, o il più
-vecchio fra quelli della stessa priorità. Una volta ricevuto il messaggio
+La funzione estrae dalla coda il messaggio a priorità più alta, o il più
+vecchio fra quelli della stessa priorità. Una volta ricevuto il messaggio
 viene tolto dalla coda e la sua dimensione viene restituita come valore di
-ritorno.\footnote{si tenga presente che 0 è una dimensione valida e che la
-  condizione di errore è restituita dal valore -1; Stevens in \cite{UNP2} fa
-  notare che questo è uno dei casi in cui vale ciò che lo standard
+ritorno.\footnote{si tenga presente che 0 è una dimensione valida e che la
+  condizione di errore è restituita dal valore -1; Stevens in \cite{UNP2} fa
+  notare che questo è uno dei casi in cui vale ciò che lo standard
   \textsl{non} dice, una dimensione nulla infatti, pur non essendo citata, non
   viene proibita.}
 
-Se la dimensione specificata da \param{msg\_len} non è sufficiente a contenere
+Se la dimensione specificata da \param{msg\_len} non è sufficiente a contenere
 il messaggio, entrambe le funzioni, al contrario di quanto avveniva nelle code
 di messaggi di SysV, ritornano un errore di \errcode{EMSGSIZE} senza estrarre
-il messaggio.  È pertanto opportuno eseguire sempre una chiamata a
+il messaggio.  È pertanto opportuno eseguire sempre una chiamata a
 \func{mq\_getaddr} prima di eseguire una ricezione, in modo da ottenere la
 dimensione massima dei messaggi sulla coda, per poter essere in grado di
 allocare dei buffer sufficientemente ampi per la lettura.
 
 Se si specifica un puntatore per l'argomento \param{msg\_prio} il valore della
-priorità del messaggio viene memorizzato all'indirizzo da esso indicato.
-Qualora non interessi usare la priorità dei messaggi si può specificare
-\var{NULL}, ed usare un valore nullo della priorità nelle chiamate a
+priorità del messaggio viene memorizzato all'indirizzo da esso indicato.
+Qualora non interessi usare la priorità dei messaggi si può specificare
+\var{NULL}, ed usare un valore nullo della priorità nelle chiamate a
 \func{mq\_send}.
 
-Si noti che con le code di messaggi POSIX non si ha la possibilità di
-selezionare quale messaggio estrarre con delle condizioni sulla priorità, a
+Si noti che con le code di messaggi POSIX non si ha la possibilità di
+selezionare quale messaggio estrarre con delle condizioni sulla priorità, a
 differenza di quanto avveniva con le code di messaggi di SysV che permettono
 invece la selezione in base al valore del campo \var{mtype}. 
 
 % TODO inserire i dati di /proc/sys/fs/mqueue 
 
 Qualora la coda sia vuota entrambe le funzioni si bloccano, a meno che non si
-sia selezionata la modalità non bloccante; in tal caso entrambe ritornano
+sia selezionata la modalità non bloccante; in tal caso entrambe ritornano
 immediatamente con l'errore \errcode{EAGAIN}. Anche in questo caso la sola
-differenza fra le due funzioni è che la seconda non attende indefinitamente e
+differenza fra le due funzioni è che la seconda non attende indefinitamente e
 passato il tempo massimo \param{abs\_timeout} ritorna comunque con un errore
 di \errcode{ETIMEDOUT}.
 
 Uno dei problemi sottolineati da Stevens in \cite{UNP2}, comuni ad entrambe le
-tipologie di code messaggi, è che non è possibile per chi riceve identificare
-chi è che ha inviato il messaggio, in particolare non è possibile sapere da
+tipologie di code messaggi, è che non è possibile per chi riceve identificare
+chi è che ha inviato il messaggio, in particolare non è possibile sapere da
 quale utente esso provenga. Infatti, in mancanza di un meccanismo interno al
 kernel, anche se si possono inserire delle informazioni nel messaggio, queste
 non possono essere credute, essendo completamente dipendenti da chi lo invia.
-Vedremo però come, attraverso l'uso del meccanismo di notifica, sia possibile
+Vedremo però come, attraverso l'uso del meccanismo di notifica, sia possibile
 superare in parte questo problema.
 
-Una caratteristica specifica delle code di messaggi POSIX è la possibilità di
-usufruire di un meccanismo di notifica asincrono; questo può essere attivato
-usando la funzione \funcd{mq\_notify}, il cui prototipo è:
+Una caratteristica specifica delle code di messaggi POSIX è la possibilità di
+usufruire di un meccanismo di notifica asincrono; questo può essere attivato
+usando la funzione \funcd{mq\_notify}, il cui prototipo è:
 \begin{prototype}{mqueue.h}
 {int mq\_notify(mqd\_t mqdes, const struct sigevent *notification)}
 
 Attiva il meccanismo di notifica per la coda \param{mqdes}.
   
 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-  errore; nel quel caso \var{errno} assumerà i valori: 
+  errore; nel quel caso \var{errno} assumerà i valori: 
     \begin{errlist}
-    \item[\errcode{EBUSY}] c'è già un processo registrato per la notifica.
+    \item[\errcode{EBUSY}] c'è già un processo registrato per la notifica.
     \item[\errcode{EBADF}] il descrittore non fa riferimento ad una coda di
       messaggi.
     \end{errlist}}
 \end{prototype}
 
 Il meccanismo di notifica permette di segnalare in maniera asincrona ad un
-processo la presenza di dati sulla coda, in modo da evitare la necessità di
+processo la presenza di dati sulla coda, in modo da evitare la necessità di
 bloccarsi nell'attesa. Per far questo un processo deve registrarsi con la
-funzione \func{mq\_notify}, ed il meccanismo è disponibile per un solo
+funzione \func{mq\_notify}, ed il meccanismo è disponibile per un solo
 processo alla volta per ciascuna coda.
 
 Il comportamento di \func{mq\_notify} dipende dal valore dell'argomento
-\param{notification}, che è un puntatore ad una apposita struttura
+\param{notification}, che è un puntatore ad una apposita struttura
 \struct{sigevent}, (definita in fig.~\ref{fig:struct_sigevent}) introdotta
 dallo standard POSIX.1b per gestire la notifica di eventi; per altri dettagli
-si può vedere quanto detto in sez.~\ref{sec:sig_timer_adv} a proposito
+si può vedere quanto detto in sez.~\ref{sec:sig_timer_adv} a proposito
 dell'uso della stessa struttura per la notifica delle scadenze dei
 \textit{timer}.
 
-Attraverso questa struttura si possono impostare le modalità con cui viene
-effettuata la notifica nel campo \var{sigev\_notify}, che può assumere i
+Attraverso questa struttura si possono impostare le modalità con cui viene
+effettuata la notifica nel campo \var{sigev\_notify}, che può assumere i
 valori di tab.~\ref{tab:sigevent_sigev_notify}.\footnote{la pagina di manuale
   riporta soltanto i primi tre (inizialmente era possibile solo
-  \const{SIGEV\_SIGNAL}).} Il metodo consigliato è quello di usare
+  \const{SIGEV\_SIGNAL}).} Il metodo consigliato è quello di usare
 \const{SIGEV\_SIGNAL} usando il campo \var{sigev\_signo} per indicare il quale
-segnale deve essere inviato al processo. Inoltre il campo \var{sigev\_value} è
+segnale deve essere inviato al processo. Inoltre il campo \var{sigev\_value} è
 un puntatore ad una struttura \struct{sigval\_t} (definita in
 fig.~\ref{fig:sig_sigval}) che permette di restituire al gestore del segnale
 un valore numerico o un indirizzo,\footnote{per il suo uso si riveda la
@@ -3734,17 +3734,17 @@ vista in sez.~\ref{sec:sig_sigaction}.
 
 La funzione registra il processo chiamante per la notifica se
 \param{notification} punta ad una struttura \struct{sigevent} opportunamente
-inizializzata, o cancella una precedente registrazione se è \val{NULL}. Dato
-che un solo processo alla volta può essere registrato, la funzione fallisce
-con \errcode{EBUSY} se c'è un altro processo già registrato.\footnote{questo
+inizializzata, o cancella una precedente registrazione se è \val{NULL}. Dato
+che un solo processo alla volta può essere registrato, la funzione fallisce
+con \errcode{EBUSY} se c'è un altro processo già registrato.\footnote{questo
   significa anche che se si registra una notifica con \const{SIGEV\_NONE} il
-  processo non la riceverà, ma impedirà anche che altri possano registrarsi
+  processo non la riceverà, ma impedirà anche che altri possano registrarsi
   per poterlo fare.}  Si tenga presente inoltre che alla chiusura del
 descrittore associato alla coda (e quindi anche all'uscita del processo) ogni
 eventuale registrazione di notifica presente viene cancellata.
 
 La notifica del segnale avviene all'arrivo di un messaggio in una coda vuota
-(cioè solo se sulla coda non ci sono messaggi) e se non c'è nessun processo
+(cioè solo se sulla coda non ci sono messaggi) e se non c'è nessun processo
 bloccato in una chiamata a \func{mq\_receive}, in questo caso infatti il
 processo bloccato ha la precedenza ed il messaggio gli viene immediatamente
 inviato, mentre per il meccanismo di notifica tutto funziona come se la coda
@@ -3756,10 +3756,10 @@ la coda diventa disponibile per una ulteriore registrazione.  Questo comporta
 che se si vuole mantenere il meccanismo di notifica occorre ripetere la
 registrazione chiamando nuovamente \func{mq\_notify} all'interno del gestore
 del segnale di notifica. A differenza della situazione simile che si aveva con
-i segnali non affidabili,\footnote{l'argomento è stato affrontato in
+i segnali non affidabili,\footnote{l'argomento è stato affrontato in
   \ref{sec:sig_semantics}.} questa caratteristica non configura una
-\itindex{race~condition} \textit{race condition} perché l'invio di un segnale
-avviene solo se la coda è vuota; pertanto se si vuole evitare di correre il
+\itindex{race~condition} \textit{race condition} perché l'invio di un segnale
+avviene solo se la coda è vuota; pertanto se si vuole evitare di correre il
 rischio di perdere eventuali ulteriori segnali inviati nel lasso di tempo che
 occorre per ripetere la richiesta di notifica basta avere cura di eseguire
 questa operazione prima di estrarre i messaggi presenti dalla coda.
@@ -3770,7 +3770,7 @@ fig.~\ref{fig:sig_siginfo_t}). In particolare \var{si\_pid} viene impostato al
 valore del \acr{pid} del processo che ha emesso il segnale, \var{si\_uid}
 all'userid effettivo, \var{si\_code} a \const{SI\_MESGQ}, e \var{si\_errno} a
 0. Questo ci dice che, se si effettua la ricezione dei messaggi usando
-esclusivamente il meccanismo di notifica, è possibile ottenere le informazioni
+esclusivamente il meccanismo di notifica, è possibile ottenere le informazioni
 sul processo che ha inserito un messaggio usando un gestore per il segnale in
 forma estesa.\footnote{di nuovo si faccia riferimento a quanto detto al
   proposito in sez.~\ref{sec:sig_sigaction} e sez.~\ref{sec:sig_real_time}.}
@@ -3780,21 +3780,21 @@ forma estesa.\footnote{di nuovo si faccia riferimento a quanto detto al
 \subsection{Memoria condivisa}
 \label{sec:ipc_posix_shm}
 
-La memoria condivisa è stato il primo degli oggetti di IPC POSIX inserito nel
-kernel ufficiale; il supporto a questo tipo di oggetti è realizzato attraverso
+La memoria condivisa è stato il primo degli oggetti di IPC POSIX inserito nel
+kernel ufficiale; il supporto a questo tipo di oggetti è realizzato attraverso
 il filesystem \texttt{tmpfs}, uno speciale filesystem che mantiene tutti i
 suoi contenuti in memoria, che viene attivato abilitando l'opzione
 \texttt{CONFIG\_TMPFS} in fase di compilazione del kernel.
 
 Per potere utilizzare l'interfaccia POSIX per la memoria condivisa le
 \acr{glibc}\footnote{le funzioni sono state introdotte con le glibc-2.2.}
-richiedono di compilare i programmi con l'opzione \code{-lrt}; inoltre è
+richiedono di compilare i programmi con l'opzione \code{-lrt}; inoltre è
 necessario che in \file{/dev/shm} sia montato un filesystem \texttt{tmpfs};
 questo di norma viene fatto aggiungendo una riga del tipo di:
 \begin{verbatim}
 tmpfs   /dev/shm        tmpfs   defaults        0      0
 \end{verbatim}
-ad \conffile{/etc/fstab}. In realtà si può montare un filesystem \texttt{tmpfs}
+ad \conffile{/etc/fstab}. In realtà si può montare un filesystem \texttt{tmpfs}
 dove si vuole, per usarlo come RAM disk, con un comando del tipo:
 \begin{verbatim}
 mount -t tmpfs -o size=128M,nr_inodes=10k,mode=700 tmpfs /mytmpfs
@@ -3802,13 +3802,13 @@ mount -t tmpfs -o size=128M,nr_inodes=10k,mode=700 tmpfs /mytmpfs
 
 Il filesystem riconosce, oltre quelle mostrate, le opzioni \texttt{uid} e
 \texttt{gid} che identificano rispettivamente utente e gruppo cui assegnarne
-la titolarità, e \texttt{nr\_blocks} che permette di specificarne la
-dimensione in blocchi, cioè in multipli di \const{PAGECACHE\_SIZE} che in
-questo caso è l'unità di allocazione elementare.
+la titolarità, e \texttt{nr\_blocks} che permette di specificarne la
+dimensione in blocchi, cioè in multipli di \const{PAGECACHE\_SIZE} che in
+questo caso è l'unità di allocazione elementare.
 
 La funzione che permette di aprire un segmento di memoria condivisa POSIX, ed
-eventualmente di crearlo se non esiste ancora, è \funcd{shm\_open}; il suo
-prototipo è:
+eventualmente di crearlo se non esiste ancora, è \funcd{shm\_open}; il suo
+prototipo è:
 \begin{functions}
   \headdecl{sys/mman.h} 
   \headdecl{sys/stat.h} 
@@ -3819,25 +3819,25 @@ prototipo 
   Apre un segmento di memoria condivisa.
   
   \bodydesc{La funzione restituisce un file descriptor positivo in caso di
-    successo e -1 in caso di errore; nel quel caso \var{errno} assumerà gli
+    successo e -1 in caso di errore; nel quel caso \var{errno} assumerà gli
     stessi valori riportati da \func{open}.}
 \end{functions}
 
 La funzione apre un segmento di memoria condivisa identificato dal nome
-\param{name}. Come già spiegato in sez.~\ref{sec:ipc_posix_generic} questo
-nome può essere specificato in forma standard solo facendolo iniziare per
+\param{name}. Come già spiegato in sez.~\ref{sec:ipc_posix_generic} questo
+nome può essere specificato in forma standard solo facendolo iniziare per
 ``\file{/}'' e senza ulteriori ``\file{/}''. Linux supporta comunque nomi
 generici, che verranno interpretati prendendo come radice
 \file{/dev/shm}.\footnote{occorre pertanto evitare di specificare qualcosa del
-  tipo \file{/dev/shm/nome} all'interno di \param{name}, perché questo
+  tipo \file{/dev/shm/nome} all'interno di \param{name}, perché questo
   comporta, da parte delle funzioni di libreria, il tentativo di accedere a
   \file{/dev/shm/dev/shm/nome}.}
 
-La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
+La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
 possono essere specificati per \param{oflag}, che deve essere specificato come
 maschera binaria comprendente almeno uno dei due valori \const{O\_RDONLY} e
 \const{O\_RDWR}; i valori possibili per i vari bit sono quelli visti in
-tab.~\ref{tab:file_open_flags} dei quali però \func{shm\_open} riconosce solo
+tab.~\ref{tab:file_open_flags} dei quali però \func{shm\_open} riconosce solo
 i seguenti:
 \begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
 \item[\const{O\_RDONLY}] Apre il file descriptor associato al segmento di
@@ -3847,54 +3847,54 @@ i seguenti:
 \item[\const{O\_CREAT}] Necessario qualora si debba creare il segmento di
   memoria condivisa se esso non esiste; in questo caso viene usato il valore
   di \param{mode} per impostare i permessi, che devono essere compatibili con
-  le modalità con cui si è aperto il file.
+  le modalità con cui si è aperto il file.
 \item[\const{O\_EXCL}] Se usato insieme a \const{O\_CREAT} fa fallire la
-  chiamata a \func{shm\_open} se il segmento esiste già, altrimenti esegue la
+  chiamata a \func{shm\_open} se il segmento esiste già, altrimenti esegue la
   creazione atomicamente.
-\item[\const{O\_TRUNC}] Se il segmento di memoria condivisa esiste già, ne
+\item[\const{O\_TRUNC}] Se il segmento di memoria condivisa esiste già, ne
   tronca le dimensioni a 0 byte.
 \end{basedescript}
 
 In caso di successo la funzione restituisce un file descriptor associato al
-segmento di memoria condiviso con le stesse modalità di
-\func{open}\footnote{in realtà, come accennato, \func{shm\_open} è un semplice
+segmento di memoria condiviso con le stesse modalità di
+\func{open}\footnote{in realtà, come accennato, \func{shm\_open} è un semplice
   wrapper per \func{open}, usare direttamente quest'ultima avrebbe lo stesso
   effetto.}  viste in sez.~\ref{sec:file_open}; in particolare viene impostato
 il flag \const{FD\_CLOEXEC}.  Chiamate effettuate da diversi processi usando
 lo stesso nome, restituiranno file descriptor associati allo stesso segmento
-(così come, nel caso di file di dati, essi sono associati allo stesso
-\index{inode} inode).  In questo modo è possibile effettuare una chiamata ad
+(così come, nel caso di file di dati, essi sono associati allo stesso
+\index{inode} inode).  In questo modo è possibile effettuare una chiamata ad
 \func{mmap} sul file descriptor restituito da \func{shm\_open} ed i processi
 vedranno lo stesso segmento di memoria condivisa.
 
-Quando il nome non esiste il segmento può essere creato specificando
-\const{O\_CREAT}; in tal caso il segmento avrà (così come i nuovi file)
-lunghezza nulla. Dato che un segmento di lunghezza nulla è di scarsa utilità,
+Quando il nome non esiste il segmento può essere creato specificando
+\const{O\_CREAT}; in tal caso il segmento avrà (così come i nuovi file)
+lunghezza nulla. Dato che un segmento di lunghezza nulla è di scarsa utilità,
 per impostarne la dimensione si deve usare \func{ftruncate} (vedi
 sez.~\ref{sec:file_file_size}), prima di mapparlo in memoria con \func{mmap}.
-Si tenga presente che una volta chiamata \func{mmap} si può chiudere il file
+Si tenga presente che una volta chiamata \func{mmap} si può chiudere il file
 descriptor (con \func{close}), senza che la mappatura ne risenta.
 
 Come per i file, quando si vuole effettivamente rimuovere segmento di memoria
-condivisa, occorre usare la funzione \funcd{shm\_unlink}, il cui prototipo è:
+condivisa, occorre usare la funzione \funcd{shm\_unlink}, il cui prototipo è:
 \begin{prototype}{sys/mman.h}
 {int shm\_unlink(const char *name)}
 
 Rimuove un segmento di memoria condivisa.
   
 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-  errore; nel quel caso \var{errno} assumerà gli stessi valori riportati da
+  errore; nel quel caso \var{errno} assumerà gli stessi valori riportati da
   \func{unlink}.}
 \end{prototype}
 
-La funzione è del tutto analoga ad \func{unlink}, e si limita a cancellare il
-nome del segmento da \file{/dev/shm}, senza nessun effetto né sui file
-descriptor precedentemente aperti con \func{shm\_open}, né sui segmenti già
+La funzione è del tutto analoga ad \func{unlink}, e si limita a cancellare il
+nome del segmento da \file{/dev/shm}, senza nessun effetto né sui file
+descriptor precedentemente aperti con \func{shm\_open}, né sui segmenti già
 mappati in memoria; questi verranno cancellati automaticamente dal sistema
 solo con le rispettive chiamate a \func{close} e \func{munmap}.  Una volta
-eseguita questa funzione però, qualora si richieda l'apertura di un segmento
-con lo stesso nome, la chiamata a \func{shm\_open} fallirà, a meno di non aver
-usato \const{O\_CREAT}, in quest'ultimo caso comunque si otterrà un file
+eseguita questa funzione però, qualora si richieda l'apertura di un segmento
+con lo stesso nome, la chiamata a \func{shm\_open} fallirà, a meno di non aver
+usato \const{O\_CREAT}, in quest'ultimo caso comunque si otterrà un file
 descriptor che fa riferimento ad un segmento distinto da eventuali precedenti.
 
 \begin{figure}[!htb]
@@ -3908,13 +3908,13 @@ descriptor che fa riferimento ad un segmento distinto da eventuali precedenti.
   \label{fig:ipc_posix_shmmem}
 \end{figure}
 
-Come esempio per l'uso di queste funzioni vediamo come è possibile riscrivere
+Come esempio per l'uso di queste funzioni vediamo come è possibile riscrivere
 una interfaccia semplificata analoga a quella vista in
 fig.~\ref{fig:ipc_sysv_shm_func} per la memoria condivisa in stile SysV. Il
-codice, riportato in fig.~\ref{fig:ipc_posix_shmmem}, è sempre contenuto nel
+codice, riportato in fig.~\ref{fig:ipc_posix_shmmem}, è sempre contenuto nel
 file \file{SharedMem.c} dei sorgenti allegati.
 
-La prima funzione (\texttt{\small 1--24}) è \func{CreateShm} che, dato un nome
+La prima funzione (\texttt{\small 1--24}) è \func{CreateShm} che, dato un nome
 nell'argomento \var{name} crea un nuovo segmento di memoria condivisa,
 accessibile in lettura e scrittura, e ne restituisce l'indirizzo. Anzitutto si
 definiscono (\texttt{\small 8}) i flag per la successiva (\texttt{\small 9})
@@ -3926,27 +3926,27 @@ prosegue impostando (\texttt{\small 14}) la dimensione del segmento con
 \func{ftruncate}. Di nuovo (\texttt{\small 15--16}) si esce immediatamente
 restituendo un puntatore nullo in caso di errore. Poi si passa (\texttt{\small
   18}) a mappare in memoria il segmento con \func{mmap} specificando dei
-diritti di accesso corrispondenti alla modalità di apertura.  Di nuovo si
+diritti di accesso corrispondenti alla modalità di apertura.  Di nuovo si
 restituisce (\texttt{\small 19--21}) un puntatore nullo in caso di errore,
 altrimenti si inizializza (\texttt{\small 22}) il contenuto del segmento al
 valore specificato dall'argomento \var{fill} con \func{memset}, e se ne
 restituisce (\texttt{\small 23}) l'indirizzo.
 
-La seconda funzione (\texttt{\small 25--40}) è \func{FindShm} che trova un
-segmento di memoria condiviso già esistente, restituendone l'indirizzo. In
+La seconda funzione (\texttt{\small 25--40}) è \func{FindShm} che trova un
+segmento di memoria condiviso già esistente, restituendone l'indirizzo. In
 questo caso si apre (\texttt{\small 31}) il segmento con \func{shm\_open}
-richiedendo che il segmento sia già esistente, in caso di errore
+richiedendo che il segmento sia già esistente, in caso di errore
 (\texttt{\small 31--33}) si ritorna immediatamente un puntatore nullo.
 Ottenuto il file descriptor del segmento lo si mappa (\texttt{\small 35}) in
 memoria con \func{mmap}, restituendo (\texttt{\small 36--38}) un puntatore
 nullo in caso di errore, o l'indirizzo (\texttt{\small 39}) dello stesso in
 caso di successo.
 
-La terza funzione (\texttt{\small 40--45}) è \func{RemoveShm}, e serve a
+La terza funzione (\texttt{\small 40--45}) è \func{RemoveShm}, e serve a
 cancellare un segmento di memoria condivisa. Dato che al contrario di quanto
 avveniva con i segmenti del SysV IPC gli oggetti allocati nel kernel vengono
-rilasciati automaticamente quando nessuna li usa più, tutto quello che c'è da
-fare (\texttt{\small 44}) in questo caso è chiamare \func{shm\_unlink},
+rilasciati automaticamente quando nessuna li usa più, tutto quello che c'è da
+fare (\texttt{\small 44}) in questo caso è chiamare \func{shm\_unlink},
 restituendo al chiamante il valore di ritorno.
 
 
@@ -3964,25 +3964,25 @@ dei semafori POSIX che li realizzava solo a livello di \itindex{thread}
 estensioni \textit{real-time} delle \acr{glibc}.\footnote{quelle che si
   accedono collegandosi alla libreria \texttt{librt}.} Esisteva inoltre una
 libreria che realizzava (parzialmente) l'interfaccia POSIX usando le funzioni
-dei semafori di SysV IPC (mantenendo così tutti i problemi sottolineati in
+dei semafori di SysV IPC (mantenendo così tutti i problemi sottolineati in
 sez.~\ref{sec:ipc_sysv_sem}).
 
-A partire dal kernel 2.5.7 è stato introdotto un meccanismo di
+A partire dal kernel 2.5.7 è stato introdotto un meccanismo di
 sincronizzazione completamente nuovo, basato sui cosiddetti
 \textit{futex},\footnote{la sigla sta per \textit{fast user mode mutex}.} con
-il quale è stato possibile implementare una versione nativa dei semafori
+il quale è stato possibile implementare una versione nativa dei semafori
 POSIX.  Grazie a questo con i kernel della serie 2.6 e le nuove versioni delle
 \acr{glibc} che usano questa nuova infrastruttura per quella che viene quella
 che viene chiamata \textit{New Posix Thread Library}, sono state implementate
 anche tutte le funzioni dell'interfaccia dei semafori POSIX.
 
-Anche in questo caso è necessario appoggiarsi alla libreria per le estensioni
+Anche in questo caso è necessario appoggiarsi alla libreria per le estensioni
 \textit{real-time} \texttt{librt}, questo significa che se si vuole utilizzare
 questa interfaccia, oltre ad utilizzare gli opportuni file di definizione,
-occorrerà compilare i programmi con l'opzione \texttt{-lrt}. 
+occorrerà compilare i programmi con l'opzione \texttt{-lrt}. 
 
 La funzione che permette di creare un nuovo semaforo POSIX, creando il
-relativo file, o di accedere ad uno esistente, è \funcd{sem\_open}, questa
+relativo file, o di accedere ad uno esistente, è \funcd{sem\_open}, questa
 prevede due forme diverse a seconda che sia utilizzata per aprire un semaforo
 esistente o per crearne uno nuovi, i relativi prototipi sono:
 \begin{functions}
@@ -3997,7 +3997,7 @@ esistente o per crearne uno nuovi, i relativi prototipi sono:
   
   \bodydesc{La funzione restituisce l'indirizzo del semaforo in caso di
     successo e \const{SEM\_FAILED} in caso di errore; nel quel caso
-    \var{errno} assumerà i valori:
+    \var{errno} assumerà i valori:
     \begin{errlist}
     \item[\errcode{EACCESS}] il semaforo esiste ma non si hanno permessi
       sufficienti per accedervi.
@@ -4005,25 +4005,25 @@ esistente o per crearne uno nuovi, i relativi prototipi sono:
       \const{O\_EXCL} ma il semaforo esiste.
     \item[\errcode{EINVAL}] il valore di \param{value} eccede
       \const{SEM\_VALUE\_MAX}.
-    \item[\errcode{ENAMETOOLONG}] si è utilizzato un nome troppo lungo.
-    \item[\errcode{ENOENT}] non si è usato \const{O\_CREAT} ed il nome
+    \item[\errcode{ENAMETOOLONG}] si è utilizzato un nome troppo lungo.
+    \item[\errcode{ENOENT}] non si è usato \const{O\_CREAT} ed il nome
       specificato non esiste.
     \end{errlist}    
     ed inoltre \errval{ENFILE} ed \errval{ENOMEM}.}
 \end{functions}
 
 L'argomento \param{name} definisce il nome del semaforo che si vuole
-utilizzare, ed è quello che permette a processi diversi di accedere allo
+utilizzare, ed è quello che permette a processi diversi di accedere allo
 stesso semaforo. Questo deve essere specificato con un pathname nella forma
 \texttt{/qualchenome}, che non ha una corrispondenza diretta con un pathname
 reale; con Linux infatti i file associati ai semafori sono mantenuti nel
 filesystem virtuale \texttt{/dev/shm}, e gli viene assegnato automaticamente
-un nome nella forma \texttt{sem.qualchenome}.\footnote{si ha cioè una
+un nome nella forma \texttt{sem.qualchenome}.\footnote{si ha cioè una
   corrispondenza per cui \texttt{/qualchenome} viene rimappato, nella
   creazione tramite \func{sem\_open}, su \texttt{/dev/shm/sem.qualchenome}.}
 
-L'argomento \param{oflag} è quello che controlla le modalità con cui opera la
-funzione, ed è passato come maschera binaria; i bit corrispondono a quelli
+L'argomento \param{oflag} è quello che controlla le modalità con cui opera la
+funzione, ed è passato come maschera binaria; i bit corrispondono a quelli
 utilizzati per l'analogo argomento di \func{open}, anche se dei possibili
 valori visti in sez.~\ref{sec:file_open} sono utilizzati soltanto
 \const{O\_CREAT} e \const{O\_EXCL}.
@@ -4031,20 +4031,20 @@ valori visti in sez.~\ref{sec:file_open} sono utilizzati soltanto
 Se si usa \const{O\_CREAT} si richiede la creazione del semaforo qualora
 questo non esista, ed in tal caso occorre utilizzare la seconda forma della
 funzione, in cui si devono specificare sia un valore iniziale con l'argomento
-\param{value},\footnote{e si noti come così diventa possibile, differenza di
+\param{value},\footnote{e si noti come così diventa possibile, differenza di
   quanto avviene per i semafori del \textit{SysV IPC}, effettuare in maniera
   atomica creazione ed inizializzazione di un semaforo usando una unica
   funzione.} che una maschera dei permessi con l'argomento
 \param{mode};\footnote{anche questo argomento prende gli stessi valori
   utilizzati per l'analogo di \func{open}, che si sono illustrati in dettaglio
   sez.~\ref{sec:file_perm_overview}.} questi verranno assegnati al semaforo
-appena creato. Se il semaforo esiste già i suddetti valori saranno invece
+appena creato. Se il semaforo esiste già i suddetti valori saranno invece
 ignorati. Usando il flag \const{O\_EXCL} si richiede invece la verifica che il
 semaforo non esiste, usandolo insieme ad \const{O\_CREAT} la funzione fallisce
-qualora un semaforo con lo stesso nome sia già presente.
+qualora un semaforo con lo stesso nome sia già presente.
 
 La funzione restituisce in caso di successo un puntatore all'indirizzo del
-semaforo con un valore di tipo \ctyp{sem\_t *}, è questo valore che dovrà
+semaforo con un valore di tipo \ctyp{sem\_t *}, è questo valore che dovrà
 essere passato alle altre funzioni per operare sul semaforo stesso. Si tenga
 presente che, come accennato in sez.~\ref{sec:ipc_posix_generic}, i semafori
 usano la semantica standard dei file per quanto riguarda i controlli di
@@ -4053,16 +4053,16 @@ accesso.
 Questo significa che un nuovo semaforo viene sempre creato con l'user-ID ed il
 group-ID effettivo del processo chiamante, e che i permessi indicati con
 \param{mode} vengono filtrati dal valore della \itindex{umask} \textit{umask}
-del processo.  Inoltre per poter aprire un semaforo è necessario avere su di
+del processo.  Inoltre per poter aprire un semaforo è necessario avere su di
 esso sia il permesso di lettura che quello di scrittura.
 
-Una volta che si sia ottenuto l'indirizzo di un semaforo, sarà possibile
+Una volta che si sia ottenuto l'indirizzo di un semaforo, sarà possibile
 utilizzarlo; se si ricorda quanto detto all'inizio di
 sez.~\ref{sec:ipc_sysv_sem}, dove si sono introdotti i concetti generali
 relativi ai semafori, le operazioni principali sono due, quella che richiede
 l'uso di una risorsa bloccando il semaforo e quella che rilascia la risorsa
-liberando il semaforo. La prima operazione è effettuata dalla funzione
-\funcd{sem\_wait}, il cui prototipo è:
+liberando il semaforo. La prima operazione è effettuata dalla funzione
+\funcd{sem\_wait}, il cui prototipo è:
 \begin{functions}
   \headdecl{semaphore.h} 
   
@@ -4071,9 +4071,9 @@ liberando il semaforo. La prima operazione 
   Blocca il semaforo \param{sem}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore; nel quel caso \var{errno} assumerà i valori:
+    errore; nel quel caso \var{errno} assumerà i valori:
     \begin{errlist}
-    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
     \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
     \end{errlist}    
 }
@@ -4081,23 +4081,23 @@ liberando il semaforo. La prima operazione 
 
 La funzione cerca di decrementare il valore del semaforo indicato dal
 puntatore \param{sem}, se questo ha un valore positivo, cosa che significa che
-la risorsa è disponibile, la funzione ha successo, il valore del semaforo
-viene diminuito di 1 ed essa ritorna immediatamente; se il valore è nullo la
+la risorsa è disponibile, la funzione ha successo, il valore del semaforo
+viene diminuito di 1 ed essa ritorna immediatamente; se il valore è nullo la
 funzione si blocca fintanto che il valore del semaforo non torni
 positivo\footnote{ovviamente per opera di altro processo che lo rilascia
-  chiamando \func{sem\_post}.} così che poi essa possa decrementarlo con
+  chiamando \func{sem\_post}.} così che poi essa possa decrementarlo con
 successo e proseguire. 
 
-Si tenga presente che la funzione può sempre essere interrotta da un segnale
-(nel qual caso si avrà un errore di \const{EINTR}) e che questo avverrà
-comunque, anche se si è richiesta la semantica BSD installando il relativo
+Si tenga presente che la funzione può sempre essere interrotta da un segnale
+(nel qual caso si avrà un errore di \const{EINTR}) e che questo avverrà
+comunque, anche se si è richiesta la semantica BSD installando il relativo
 gestore con \const{SA\_RESTART} (vedi sez.~\ref{sec:sig_sigaction}) per
 riavviare le system call interrotte.
 
 Della funzione \func{sem\_wait} esistono due varianti che consentono di
-gestire diversamente le modalità di attesa in caso di risorsa occupata, la
-prima di queste è \funcd{sem\_trywait}, che serve ad effettuare un tentativo
-di acquisizione senza bloccarsi; il suo prototipo è:
+gestire diversamente le modalità di attesa in caso di risorsa occupata, la
+prima di queste è \funcd{sem\_trywait}, che serve ad effettuare un tentativo
+di acquisizione senza bloccarsi; il suo prototipo è:
 \begin{functions}
   \headdecl{semaphore.h} 
   
@@ -4106,26 +4106,26 @@ di acquisizione senza bloccarsi; il suo prototipo 
   Tenta di bloccare il semaforo \param{sem}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore; nel quel caso \var{errno} assumerà gli stessi valori:
+    errore; nel quel caso \var{errno} assumerà gli stessi valori:
     \begin{errlist}
-    \item[\errcode{EAGAIN}] il semaforo non può essere acquisito senza
+    \item[\errcode{EAGAIN}] il semaforo non può essere acquisito senza
       bloccarsi. 
     \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
     \end{errlist}    
 }
 \end{functions}
 
-La funzione è identica a \func{sem\_wait} ed se la risorsa è libera ha lo
+La funzione è identica a \func{sem\_wait} ed se la risorsa è libera ha lo
 stesso effetto, vale a dire che in caso di semaforo diverso da zero la
-funzione lo decrementa e ritorna immediatamente; la differenza è che nel caso
-in cui il semaforo è occupato essa non si blocca e di nuovo ritorna
-immediatamente, restituendo però un errore di \errval{EAGAIN}, così che il
+funzione lo decrementa e ritorna immediatamente; la differenza è che nel caso
+in cui il semaforo è occupato essa non si blocca e di nuovo ritorna
+immediatamente, restituendo però un errore di \errval{EAGAIN}, così che il
 programma possa proseguire.
 
-La seconda variante di \func{sem\_wait} è una estensione specifica che può
+La seconda variante di \func{sem\_wait} è una estensione specifica che può
 essere utilizzata soltanto se viene definita la macro \macro{\_XOPEN\_SOURCE}
-ad un valore di 600 prima di includere \texttt{semaphore.h}, la funzione è
-\func{sem\_timedwait}, ed il suo prototipo è:
+ad un valore di 600 prima di includere \texttt{semaphore.h}, la funzione è
+\func{sem\_timedwait}, ed il suo prototipo è:
 \begin{functions}
   \headdecl{semaphore.h} 
 
@@ -4135,27 +4135,27 @@ ad un valore di 600 prima di includere \texttt{semaphore.h}, la funzione 
   Blocca il semaforo \param{sem}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore; nel quel caso \var{errno} assumerà gli stessi valori:
+    errore; nel quel caso \var{errno} assumerà gli stessi valori:
     \begin{errlist}
-    \item[\errcode{ETIMEDOUT}] è scaduto il tempo massimo di attesa. 
+    \item[\errcode{ETIMEDOUT}] è scaduto il tempo massimo di attesa. 
     \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
-    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
     \end{errlist}    
 }
 \end{functions}
 
-Anche in questo caso il comportamento della funzione è identico a quello di
+Anche in questo caso il comportamento della funzione è identico a quello di
 \func{sem\_wait}, la sola differenza consiste nel fatto che con questa
-funzione è possibile impostare tramite l'argomento \param{abs\_timeout} un
+funzione è possibile impostare tramite l'argomento \param{abs\_timeout} un
 tempo limite per l'attesa, scaduto il quale la funzione ritorna comunque,
-anche se non è possibile acquisire il semaforo. In tal caso la funzione
-fallirà, riportando un errore di \errval{ETIMEDOUT}.
+anche se non è possibile acquisire il semaforo. In tal caso la funzione
+fallirà, riportando un errore di \errval{ETIMEDOUT}.
 
-La seconda funzione principale utilizzata per l'uso dei semafori è
+La seconda funzione principale utilizzata per l'uso dei semafori è
 \funcd{sem\_post}, che viene usata per rilasciare un semaforo occupato o, in
-generale, per aumentare di una unità il valore dello stesso anche qualora non
+generale, per aumentare di una unità il valore dello stesso anche qualora non
 fosse occupato;\footnote{si ricordi che in generale un semaforo viene usato
-  come indicatore di un numero di risorse disponibili.} il suo prototipo è:
+  come indicatore di un numero di risorse disponibili.} il suo prototipo è:
 \begin{functions}
   \headdecl{semaphore.h} 
   
@@ -4164,7 +4164,7 @@ fosse occupato;\footnote{si ricordi che in generale un semaforo viene usato
   Rilascia il semaforo \param{sem}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore; nel quel caso \var{errno} assumerà i valori:
+    errore; nel quel caso \var{errno} assumerà i valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
     \end{errlist}    
@@ -4172,15 +4172,15 @@ fosse occupato;\footnote{si ricordi che in generale un semaforo viene usato
 \end{functions}
 
 La funzione incrementa di uno il valore corrente del semaforo indicato
-dall'argomento \param{sem}, se questo era nullo la relativa risorsa risulterà
-sbloccata, cosicché un altro processo (o \itindex{thread} \textit{thread})
-eventualmente bloccato in una \func{sem\_wait} sul semaforo potrà essere
-svegliato e rimesso in esecuzione.  Si tenga presente che la funzione è sicura
+dall'argomento \param{sem}, se questo era nullo la relativa risorsa risulterà
+sbloccata, cosicché un altro processo (o \itindex{thread} \textit{thread})
+eventualmente bloccato in una \func{sem\_wait} sul semaforo potrà essere
+svegliato e rimesso in esecuzione.  Si tenga presente che la funzione è sicura
 \index{funzioni!sicure} per l'uso all'interno di un gestore di segnali (si
 ricordi quanto detto in sez.~\ref{sec:sig_signal_handler}).
 
 Se invece di operare su un semaforo se ne vuole solamente leggere il valore,
-si può usare la funzione \funcd{sem\_getvalue}, il cui prototipo è:
+si può usare la funzione \funcd{sem\_getvalue}, il cui prototipo è:
 \begin{functions}
   \headdecl{semaphore.h} 
   
@@ -4189,7 +4189,7 @@ si pu
   Richiede il valore del semaforo \param{sem}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore; nel quel caso \var{errno} assumerà i valori:
+    errore; nel quel caso \var{errno} assumerà i valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
     \end{errlist}    
@@ -4198,20 +4198,20 @@ si pu
 
 La funzione legge il valore del semaforo indicato dall'argomento \param{sem} e
 lo restituisce nella variabile intera puntata dall'argomento
-\param{sval}. Qualora ci siano uno o più processi bloccati in attesa sul
+\param{sval}. Qualora ci siano uno o più processi bloccati in attesa sul
 semaforo lo standard prevede che la funzione possa restituire un valore nullo
 oppure il numero di processi bloccati in una \func{sem\_wait} sul suddetto
 semaforo; nel caso di Linux vale la prima opzione.
 
-Questa funzione può essere utilizzata per avere un suggerimento sullo stato di
-un semaforo, ovviamente non si può prendere il risultato riportato in
+Questa funzione può essere utilizzata per avere un suggerimento sullo stato di
+un semaforo, ovviamente non si può prendere il risultato riportato in
 \param{sval} che come indicazione, il valore del semaforo infatti potrebbe
-essere già stato modificato al ritorno della funzione.
+essere già stato modificato al ritorno della funzione.
 
 % TODO verificare comportamento sem_getvalue
 
-Una volta che non ci sia più la necessità di operare su un semaforo se ne può
-terminare l'uso con la funzione \funcd{sem\_close}, il cui prototipo è:
+Una volta che non ci sia più la necessità di operare su un semaforo se ne può
+terminare l'uso con la funzione \funcd{sem\_close}, il cui prototipo è:
 \begin{functions}
   \headdecl{semaphore.h} 
   
@@ -4220,7 +4220,7 @@ terminare l'uso con la funzione \funcd{sem\_close}, il cui prototipo 
   Chiude il semaforo \param{sem}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore; nel quel caso \var{errno} assumerà i valori:
+    errore; nel quel caso \var{errno} assumerà i valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
     \end{errlist}    
@@ -4228,25 +4228,25 @@ terminare l'uso con la funzione \funcd{sem\_close}, il cui prototipo 
 \end{functions}
 
 La funzione chiude il semaforo indicato dall'argomento \param{sem}; questo
-comporta che tutte le risorse che il sistema può avere assegnato al processo
+comporta che tutte le risorse che il sistema può avere assegnato al processo
 nell'uso dello stesso vengono rilasciate. Questo significa che un altro
 processo bloccato sul semaforo a causa della acquisizione da parte del
-processo che chiama \func{sem\_close} potrà essere riavviato.
+processo che chiama \func{sem\_close} potrà essere riavviato.
 
 Si tenga presente poi che come per i file all'uscita di un processo tutti i
 semafori che questo aveva aperto vengono automaticamente chiusi; questo
 comportamento risolve il problema che si aveva con i semafori del \textit{SysV
-  IPC} (di cui si è parlato in sez.~\ref{sec:ipc_sysv_sem}) per i quali le
+  IPC} (di cui si è parlato in sez.~\ref{sec:ipc_sysv_sem}) per i quali le
 risorse possono restare bloccate. Si tenga poi presente che, a differenza di
 quanto avviene per i file, in caso di una chiamata ad \func{execve} tutti i
 semafori vengono chiusi automaticamente.
 
 Come per i semafori del \textit{SysV IPC} anche quelli POSIX hanno una
-persistenza di sistema; questo significa che una volta che si è creato un
-semaforo con \func{sem\_open} questo continuerà ad esistere fintanto che il
+persistenza di sistema; questo significa che una volta che si è creato un
+semaforo con \func{sem\_open} questo continuerà ad esistere fintanto che il
 kernel resta attivo (vale a dire fino ad un successivo riavvio) a meno che non
-lo si cancelli esplicitamente. Per far questo si può utilizzare la funzione
-\funcd{sem\_unlink}, il cui prototipo è:
+lo si cancelli esplicitamente. Per far questo si può utilizzare la funzione
+\funcd{sem\_unlink}, il cui prototipo è:
 \begin{functions}
   \headdecl{semaphore.h} 
   
@@ -4255,11 +4255,11 @@ lo si cancelli esplicitamente. Per far questo si pu
   Rimuove il semaforo \param{name}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore; nel quel caso \var{errno} assumerà i valori:
+    errore; nel quel caso \var{errno} assumerà i valori:
     \begin{errlist}
     \item[\errcode{EACCESS}] non si hanno i permessi necessari a cancellare il
       semaforo.
-    \item[\errcode{ENAMETOOLONG}] il nome indicato è troppo lungo.
+    \item[\errcode{ENAMETOOLONG}] il nome indicato è troppo lungo.
     \item[\errcode{ENOENT}] il semaforo \param{name} non esiste.
     \end{errlist}    
 }
@@ -4269,17 +4269,17 @@ La funzione rimuove il semaforo indicato dall'argomento \param{name}, che
 prende un valore identico a quello usato per creare il semaforo stesso con
 \func{sem\_open}. Il semaforo viene rimosso dal filesystem immediatamente; ma
 il semaforo viene effettivamente cancellato dal sistema soltanto quando tutti
-i processi che lo avevano aperto lo chiudono. Si segue cioè la stessa
+i processi che lo avevano aperto lo chiudono. Si segue cioè la stessa
 semantica usata con \func{unlink} per i file, trattata in dettaglio in
 sez.~\ref{sec:file_link}.
 
-Una delle caratteristiche peculiari dei semafori POSIX è che questi possono
-anche essere utilizzati anche in forma anonima, senza necessità di fare
+Una delle caratteristiche peculiari dei semafori POSIX è che questi possono
+anche essere utilizzati anche in forma anonima, senza necessità di fare
 ricorso ad un nome sul filesystem o ad altri indicativi.  In questo caso si
-dovrà porre la variabile che contiene l'indirizzo del semaforo in un tratto di
+dovrà porre la variabile che contiene l'indirizzo del semaforo in un tratto di
 memoria che sia accessibile a tutti i processi in gioco.  La funzione che
-consente di inizializzare un semaforo anonimo è \funcd{sem\_init}, il cui
-prototipo è:
+consente di inizializzare un semaforo anonimo è \funcd{sem\_init}, il cui
+prototipo è:
 \begin{functions}
   \headdecl{semaphore.h} 
   
@@ -4288,11 +4288,11 @@ prototipo 
   Inizializza il semaforo anonimo \param{sem}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore; nel quel caso \var{errno} assumerà i valori:
+    errore; nel quel caso \var{errno} assumerà i valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] il valore di \param{value} eccede
       \const{SEM\_VALUE\_MAX}.
-    \item[\errcode{ENOSYS}] il valore di \param{pshared} non è nullo ed il
+    \item[\errcode{ENOSYS}] il valore di \param{pshared} non è nullo ed il
       sistema non supporta i semafori per i processi.
     \end{errlist}
 }
@@ -4307,15 +4307,15 @@ valore non nullo).
 
 Qualora il semaforo debba essere condiviso dai \itindex{thread}
 \textit{thread} di uno stesso processo (nel qual caso si parla di
-\textit{thread-shared semaphore}), occorrerà che \param{sem} sia l'indirizzo
+\textit{thread-shared semaphore}), occorrerà che \param{sem} sia l'indirizzo
 di una variabile visibile da tutti i \itindex{thread} \textit{thread}, si
-dovrà usare cioè una variabile globale o una variabile allocata dinamicamente
+dovrà usare cioè una variabile globale o una variabile allocata dinamicamente
 nello \itindex{heap} \textit{heap}.
 
-Qualora il semaforo debba essere condiviso fra più processi (nel qual caso si
+Qualora il semaforo debba essere condiviso fra più processi (nel qual caso si
 parla di \textit{process-shared semaphore}) la sola scelta possibile per
-renderlo visibile a tutti è di porlo in un tratto di memoria condivisa. Questo
-potrà essere ottenuto direttamente sia con \func{shmget} (vedi
+renderlo visibile a tutti è di porlo in un tratto di memoria condivisa. Questo
+potrà essere ottenuto direttamente sia con \func{shmget} (vedi
 sez.~\ref{sec:ipc_sysv_shm}) che con \func{shm\_open} (vedi
 sez.~\ref{sec:ipc_posix_shm}), oppure, nel caso che tutti i processi in gioco
 abbiano un genitore comune, con una mappatura anonima con \func{mmap} (vedi
@@ -4323,14 +4323,14 @@ sez.~\ref{sec:file_memory_map}),\footnote{si ricordi che i tratti di memoria
   condivisa vengono mantenuti nei processi figli attraverso la funzione
   \func{fork}.} a cui essi poi potranno accedere.
 
-Una volta inizializzato il semaforo anonimo con \func{sem\_init} lo si potrà
+Una volta inizializzato il semaforo anonimo con \func{sem\_init} lo si potrà
 utilizzare nello stesso modo dei semafori normali con \func{sem\_wait} e
-\func{sem\_post}. Si tenga presente però che inizializzare due volte lo stesso
-semaforo può dar luogo ad un comportamento indefinito. 
+\func{sem\_post}. Si tenga presente però che inizializzare due volte lo stesso
+semaforo può dar luogo ad un comportamento indefinito. 
 
-Una volta che non si intenda più utilizzare un semaforo anonimo questo può
+Una volta che non si intenda più utilizzare un semaforo anonimo questo può
 essere eliminato dal sistema; per far questo di deve utilizzare una apposita
-funzione, \funcd{sem\_destroy}, il cui prototipo è:
+funzione, \funcd{sem\_destroy}, il cui prototipo è:
 \begin{functions}
   \headdecl{semaphore.h} 
   
@@ -4339,7 +4339,7 @@ funzione, \funcd{sem\_destroy}, il cui prototipo 
   Elimina il semaforo anonimo \param{sem}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore; nel quel caso \var{errno} assumerà i valori:
+    errore; nel quel caso \var{errno} assumerà i valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] il valore di \param{value} eccede
       \const{SEM\_VALUE\_MAX}.
@@ -4352,16 +4352,16 @@ essere stato inizializzato con \func{sem\_init}; non deve quindi essere
 applicata a semafori creati con \func{sem\_open}. Inoltre si deve essere
 sicuri che il semaforo sia effettivamente inutilizzato, la distruzione di un
 semaforo su cui sono presenti processi (o \itindex{thread} \textit{thread}) in
-attesa (cioè bloccati in una \func{sem\_wait}) provoca un comportamento
+attesa (cioè bloccati in una \func{sem\_wait}) provoca un comportamento
 indefinito.
 
-Si tenga presente infine che utilizzare un semaforo che è stato distrutto con
-\func{sem\_destroy} di nuovo può dare esito a comportamenti indefiniti.  Nel
+Si tenga presente infine che utilizzare un semaforo che è stato distrutto con
+\func{sem\_destroy} di nuovo può dare esito a comportamenti indefiniti.  Nel
 caso ci si trovi in una tale evenienza occorre reinizializzare il semaforo una
 seconda volta con \func{sem\_init}.
 
 Come esempio di uso sia della memoria condivisa che dei semafori POSIX si sono
-scritti due semplici programmi con i quali è possibile rispettivamente
+scritti due semplici programmi con i quali è possibile rispettivamente
 monitorare il contenuto di un segmento di memoria condivisa e modificarne il
 contenuto. 
 
@@ -4376,64 +4376,64 @@ contenuto.
   \label{fig:ipc_posix_sem_shm_message_server}
 \end{figure}
 
-Il corpo principale del primo dei due, il cui codice completo è nel file
-\file{message\_getter.c} dei sorgenti allegati, è riportato in
-fig.~\ref{fig:ipc_posix_sem_shm_message_server}; si è tralasciata la parte che
+Il corpo principale del primo dei due, il cui codice completo è nel file
+\file{message\_getter.c} dei sorgenti allegati, è riportato in
+fig.~\ref{fig:ipc_posix_sem_shm_message_server}; si è tralasciata la parte che
 tratta la gestione delle opzioni a riga di comando (che consentono di
 impostare un nome diverso per il semaforo e il segmento di memoria condivisa)
 ed il controllo che al programma venga fornito almeno un argomento, contenente
 la stringa iniziale da inserire nel segmento di memoria condivisa.
 
-Lo scopo del programma è quello di creare un segmento di memoria condivisa su
+Lo scopo del programma è quello di creare un segmento di memoria condivisa su
 cui registrare una stringa, e tenerlo sotto osservazione stampando la stessa
-una volta al secondo. Si utilizzerà un semaforo per proteggere l'accesso in
+una volta al secondo. Si utilizzerà un semaforo per proteggere l'accesso in
 lettura alla stringa, in modo che questa non possa essere modificata
 dall'altro programma prima di averla finita di stampare.
 
 La parte iniziale del programma contiene le definizioni (\texttt{\small 1--8})
 del gestore del segnale usato per liberare le risorse utilizzate, delle
 variabili globali contenenti i nomi di default del segmento di memoria
-condivisa e del semaforo (il default scelto è \texttt{messages}), e delle
+condivisa e del semaforo (il default scelto è \texttt{messages}), e delle
 altre variabili utilizzate dal programma.
 
-Come prima istruzione (\texttt{\small 10}) si è provveduto ad installare un
-gestore di segnale che consentirà di effettuare le operazioni di pulizia
+Come prima istruzione (\texttt{\small 10}) si è provveduto ad installare un
+gestore di segnale che consentirà di effettuare le operazioni di pulizia
 (usando la funzione \func{Signal} illustrata in
-fig.~\ref{fig:sig_Signal_code}), dopo di che (\texttt{\small 10--16}) si è
+fig.~\ref{fig:sig_Signal_code}), dopo di che (\texttt{\small 10--16}) si è
 creato il segmento di memoria condivisa con la funzione \func{CreateShm} che
 abbiamo appena trattato in sez.~\ref{sec:ipc_posix_shm}, uscendo con un
 messaggio in caso di errore. 
 
 Si tenga presente che la funzione \func{CreateShm} richiede che il segmento
-non sia già presente e fallirà qualora un'altra istanza, o un altro programma
-abbia già allocato un segmento con quello stesso nome. Per semplicità di
-gestione si è usata una dimensione fissa pari a 256 byte, definita tramite la
+non sia già presente e fallirà qualora un'altra istanza, o un altro programma
+abbia già allocato un segmento con quello stesso nome. Per semplicità di
+gestione si è usata una dimensione fissa pari a 256 byte, definita tramite la
 costante \texttt{MSGMAXSIZE}.
 
-Il passo successivo (\texttt{\small 17--21}) è quello della creazione del
+Il passo successivo (\texttt{\small 17--21}) è quello della creazione del
 semaforo che regola l'accesso al segmento di memoria condivisa con
 \func{sem\_open}; anche in questo caso si gestisce l'uscita con stampa di un
 messaggio in caso di errore. Anche per il semaforo, avendo specificato la
 combinazione di flag \code{O\_CREAT|O\_EXCL} come secondo argomento, si esce
-qualora fosse già esistente; altrimenti esso verrà creato con gli opportuni
+qualora fosse già esistente; altrimenti esso verrà creato con gli opportuni
 permessi specificati dal terzo argomento, (indicante lettura e scrittura in
-notazione ottale). Infine il semaforo verrà inizializzato ad un valore nullo
+notazione ottale). Infine il semaforo verrà inizializzato ad un valore nullo
 (il quarto argomento), corrispondete allo stato in cui risulta bloccato.
 
-A questo punto (\texttt{\small 23}) si potrà inizializzare il messaggio posto
+A questo punto (\texttt{\small 23}) si potrà inizializzare il messaggio posto
 nel segmento di memoria condivisa usando la stringa passata come argomento al
-programma. Essendo il semaforo stato creato già bloccato non ci si dovrà
+programma. Essendo il semaforo stato creato già bloccato non ci si dovrà
 preoccupare di eventuali \itindex{race~condition} \textit{race condition}
 qualora il programma di modifica del messaggio venisse lanciato proprio in
-questo momento.  Una volta inizializzato il messaggio occorrerà però
+questo momento.  Una volta inizializzato il messaggio occorrerà però
 rilasciare il semaforo (\texttt{\small 25--28}) per consentirne l'uso; in
-tutte queste operazioni si provvederà ad uscire dal programma con un opportuno
+tutte queste operazioni si provvederà ad uscire dal programma con un opportuno
 messaggio in caso di errore.
 
 Una volta completate le inizializzazioni il ciclo principale del programma
 (\texttt{\small 29--47}) viene ripetuto indefinitamente (\texttt{\small 29})
 per stampare sia il contenuto del messaggio che una serie di informazioni di
-controllo. Il primo passo (\texttt{\small 30--34}) è quello di acquisire (con
+controllo. Il primo passo (\texttt{\small 30--34}) è quello di acquisire (con
 \func{sem\_getvalue}, con uscita in caso di errore) e stampare il valore del
 semaforo ad inizio del ciclo; seguito (\texttt{\small 35--36}) dal tempo
 corrente.
@@ -4452,17 +4452,17 @@ corrente.
 Prima della stampa del messaggio invece si deve acquisire il semaforo
 (\texttt{\small 31--34}) per evitare accessi concorrenti alla stringa da parte
 del programma di modifica. Una volta eseguita la stampa (\texttt{\small 41})
-il semaforo dovrà essere rilasciato (\texttt{\small 42--45}). Il passo finale
-(\texttt{\small 46}) è attendere per un secondo prima di eseguire da capo il
+il semaforo dovrà essere rilasciato (\texttt{\small 42--45}). Il passo finale
+(\texttt{\small 46}) è attendere per un secondo prima di eseguire da capo il
 ciclo. 
 
-Per uscire in maniera corretta dal programma sarà necessario interromperlo con
+Per uscire in maniera corretta dal programma sarà necessario interromperlo con
 il break da tastiera (\texttt{C-c}), che corrisponde all'invio del segnale
-\const{SIGINT}, per il quale si è installato (\texttt{\small 10}) una
+\const{SIGINT}, per il quale si è installato (\texttt{\small 10}) una
 opportuna funzione di gestione, riportata in
-fig.~\ref{fig:ipc_posix_sem_shm_message_server_handler}. La funzione è molto
+fig.~\ref{fig:ipc_posix_sem_shm_message_server_handler}. La funzione è molto
 semplice e richiama le funzioni di rimozione sia per il segmento di memoria
-condivisa che per il semaforo, garantendo così che possa essere riaperto
+condivisa che per il semaforo, garantendo così che possa essere riaperto
 ex-novo senza errori in un futuro riutilizzo del comando.
 
 \begin{figure}[!h]
@@ -4476,10 +4476,10 @@ ex-novo senza errori in un futuro riutilizzo del comando.
   \label{fig:ipc_posix_sem_shm_message_setter}
 \end{figure}
 
-Il secondo programma di esempio è \file{message\_setter.c}, di cui si è
+Il secondo programma di esempio è \file{message\_setter.c}, di cui si è
 riportato il corpo principale in
 fig.~\ref{fig:ipc_posix_sem_shm_message_setter},\footnote{al solito il codice
-  completo è nel file dei sorgenti allegati.} dove si è tralasciata, non
+  completo è nel file dei sorgenti allegati.} dove si è tralasciata, non
 essendo significativa per quanto si sta trattando, la parte relativa alla
 gestione delle opzioni a riga di comando e degli argomenti, che sono identici
 a quelli usati da \file{message\_getter}, con l'unica aggiunta di un'opzione
@@ -4490,29 +4490,29 @@ Una volta completata la gestione delle opzioni e degli argomenti (ne deve
 essere presente uno solo, contenente la nuova stringa da usare come
 messaggio), il programma procede (\texttt{\small 10--14}) con l'acquisizione
 del segmento di memoria condivisa usando la funzione \func{FindShm} (trattata
-in sez.~\ref{sec:ipc_posix_shm}) che stavolta deve già esistere.  Il passo
-successivo (\texttt{\small 16--19}) è quello di aprire il semaforo, e a
+in sez.~\ref{sec:ipc_posix_shm}) che stavolta deve già esistere.  Il passo
+successivo (\texttt{\small 16--19}) è quello di aprire il semaforo, e a
 differenza di \file{message\_getter}, in questo caso si richiede a
 \func{sem\_open} che questo esista, passando uno zero come secondo ed unico
 argomento.
 
 Una volta completate con successo le precedenti inizializzazioni, il passo
-seguente (\texttt{\small 21--24}) è quello di acquisire il semaforo, dopo di
-che sarà possibile eseguire la sostituzione del messaggio (\texttt{\small 25})
+seguente (\texttt{\small 21--24}) è quello di acquisire il semaforo, dopo di
+che sarà possibile eseguire la sostituzione del messaggio (\texttt{\small 25})
 senza incorrere in possibili \itindex{race~condition} \textit{race condition}
 con la stampa dello stesso da parte di \file{message\_getter}.
 
 Una volta effettuata la modifica viene stampato (\texttt{\small 26}) il tempo
 di attesa impostato con l'opzione ``\texttt{-t}'' dopo di che (\texttt{\small
-  27}) viene eseguita la stessa, senza rilasciare il semaforo che resterà
+  27}) viene eseguita la stessa, senza rilasciare il semaforo che resterà
 quindi bloccato (causando a questo punto una interruzione delle stampe
-eseguite da \file{message\_getter}). Terminato il tempo di attesa si rilascerà
+eseguite da \file{message\_getter}). Terminato il tempo di attesa si rilascerà
 (\texttt{\small 29--32}) il semaforo per poi uscire.
 
-Per verificare il funzionamento dei programmi occorrerà lanciare per primo
-\file{message\_getter}\footnote{lanciare per primo \file{message\_setter} darà
+Per verificare il funzionamento dei programmi occorrerà lanciare per primo
+\file{message\_getter}\footnote{lanciare per primo \file{message\_setter} darà
   luogo ad un errore, non essendo stati creati il semaforo ed il segmento di
-  memoria condivisa.} che inizierà a stampare una volta al secondo il
+  memoria condivisa.} che inizierà a stampare una volta al secondo il
 contenuto del messaggio ed i suoi dati, con qualcosa del tipo:
 \begin{Verbatim}
 piccardi@hain:~/gapil/sources$  ./message_getter messaggio
@@ -4525,9 +4525,9 @@ message: messaggio
 %$
 proseguendo indefinitamente fintanto che non si prema \texttt{C-c} per farlo
 uscire. Si noti come il valore del semaforo risulti sempre pari ad 1 (in
-quanto al momento esso sarà sempre libero). 
+quanto al momento esso sarà sempre libero). 
 
-A questo punto si potrà lanciare \file{message\_setter} per cambiare il
+A questo punto si potrà lanciare \file{message\_setter} per cambiare il
 messaggio, nel nostro caso per rendere evidente il funzionamento del blocco
 richiederemo anche una attesa di 3 secondi, ed otterremo qualcosa del tipo:
 \begin{Verbatim}
@@ -4535,11 +4535,11 @@ piccardi@hain:~/gapil/sources$ ./message_setter -t 3 ciao
 Sleeping for 3 seconds
 \end{Verbatim}
 %$
-dove il programma si fermerà per 3 secondi prima di rilasciare il semaforo e
+dove il programma si fermerà per 3 secondi prima di rilasciare il semaforo e
 terminare. 
 
-L'effetto di questo programma si potrà però apprezzare meglio nell'uscita di
-\file{message\_getter}, che verrà interrotta per questo stesso tempo, prima di
+L'effetto di questo programma si potrà però apprezzare meglio nell'uscita di
+\file{message\_getter}, che verrà interrotta per questo stesso tempo, prima di
 ricominciare con il nuovo testo:
 \begin{Verbatim}
 ...
@@ -4557,9 +4557,9 @@ message: ciao
 \end{Verbatim}
 %$
 
-E si noterà come nel momento in cui si è lanciato \file{message\_setter} le
+E si noterà come nel momento in cui si è lanciato \file{message\_setter} le
 stampe di \file{message\_getter} si bloccheranno, come corretto, dopo aver
-registrato un valore nullo per il semaforo.  Il programma infatti resterà
+registrato un valore nullo per il semaforo.  Il programma infatti resterà
 bloccato nella \func{sem\_wait} (quella di riga (\texttt{\small 37}) in
 fig.~\ref{fig:ipc_posix_sem_shm_message_server}) fino alla scadenza
 dell'attesa di \file{message\_setter} (con l'esecuzione della \func{sem\_post}
diff --git a/netlayer.tex b/netlayer.tex
index b49cb36..2db12f0 100644
--- a/netlayer.tex
+++ b/netlayer.tex
@@ -20,12 +20,12 @@ generica delle principali caratteristiche, del formato di dati usato e quanto
 possa essere necessario per capirne meglio il funzionamento dal punto di vista
 della programmazione.
 
-Data la loro prevalenza il capitolo sarà sostanzialmente incentrato sui due
+Data la loro prevalenza il capitolo sarà sostanzialmente incentrato sui due
 protocolli principali esistenti su questo livello: il protocollo IP, sigla che
-sta per \textit{Internet Protocol}, (ma che più propriamente si dovrebbe
+sta per \textit{Internet Protocol}, (ma che più propriamente si dovrebbe
 chiamare IPv4) ed la nuova versione di questo stesso protocollo, denominata
 IPv6. Tratteremo comunque anche il protocollo ICMP e la sua versione
-modificata per IPv6 (cioè ICMPv6).
+modificata per IPv6 (cioè ICMPv6).
 
 
 \section{Il protocollo IP}
@@ -35,37 +35,37 @@ L'attuale \textit{Internet Protocol} (IPv4) viene standardizzato nel 1981
 dall'\href{http://www.ietf.org/rfc/rfc791.txt}{RFC~791}; esso nasce per
 disaccoppiare le applicazioni della struttura hardware delle reti di
 trasmissione, e creare una interfaccia di trasmissione dei dati indipendente
-dal sottostante substrato di rete, che può essere realizzato con le tecnologie
-più disparate (Ethernet, Token Ring, FDDI, ecc.).
+dal sottostante substrato di rete, che può essere realizzato con le tecnologie
+più disparate (Ethernet, Token Ring, FDDI, ecc.).
 
 
 \subsection{Introduzione}
 \label{sec:IP_intro}
 
-Il compito principale di IP è quello di trasmettere i pacchetti da un computer
+Il compito principale di IP è quello di trasmettere i pacchetti da un computer
 all'altro della rete; le caratteristiche essenziali con cui questo viene
 realizzato in IPv4 sono due:
 \begin{itemize}
 \item \textit{Universal addressing} la comunicazione avviene fra due host
-  identificati univocamente con un indirizzo a 32 bit che può appartenere ad
+  identificati univocamente con un indirizzo a 32 bit che può appartenere ad
   una sola interfaccia di rete.
 \item \textit{Best effort} viene assicurato il massimo impegno nella
-  trasmissione, ma non c'è nessuna garanzia per i livelli superiori né
-  sulla percentuale di successo né sul tempo di consegna dei pacchetti di
-  dati, né sull'ordine in cui vengono consegnati.
+  trasmissione, ma non c'è nessuna garanzia per i livelli superiori né
+  sulla percentuale di successo né sul tempo di consegna dei pacchetti di
+  dati, né sull'ordine in cui vengono consegnati.
 \end{itemize}
 
 Per effettuare la comunicazione e l'instradamento dei pacchetti fra le varie
-reti di cui è composta Internet IPv4 organizza gli indirizzi in una
+reti di cui è composta Internet IPv4 organizza gli indirizzi in una
 gerarchia a due livelli, in cui una parte dei 32 bit dell'indirizzo indica il
 numero di rete, e un'altra l'host al suo interno.  Il numero di rete serve
 ai router per stabilire a quale rete il pacchetto deve essere inviato, il
 numero di host indica la macchina di destinazione finale all'interno di detta
 rete.
 
-Per garantire l'unicità dell'indirizzo Internet esiste un'autorità centrale
+Per garantire l'unicità dell'indirizzo Internet esiste un'autorità centrale
 (la IANA, \textit{Internet Assigned Number Authority}) che assegna i numeri di
-rete alle organizzazioni che ne fanno richiesta; è poi compito di quest'ultime
+rete alle organizzazioni che ne fanno richiesta; è poi compito di quest'ultime
 assegnare i numeri dei singoli host all'interno della propria rete.
 
 Per venire incontro alle richieste dei vari enti e organizzazioni che volevano
@@ -147,15 +147,15 @@ dispiegamenti di reti di varie dimensioni a seconda delle diverse esigenze.
 \end{table}
 
 Le classi di indirizzi usate per il dispiegamento delle reti su quella che
-comunemente viene chiamata \textit{Internet} sono le prime tre; la classe D è
-destinata al \itindex{multicast} \textit{multicast} mentre la classe E è
+comunemente viene chiamata \textit{Internet} sono le prime tre; la classe D è
+destinata al \itindex{multicast} \textit{multicast} mentre la classe E è
 riservata per usi sperimentali e non viene impiegata.
 
-Come si può notare però la suddivisione riportata in
-tab.~\ref{tab:IP_ipv4class} è largamente inefficiente in quanto se ad un
-utente necessita anche solo un indirizzo in più dei 256 disponibili con una
+Come si può notare però la suddivisione riportata in
+tab.~\ref{tab:IP_ipv4class} è largamente inefficiente in quanto se ad un
+utente necessita anche solo un indirizzo in più dei 256 disponibili con una
 classe A occorre passare a una classe B, che ne prevede 65536,\footnote{in
-  realtà i valori esatti sarebbero 254 e 65536, una rete con a disposizione
+  realtà i valori esatti sarebbero 254 e 65536, una rete con a disposizione
   $N$ bit dell'indirizzo IP, ha disponibili per le singole macchine soltanto
   $@^N-2$ numeri, dato che uno deve essere utilizzato come indirizzo di rete e
   uno per l'indirizzo di \itindex{broadcast} \textit{broadcast}.} con un
@@ -195,11 +195,11 @@ parte di questi ultimi ed inefficienza nel trasporto.
 \label{tab:IP_ipv4cidr}
 \end{table}
 
-Per questo nel 1992 è stato introdotto un indirizzamento senza classi (il
+Per questo nel 1992 è stato introdotto un indirizzamento senza classi (il
 CIDR, \textit{Classless Inter-Domain Routing}) in cui il limite fra i bit
 destinati a indicare il numero di rete e quello destinati a indicare l'host
-finale può essere piazzato in qualunque punto (vedi
-tab.~\ref{tab:IP_ipv4cidr}), permettendo di accorpare più classi A su un'unica
+finale può essere piazzato in qualunque punto (vedi
+tab.~\ref{tab:IP_ipv4cidr}), permettendo di accorpare più classi A su un'unica
 rete o suddividere una classe B e diminuendo al contempo il numero di
 indirizzi di rete da inserire nelle tabelle di instradamento dei router.
 
@@ -211,7 +211,7 @@ Come illustrato in fig.~\ref{fig:net_tcpip_data_flux} (si ricordi quanto detto
 in sez.~\ref{sec:net_tcpip_overview} riguardo al funzionamento generale del
 TCP/IP), per eseguire il suo compito il protocollo IP inserisce (come
 praticamente ogni protocollo di rete) una opportuna intestazione in cima ai
-dati che deve trasmettere, la cui schematizzazione è riportata in
+dati che deve trasmettere, la cui schematizzazione è riportata in
 fig.~\ref{fig:IP_ipv4_head}.
 
 \begin{figure}[htb]
@@ -222,12 +222,12 @@ fig.~\ref{fig:IP_ipv4_head}.
 \end{figure}
 
 Ciascuno dei campi illustrati in fig.~\ref{fig:IP_ipv4_head} ha un suo preciso
-scopo e significato, che si è riportato brevemente in
+scopo e significato, che si è riportato brevemente in
 tab.~\ref{tab:IP_ipv4field}; si noti come l'intestazione riporti sempre due
-indirizzi IP, quello \textsl{sorgente}, che indica l'IP da cui è partito il
-pacchetto (cioè l'indirizzo assegnato alla macchina che lo spedisce) e quello
+indirizzi IP, quello \textsl{sorgente}, che indica l'IP da cui è partito il
+pacchetto (cioè l'indirizzo assegnato alla macchina che lo spedisce) e quello
 \textsl{destinazione} che indica l'indirizzo a cui deve essere inviato il
-pacchetto (cioè l'indirizzo assegnato alla macchina che lo riceverà).
+pacchetto (cioè l'indirizzo assegnato alla macchina che lo riceverà).
 
 \begin{table}[!hbt]
   \footnotesize
@@ -241,33 +241,33 @@ pacchetto (cio
                                   specifico vale sempre 4.\\
       \textit{head length}   & 4& Lunghezza dell'intestazione,
                                   in multipli di 32 bit.\\
-      \textit{type of service}&8& Il ``\textsl{tipo di servizio}'', è suddiviso
+      \textit{type of service}&8& Il ``\textsl{tipo di servizio}'', è suddiviso
                                   in: 3 bit di precedenza, che nelle attuali
                                   implementazioni del protocollo non vengono
                                   comunque utilizzati; un bit riservato che
                                   deve essere mantenuto a 0; 4 bit che
                                   identificano il tipo di servizio
-                                  richiesto, uno solo dei quali può essere
+                                  richiesto, uno solo dei quali può essere
                                   attivo.\\ 
       \textit{total length}  &16& La \textsl{lunghezza totale}, indica 
                                   la dimensione del carico di dati del
                                   pacchetto IP in byte.\\ 
       \textit{identification}&16& L'\textsl{identificazione}, assegnato alla
-                                  creazione, è aumentato di uno all'origine
+                                  creazione, è aumentato di uno all'origine
                                   della trasmissione di ciascun pacchetto, ma
                                   resta lo stesso per i pacchetti
-                                  frammentati, consentendo così di
+                                  frammentati, consentendo così di
                                   identificare quelli che derivano dallo
                                   stesso pacchetto originario.\\
       \textit{flag}          & 3& I \textsl{flag} di controllo nell'ordine: il 
-                                  primo è riservato e sempre nullo, il secondo
-                                  indica se il pacchetto non può essere 
+                                  primo è riservato e sempre nullo, il secondo
+                                  indica se il pacchetto non può essere 
                                   frammentato, il terzo se ci sono ulteriori
                                   frammenti.\\  
       \textit{fragmentation offset}&13& L'\textsl{offset di frammento}, indica
                                   la posizione del frammento rispetto al
                                   pacchetto originale.\\
-      \textit{time to live}  &16& Il \textsl{tempo di vita}, è decrementato di
+      \textit{time to live}  &16& Il \textsl{tempo di vita}, è decrementato di
                                   uno ogni volta che un router ritrasmette il
                                   pacchetto, se arriva a zero il pacchetto
                                   viene scartato.\\ 
@@ -286,15 +286,15 @@ pacchetto (cio
 
 
 Il campo TOS definisce il cosiddetto \textit{Type of Service}; questo permette
-di definire il tipo di traffico contenuto nei pacchetti, e può essere
-utilizzato dai router per dare diverse priorità in base al valore assunto da
-questo campo. Abbiamo già visto come il valore di questo campo può essere
+di definire il tipo di traffico contenuto nei pacchetti, e può essere
+utilizzato dai router per dare diverse priorità in base al valore assunto da
+questo campo. Abbiamo già visto come il valore di questo campo può essere
 impostato sul singolo socket con l'opzione \const{IP\_TOS} (vedi
-sez.~\ref{sec:sock_ipv4_options}), esso inoltre può essere manipolato sia dal
+sez.~\ref{sec:sock_ipv4_options}), esso inoltre può essere manipolato sia dal
 sistema del \textit{netfilter} di Linux con il comando \texttt{iptables} che
 dal sistema del routing avanzato del comando \texttt{ip route} per consentire
-un controllo più dettagliato dell'instradamento dei pacchetti e l'uso di
-priorità e politiche di distribuzione degli stessi.
+un controllo più dettagliato dell'instradamento dei pacchetti e l'uso di
+priorità e politiche di distribuzione degli stessi.
 
 \begin{table}[!htb]
   \centering
@@ -305,13 +305,13 @@ priorit
     \hline
     \hline
     \const{IPTOS\_LOWDELAY}     &\texttt{0x10}& Minimizza i ritardi
-                                                per rendere più veloce
+                                                per rendere più veloce
                                                 possibile la ritrasmissione
                                                 dei pacchetti (usato per
                                                 traffico interattivo di
                                                 controllo come SSH).\\
     \const{IPTOS\_THROUGHPUT}   &\texttt{0x8} & Ottimizza la trasmissione
-                                                per rendere il più elevato
+                                                per rendere il più elevato
                                                 possibile il flusso netto di
                                                 dati (usato su traffico dati,
                                                 come quello di FTP).\\ 
@@ -323,7 +323,7 @@ priorit
                                                 o DHCP).\\
    \const{IPTOS\_MINCOST}       &\texttt{0x2} & Indica i dati di riempimento,
                                                 dove non interessa se si ha
-                                                una bassa velocità di
+                                                una bassa velocità di
                                                 trasmissione, da utilizzare
                                                 per i collegamenti con minor
                                                 costo (usato per i protocolli
@@ -346,8 +346,8 @@ associata.
 
 Il campo TTL, acromino di \textit{Time To Live}, viene utilizzato per
 stabilire una sorta di tempo di vita massimo dei pacchetti sulla rete. In
-realtà più che di un tempo, il campo serve a limitare il numero massimo di
-salti (i cosiddetti \textit{hop}) che un pacchetto IP può compiere nel passare
+realtà più che di un tempo, il campo serve a limitare il numero massimo di
+salti (i cosiddetti \textit{hop}) che un pacchetto IP può compiere nel passare
 da un router ad un altro nel suo attraversamento della rete verso la
 destinazione.
 
@@ -360,10 +360,10 @@ questo avviene durante il transito sulla rete o
 \textit{ttl-zero-during-reassembly} se questo avviene alla destinazione finale
 (vedi sez.~\ref{sec:ICMP_protocol}).
 
-In sostanza grazie all'uso di questo accorgimento un pacchetto non può
+In sostanza grazie all'uso di questo accorgimento un pacchetto non può
 continuare a vagare indefinitamente sulla rete, e viene comunque scartato dopo
 un certo tempo, o meglio, dopo che ha attraversato in certo numero di
-router. Nel caso di Linux il valore iniziale utilizzato normalmente è 64 (vedi
+router. Nel caso di Linux il valore iniziale utilizzato normalmente è 64 (vedi
 sez.~\ref{sec:sock_ipv4_sysctl}).
 
 
@@ -378,18 +378,18 @@ Da fare ...
 \label{sec:ipv6_protocol}
 
 Negli anni '90 con la crescita del numero di macchine connesse su Internet si
-arrivò a temere l'esaurimento dello spazio degli indirizzi disponibili, specie
+arrivò a temere l'esaurimento dello spazio degli indirizzi disponibili, specie
 in vista di una prospettiva (per ora rivelatasi prematura) in cui ogni
 apparecchio elettronico sarebbe stato inserito all'interno della rete. 
 
-Per questo motivo si iniziò a progettare una nuova versione del protocollo 
+Per questo motivo si iniziò a progettare una nuova versione del protocollo 
 
 L'attuale Internet Protocol (IPv4) viene standardizzato nel 1981
 dall'\href{http://www.ietf.org/rfc/rfc719.txt}{RFC~719}; esso nasce per
 disaccoppiare le applicazioni della struttura hardware delle reti di
 trasmissione, e creare una interfaccia di trasmissione dei dati indipendente
-dal sottostante substrato di rete, che può essere realizzato con le tecnologie
-più disparate (Ethernet, Token Ring, FDDI, ecc.).
+dal sottostante substrato di rete, che può essere realizzato con le tecnologie
+più disparate (Ethernet, Token Ring, FDDI, ecc.).
 
 
 \subsection{I motivi della transizione}
@@ -397,15 +397,15 @@ pi
 
 Negli ultimi anni la crescita vertiginosa del numero di macchine connesse a
 internet ha iniziato a far emergere i vari limiti di IPv4; in particolare si
-è iniziata a delineare la possibilità di arrivare a una carenza di
+è iniziata a delineare la possibilità di arrivare a una carenza di
 indirizzi disponibili.
 
-In realtà il problema non è propriamente legato al numero di indirizzi
-disponibili; infatti con 32 bit si hanno $2^{32}$, cioè circa 4 miliardi,
-numeri diversi possibili, che sono molti di più dei computer attualmente
+In realtà il problema non è propriamente legato al numero di indirizzi
+disponibili; infatti con 32 bit si hanno $2^{32}$, cioè circa 4 miliardi,
+numeri diversi possibili, che sono molti di più dei computer attualmente
 esistenti.
 
-Il punto è che la suddivisione di questi numeri nei due livelli rete/host e
+Il punto è che la suddivisione di questi numeri nei due livelli rete/host e
 l'utilizzo delle classi di indirizzamento mostrate in precedenza, ha
 comportato che, nella sua evoluzione storica, il dispiegamento delle reti e
 l'allocazione degli indirizzi siano stati inefficienti; neanche l'uso del CIDR
@@ -414,16 +414,16 @@ ridispiegamento degli indirizzi comporta cambiamenti complessi a tutti i
 livelli e la riassegnazione di tutti gli indirizzi dei computer di ogni
 sottorete.
 
-Diventava perciò necessario progettare un nuovo protocollo che permettesse
-di risolvere questi problemi, e garantisse flessibilità sufficiente per
+Diventava perciò necessario progettare un nuovo protocollo che permettesse
+di risolvere questi problemi, e garantisse flessibilità sufficiente per
 poter continuare a funzionare a lungo termine; in particolare necessitava un
 nuovo schema di indirizzamento che potesse rispondere alle seguenti
-necessità:
+necessità:
 
 \begin{itemize}
 \item un maggior numero di numeri disponibili che consentisse di non restare
-  più a corto di indirizzi
-\item un'organizzazione gerarchica più flessibile dell'attuale 
+  più a corto di indirizzi
+\item un'organizzazione gerarchica più flessibile dell'attuale 
 \item uno schema di assegnazione degli indirizzi in grado di minimizzare le
   dimensioni delle tabelle di instradamento
 \item uno spazio di indirizzi che consentisse un passaggio automatico dalle
@@ -437,28 +437,28 @@ necessit
 Per rispondere alle esigenze descritte in sez.~\ref{sec:IP_whyipv6} IPv6 nasce
 come evoluzione di IPv4, mantenendone inalterate le funzioni che si sono
 dimostrate valide, eliminando quelle inutili e aggiungendone poche altre
-ponendo al contempo una grande attenzione a mantenere il protocollo il più
+ponendo al contempo una grande attenzione a mantenere il protocollo il più
 snello e veloce possibile.
 
 I cambiamenti apportati sono comunque notevoli e possono essere riassunti a
 grandi linee nei seguenti punti:
 \begin{itemize}
-\item l'espansione delle capacità di indirizzamento e instradamento, per
-  supportare una gerarchia con più livelli di indirizzamento, un numero di
+\item l'espansione delle capacità di indirizzamento e instradamento, per
+  supportare una gerarchia con più livelli di indirizzamento, un numero di
   nodi indirizzabili molto maggiore e una auto-configurazione degli indirizzi
 \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
   si aggiungono agli usuali \textit{unicast} e \itindex{multicast}
   \textit{multicast}
 \item la semplificazione del formato dell'intestazione, eliminando o rendendo
-  opzionali alcuni dei campi di IPv4, per eliminare la necessità di
+  opzionali alcuni dei campi di IPv4, per eliminare la necessità di
   riprocessare la stessa da parte dei router e contenere l'aumento di
   dimensione dovuto ai nuovi indirizzi
 \item un supporto per le opzioni migliorato, per garantire una trasmissione
-  più efficiente del traffico normale, limiti meno stringenti sulle
-  dimensioni delle opzioni, e la flessibilità necessaria per introdurne di
+  più efficiente del traffico normale, limiti meno stringenti sulle
+  dimensioni delle opzioni, e la flessibilità necessaria per introdurne di
   nuove in futuro
-\item il supporto per delle capacità di qualità di servizio (QoS) che
-  permetta di identificare gruppi di dati per i quali si può provvedere un
+\item il supporto per delle capacità di qualità di servizio (QoS) che
+  permetta di identificare gruppi di dati per i quali si può provvedere un
   trattamento speciale (in vista dell'uso di internet per applicazioni
   multimediali e/o ``real-time'')
 \end{itemize}
@@ -469,9 +469,9 @@ grandi linee nei seguenti punti:
 
 Per capire le caratteristiche di IPv6 partiamo dall'intestazione usata dal
 protocollo per gestire la trasmissione dei pacchetti; in
-fig.~\ref{fig:IP_ipv6head} è riportato il formato dell'intestazione di IPv6 da
+fig.~\ref{fig:IP_ipv6head} è riportato il formato dell'intestazione di IPv6 da
 confrontare con quella di IPv4 in fig.~\ref{fig:IP_ipv4_head}. La spiegazione
-del significato dei vari campi delle due intestazioni è riportato
+del significato dei vari campi delle due intestazioni è riportato
 rispettivamente in tab.~\ref{tab:IP_ipv6field} e tab.~\ref{tab:IP_ipv4field})
 
 % \begin{table}[htb]
@@ -517,7 +517,7 @@ rispettivamente in tab.~\ref{tab:IP_ipv6field} e tab.~\ref{tab:IP_ipv4field})
 \end{figure}
 
 
-Come si può notare l'intestazione di IPv6 diventa di dimensione fissa, pari a
+Come si può notare l'intestazione di IPv6 diventa di dimensione fissa, pari a
 40 byte, contro una dimensione (minima, in assenza di opzioni) di 20 byte per
 IPv4; un semplice raddoppio nonostante lo spazio destinato agli indirizzi sia
 quadruplicato, questo grazie a una notevole semplificazione che ha ridotto il
@@ -533,11 +533,11 @@ numero dei campi da 12 a 8.
       \hline
       \textit{version}       & 4& La \textsl{versione}, nel caso specifico vale
                                   sempre 6.\\ 
-      \textit{priority}      & 4& La \textsl{priorità}, vedi
+      \textit{priority}      & 4& La \textsl{priorità}, vedi
                                   sez.~\ref{sec:IPv6_prio}.\\
       \textit{flow label}    &24& L'\textsl{etichetta di flusso}, vedi
                                   sez.~\ref{sec:IP_ipv6_flow}.\\ 
-      \textit{payload length}&16& La \textsl{lunghezza del carico}, cioè del
+      \textit{payload length}&16& La \textsl{lunghezza del carico}, cioè del
                                   corpo dei dati che segue l'intestazione, in
                                   byte. \\ 
       \textit{next header}   & 8& L'\textsl{intestazione successiva}, 
@@ -557,44 +557,44 @@ numero dei campi da 12 a 8.
   \end{center}
 \end{table}
 
-Abbiamo già anticipato in sez.~\ref{sec:IP_ipv6over} uno dei criteri
-principali nella progettazione di IPv6 è stato quello di ridurre al minimo il
+Abbiamo già anticipato in sez.~\ref{sec:IP_ipv6over} uno dei criteri
+principali nella progettazione di IPv6 è stato quello di ridurre al minimo il
 tempo di elaborazione dei pacchetti da parte dei router, un confronto con
 l'intestazione di IPv4 (vedi fig.~\ref{fig:IP_ipv4_head}) mostra le seguenti
 differenze:
 
 \begin{itemize}
-\item è stato eliminato il campo \textit{header length} in quanto le opzioni
-  sono state tolte dall'intestazione che ha così dimensione fissa; ci possono
-  essere più intestazioni opzionali (\textsl{intestazioni di estensione}, vedi
-  sez.~\ref{sec:IP_ipv6_extens}), ciascuna delle quali avrà un suo campo di
+\item è stato eliminato il campo \textit{header length} in quanto le opzioni
+  sono state tolte dall'intestazione che ha così dimensione fissa; ci possono
+  essere più intestazioni opzionali (\textsl{intestazioni di estensione}, vedi
+  sez.~\ref{sec:IP_ipv6_extens}), ciascuna delle quali avrà un suo campo di
   lunghezza all'interno.
-\item l'intestazione e gli indirizzi sono allineati a 64 bit, questo rende più
+\item l'intestazione e gli indirizzi sono allineati a 64 bit, questo rende più
   veloce il processo da parte di computer con processori a 64 bit.
 \item i campi per gestire la frammentazione (\textit{identification},
   \textit{flag} e \textit{fragment offset}) sono stati eliminati; questo
-  perché la frammentazione è un'eccezione che non deve rallentare
+  perché la frammentazione è un'eccezione che non deve rallentare
   l'elaborazione dei pacchetti nel caso normale.
-\item è stato eliminato il campo \textit{checksum} in quanto tutti i
+\item è stato eliminato il campo \textit{checksum} in quanto tutti i
   protocolli di livello superiore (TCP, UDP e ICMPv6) hanno un campo di
   checksum che include, oltre alla loro intestazione e ai dati, pure i campi
   \textit{payload length}, \textit{next header}, e gli indirizzi di origine e
   di destinazione; una checksum esiste anche per la gran parte protocolli di
   livello inferiore (anche se quelli che non lo hanno, come SLIP, non possono
-  essere usati con grande affidabilità); con questa scelta si è ridotto di
-  molto il tempo di elaborazione dato che i router non hanno più la necessità
+  essere usati con grande affidabilità); con questa scelta si è ridotto di
+  molto il tempo di elaborazione dato che i router non hanno più la necessità
   di ricalcolare la checksum ad ogni passaggio di un pacchetto per il
   cambiamento del campo \textit{hop limit}.
-\item è stato eliminato il campo \textit{type of service}, che praticamente
-  non è mai stato utilizzato; una parte delle funzionalità ad esso delegate
+\item è stato eliminato il campo \textit{type of service}, che praticamente
+  non è mai stato utilizzato; una parte delle funzionalità ad esso delegate
   sono state reimplementate (vedi il campo \textit{priority} al prossimo
   punto) con altri metodi.
-\item è stato introdotto un nuovo campo \textit{flow label}, che viene usato,
+\item è stato introdotto un nuovo campo \textit{flow label}, che viene usato,
   insieme al campo \textit{priority} (che recupera i bit di precedenza del
   campo \textit{type of service}) per implementare la gestione di una
-  ``\textsl{qualità di servizio}'' (vedi sez.~\ref{sec:IP_ipv6_qos}) che
+  ``\textsl{qualità di servizio}'' (vedi sez.~\ref{sec:IP_ipv6_qos}) che
   permette di identificare i pacchetti appartenenti a un ``\textsl{flusso}''
-  di dati per i quali si può provvedere un trattamento speciale.
+  di dati per i quali si può provvedere un trattamento speciale.
 \end{itemize}
 
 Oltre alle differenze precedenti, relative ai singoli campi nell'intestazione,
@@ -602,60 +602,60 @@ ulteriori caratteristiche che diversificano il comportamento di IPv4 da
 quello di IPv6 sono le seguenti:
 
 \begin{itemize}
-\item il \itindex{broadcast} \textit{broadcasting} non è previsto in IPv6, le
+\item il \itindex{broadcast} \textit{broadcasting} non è previsto in IPv6, le
   applicazioni che lo usano dovono essere reimplementate usando il
   \itindex{multicast} \textit{multicasting} (vedi
   sez.~\ref{sec:IP_ipv6_multicast}), che da opzionale diventa obbligatorio.
-\item è stato introdotto un nuovo tipo di indirizzi, gli \textit{anycast}.
-\item i router non possono più frammentare i pacchetti lungo il cammino, la
-  frammentazione di pacchetti troppo grandi potrà essere gestita solo ai
+\item è stato introdotto un nuovo tipo di indirizzi, gli \textit{anycast}.
+\item i router non possono più frammentare i pacchetti lungo il cammino, la
+  frammentazione di pacchetti troppo grandi potrà essere gestita solo ai
   capi della comunicazione (usando un'apposita estensione vedi
   sez.~\ref{sec:IP_ipv6_extens}).
 \item IPv6 richiede il supporto per il \itindex{Maximum~Transfer~Unit}
-  \textit{path MTU discovery} (cioè il protocollo per la selezione della
+  \textit{path MTU discovery} (cioè il protocollo per la selezione della
   massima lunghezza del pacchetto); seppure questo sia in teoria opzionale,
-  senza di esso non sarà possibile inviare pacchetti più larghi della
+  senza di esso non sarà possibile inviare pacchetti più larghi della
   dimensione minima (576 byte).
 \end{itemize}
 
 \subsection{Gli indirizzi di IPv6}
 \label{sec:IP_ipv6_addr}
 
-Come già abbondantemente anticipato la principale novità di IPv6 è
+Come già abbondantemente anticipato la principale novità di IPv6 è
 costituita dall'ampliamento dello spazio degli indirizzi, che consente di avere
 indirizzi disponibili in un numero dell'ordine di quello degli atomi che
 costituiscono la terra. 
 
-In realtà l'allocazione di questi indirizzi deve tenere conto della
-necessità di costruire delle gerarchie che consentano un instradamento
-rapido ed efficiente dei pacchetti, e flessibilità nel dispiegamento delle
+In realtà l'allocazione di questi indirizzi deve tenere conto della
+necessità di costruire delle gerarchie che consentano un instradamento
+rapido ed efficiente dei pacchetti, e flessibilità nel dispiegamento delle
 reti, il che comporta una riduzione drastica dei numeri utilizzabili; uno
 studio sull'efficienza dei vari sistemi di allocazione usati in altre
-architetture (come i sistemi telefonici) è comunque giunto alla conclusione
+architetture (come i sistemi telefonici) è comunque giunto alla conclusione
 che anche nella peggiore delle ipotesi IPv6 dovrebbe essere in grado di
-fornire più di un migliaio di indirizzi per ogni metro quadro della
+fornire più di un migliaio di indirizzi per ogni metro quadro della
 superficie terrestre.
 
 
 \subsection{La notazione}
 \label{sec:IP_ipv6_notation}
-Con un numero di bit quadruplicato non è più possibile usare la notazione
+Con un numero di bit quadruplicato non è più possibile usare la notazione
 coi numeri decimali di IPv4 per rappresentare un numero IP. Per questo gli
 indirizzi di IPv6 sono in genere scritti come sequenze di otto numeri
-esadecimali di 4 cifre (cioè a gruppi di 16 bit) usando i due punti come
-separatore; cioè qualcosa del tipo
+esadecimali di 4 cifre (cioè a gruppi di 16 bit) usando i due punti come
+separatore; cioè qualcosa del tipo
 \texttt{5f1b:df00:ce3e:e200:0020:0800:2078:e3e3}.
 
 
 Visto che la notazione resta comunque piuttosto pesante esistono alcune
-abbreviazioni; si può evitare di scrivere gli zeri iniziali per cui si
-può scrivere \texttt{1080:0:0:0:8:800:ba98:2078:e3e3}; se poi un intero è
-zero si può omettere del tutto, così come un insieme di zeri (ma questo
-solo una volta per non generare ambiguità) per cui il precedente indirizzo
-si può scrivere anche come \texttt{1080::8:800:ba98:2078:e3e3}.
+abbreviazioni; si può evitare di scrivere gli zeri iniziali per cui si
+può scrivere \texttt{1080:0:0:0:8:800:ba98:2078:e3e3}; se poi un intero è
+zero si può omettere del tutto, così come un insieme di zeri (ma questo
+solo una volta per non generare ambiguità) per cui il precedente indirizzo
+si può scrivere anche come \texttt{1080::8:800:ba98:2078:e3e3}.
 
 Infine per scrivere un indirizzo IPv4 all'interno di un indirizzo IPv6 si
-può usare la vecchia notazione con i punti, per esempio
+può usare la vecchia notazione con i punti, per esempio
 \texttt{::192.84.145.138}.
 
 \begin{table}[htb]
@@ -697,7 +697,7 @@ pu
     \textit{multicast} & \texttt{1111 1111} & 1/256 \\
     \hline
   \end{tabular}
-  \caption{Classificazione degli indirizzi IPv6 a seconda dei bit più 
+  \caption{Classificazione degli indirizzi IPv6 a seconda dei bit più 
     significativi}
   \label{tab:IP_ipv6addr}
 \end{table}
@@ -711,14 +711,14 @@ Come per IPv4 gli indirizzi sono identificatori per una singola (indirizzi
 \textit{multicast} e \textit{anycast}) di interfacce di rete.
 
 Gli indirizzi sono sempre assegnati all'interfaccia, non al nodo che la
-ospita; dato che ogni interfaccia appartiene ad un nodo quest'ultimo può
+ospita; dato che ogni interfaccia appartiene ad un nodo quest'ultimo può
 essere identificato attraverso uno qualunque degli indirizzi unicast delle sue
-interfacce. A una interfaccia possono essere associati anche più indirizzi.
+interfacce. A una interfaccia possono essere associati anche più indirizzi.
 
 IPv6 presenta tre tipi diversi di indirizzi: due di questi, gli indirizzi
 \textit{unicast} e \itindex{multicast} \textit{multicast} hanno le stesse
-caratteristiche che in IPv4, un terzo tipo, gli indirizzi \textit{anycast} è
-completamente nuovo.  In IPv6 non esistono più gli indirizzi
+caratteristiche che in IPv4, un terzo tipo, gli indirizzi \textit{anycast} è
+completamente nuovo.  In IPv6 non esistono più gli indirizzi
 \itindex{broadcast} \textit{broadcast}, la funzione di questi ultimi deve
 essere reimplementata con gli indirizzi \itindex{multicast}
 \textit{multicast}.
@@ -726,21 +726,21 @@ essere reimplementata con gli indirizzi \itindex{multicast}
 Gli indirizzi \textit{unicast} identificano una singola interfaccia: i
 pacchetti mandati ad un tale indirizzo verranno inviati a quella interfaccia,
 gli indirizzi \textit{anycast} identificano un gruppo di interfacce tale che
-un pacchetto mandato a uno di questi indirizzi viene inviato alla più vicina
+un pacchetto mandato a uno di questi indirizzi viene inviato alla più vicina
 (nel senso di distanza di routing) delle interfacce del gruppo, gli indirizzi
 \itindex{multicast} \textit{multicast} identificano un gruppo di interfacce
 tale che un pacchetto mandato a uno di questi indirizzi viene inviato a tutte
 le interfacce del gruppo.
 
-In IPv6 non ci sono più le classi ma i bit più significativi indicano il tipo
+In IPv6 non ci sono più le classi ma i bit più significativi indicano il tipo
 di indirizzo; in tab.~\ref{tab:IP_ipv6addr} sono riportati i valori di detti
-bit e il tipo di indirizzo che loro corrispondente.  I bit più significativi
-costituiscono quello che viene chiamato il \textit{format prefix} ed è sulla
+bit e il tipo di indirizzo che loro corrispondente.  I bit più significativi
+costituiscono quello che viene chiamato il \textit{format prefix} ed è sulla
 base di questo che i vari tipi di indirizzi vengono identificati.  Come si
 vede questa architettura di allocazione supporta l'allocazione di indirizzi
 per i provider, per uso locale e per il \itindex{multicast}
-\textit{multicast}; inoltre è stato riservato lo spazio per indirizzi NSAP,
-IPX e per le connessioni; gran parte dello spazio (più del 70\%) è riservato
+\textit{multicast}; inoltre è stato riservato lo spazio per indirizzi NSAP,
+IPX e per le connessioni; gran parte dello spazio (più del 70\%) è riservato
 per usi futuri.
 
 Si noti infine che gli indirizzi \textit{anycast} non sono riportati in
@@ -755,10 +755,10 @@ comunicazioni globali, questi sono definiti
 nell'\href{http://www.ietf.org/rfc/rfc2073.txt}{RFC~2073} e sono gli
 equivalenti degli attuali indirizzi delle classi da A a C.
 
-L'autorità che presiede all'allocazione di questi indirizzi è la IANA; per
+L'autorità che presiede all'allocazione di questi indirizzi è la IANA; per
 evitare i problemi di crescita delle tabelle di instradamento e una procedura
-efficiente di allocazione la struttura di questi indirizzi è organizzata fin
-dall'inizio in maniera gerarchica; pertanto lo spazio di questi indirizzi è
+efficiente di allocazione la struttura di questi indirizzi è organizzata fin
+dall'inizio in maniera gerarchica; pertanto lo spazio di questi indirizzi è
 stato suddiviso in una serie di campi secondo lo schema riportato in
 tab.~\ref{tab:IP_ipv6_unicast}.
 
@@ -785,12 +785,12 @@ tab.~\ref{tab:IP_ipv6_unicast}.
 \label{tab:IP_ipv6_unicast}
 \end{table}
 
-Al livello più alto la IANA può delegare l'allocazione a delle autorità
+Al livello più alto la IANA può delegare l'allocazione a delle autorità
 regionali (i Regional Register) assegnando ad esse dei blocchi di indirizzi; a
-queste autorità regionali è assegnato un Registry Id che deve seguire
+queste autorità regionali è assegnato un Registry Id che deve seguire
 immediatamente il prefisso di formato. Al momento sono definite tre registri
-regionali (INTERNIC, RIPE NCC e APNIC), inoltre la IANA si è riservata la
-possibilità di allocare indirizzi su base regionale; pertanto sono previsti
+regionali (INTERNIC, RIPE NCC e APNIC), inoltre la IANA si è riservata la
+possibilità di allocare indirizzi su base regionale; pertanto sono previsti
 i seguenti possibili valori per il \textsl{Registry Id};
 gli altri valori restano riservati per la IANA.
 \begin{table}[htb]
@@ -818,15 +818,15 @@ servizi, e \textit{Subscriber Id}, che identifica i fruitori, sia gestita dai
 singoli registri regionali. Questi ultimi dovranno definire come dividere lo
 spazio di indirizzi assegnato a questi due campi (che ammonta a un totale di
 56~bit), definendo lo spazio da assegnare al \textit{Provider Id} e
-al \textit{Subscriber Id}, ad essi spetterà inoltre anche l'allocazione dei
-numeri di \textit{Provider Id} ai singoli fornitori, ai quali sarà delegata
-l'autorità di allocare i \textit{Subscriber Id} al loro interno.
+al \textit{Subscriber Id}, ad essi spetterà inoltre anche l'allocazione dei
+numeri di \textit{Provider Id} ai singoli fornitori, ai quali sarà delegata
+l'autorità di allocare i \textit{Subscriber Id} al loro interno.
 
-L'ultimo livello è quello \textit{Intra-subscriber} che è lasciato alla
+L'ultimo livello è quello \textit{Intra-subscriber} che è lasciato alla
 gestione dei singoli fruitori finali, gli indirizzi \textit{provider-based}
 lasciano normalmente gli ultimi 64~bit a disposizione per questo livello, la
-modalità più immediata è quella di usare uno schema del tipo mostrato in
-tab.~\ref{tab:IP_ipv6_uninterf} dove l'\textit{Interface Id} è dato dal
+modalità più immediata è quella di usare uno schema del tipo mostrato in
+tab.~\ref{tab:IP_ipv6_uninterf} dove l'\textit{Interface Id} è dato dal
 MAC-address a 48~bit dello standard Ethernet, scritto in genere nell'hardware
 delle scheda di rete, e si usano i restanti 16~bit per indicare la sottorete.
 
@@ -849,19 +849,19 @@ delle scheda di rete, e si usano i restanti 16~bit per indicare la sottorete.
 \label{tab:IP_ipv6_uninterf}
 \end{table}
 
-Qualora si dovesse avere a che fare con una necessità di un numero più
+Qualora si dovesse avere a che fare con una necessità di un numero più
 elevato di sotto-reti, il precedente schema andrebbe modificato, per evitare
 l'enorme spreco dovuto all'uso dei MAC-address, a questo scopo si possono
-usare le capacità di auto-configurazione di IPv6 per assegnare indirizzi
+usare le capacità di auto-configurazione di IPv6 per assegnare indirizzi
 generici con ulteriori gerarchie per sfruttare efficacemente tutto lo spazio
 di indirizzi.
 
-Un registro regionale può introdurre un ulteriore livello nella gerarchia
-degli indirizzi, allocando dei blocchi per i quali delegare l'autorità a dei
+Un registro regionale può introdurre un ulteriore livello nella gerarchia
+degli indirizzi, allocando dei blocchi per i quali delegare l'autorità a dei
 registri nazionali, quest'ultimi poi avranno il compito di gestire la
 attribuzione degli indirizzi per i fornitori di servizi nell'ambito del/i
-paese coperto dal registro nazionale con le modalità viste in precedenza.
-Una tale ripartizione andrà effettuata all'interno dei soliti 56~bit come
+paese coperto dal registro nazionale con le modalità viste in precedenza.
+Una tale ripartizione andrà effettuata all'interno dei soliti 56~bit come
 mostrato in tab.~\ref{tab:IP_ipv6_uninaz}.
 
 \begin{table}[htb]
@@ -895,7 +895,7 @@ mostrato in tab.~\ref{tab:IP_ipv6_uninaz}.
 
 Gli indirizzi ad uso locale sono indirizzi unicast che sono instradabili solo
 localmente (all'interno di un sito o di una sottorete), e possono avere una
-unicità locale o globale.
+unicità locale o globale.
 
 Questi indirizzi sono pensati per l'uso all'interno di un sito per mettere su
 una comunicazione locale immediata, o durante le fasi di auto-configurazione
@@ -920,22 +920,22 @@ prima di avere un indirizzo globale.
 \end{table}
 
 Ci sono due tipi di indirizzi, \textit{link-local} e \textit{site-local}. Il
-primo è usato per un singolo link; la struttura è mostrata in
+primo è usato per un singolo link; la struttura è mostrata in
 tab.~\ref{tab:IP_ipv6_linklocal}, questi indirizzi iniziano sempre con un
 valore nell'intervallo \texttt{FE80}--\texttt{FEBF} e vengono in genere usati
 per la configurazione automatica dell'indirizzo al bootstrap e per la ricerca
 dei vicini (vedi \ref{sec:IP_ipv6_autoconf}); un pacchetto che abbia tale
 indirizzo come sorgente o destinazione non deve venire ritrasmesso dai router.
 
-Un indirizzo \textit{site-local} invece è usato per l'indirizzamento
+Un indirizzo \textit{site-local} invece è usato per l'indirizzamento
 all'interno di un sito che non necessita di un prefisso globale; la struttura
-è mostrata in tab.~\ref{tab:IP_ipv6_sitelocal}, questi indirizzi iniziano
+è mostrata in tab.~\ref{tab:IP_ipv6_sitelocal}, questi indirizzi iniziano
 sempre con un valore nell'intervallo \texttt{FEC0}--\texttt{FEFF} e non devono
 venire ritrasmessi dai router all'esterno del sito stesso; sono in sostanza
 gli equivalenti degli indirizzi riservati per reti private definiti su IPv4.
-Per entrambi gli indirizzi il campo \textit{Interface Id} è un identificatore
+Per entrambi gli indirizzi il campo \textit{Interface Id} è un identificatore
 che deve essere unico nel dominio in cui viene usato, un modo immediato per
-costruirlo è quello di usare il MAC-address delle schede di rete.
+costruirlo è quello di usare il MAC-address delle schede di rete.
  
 \begin{table}[!h]
   \centering
@@ -957,7 +957,7 @@ costruirlo 
 \label{tab:IP_ipv6_sitelocal}
 \end{table}
 
-Gli indirizzi di uso locale consentono ad una organizzazione che non è
+Gli indirizzi di uso locale consentono ad una organizzazione che non è
 (ancora) connessa ad Internet di operare senza richiedere un prefisso globale,
 una volta che in seguito l'organizzazione venisse connessa a Internet
 potrebbe continuare a usare la stessa suddivisione effettuata con gli
@@ -968,7 +968,7 @@ rinumerazione degli indirizzi delle singole macchine sarebbe automatica.
 \label{sec:IP_ipv6_reserved}
 
 Alcuni indirizzi sono riservati per scopi speciali, in particolare per scopi
-di compatibilità.
+di compatibilità.
 
 Un primo tipo sono gli indirizzi \textit{IPv4 mappati su IPv6} (mostrati in
 tab.~\ref{tab:IP_ipv6_map}), questo sono indirizzi unicast che vengono usati
@@ -997,11 +997,11 @@ che IPv6 siano supportati sull'host di origine).
 \label{tab:IP_ipv6_map}
 \end{table}
 
-Un secondo tipo di indirizzi di compatibilità sono gli \textsl{IPv4
+Un secondo tipo di indirizzi di compatibilità sono gli \textsl{IPv4
   compatibili IPv6} (vedi tab.~\ref{tab:IP_ipv6_comp}) usati nella transizione
 da IPv4 a IPv6: quando un nodo che supporta sia IPv6 che IPv4 non ha un router
 IPv6 deve usare nel DNS un indirizzo di questo tipo, ogni pacchetto IPv6
-inviato a un tale indirizzo verrà automaticamente incapsulato in IPv4.
+inviato a un tale indirizzo verrà automaticamente incapsulato in IPv4.
 
 \begin{table}[htb]
   \centering
@@ -1023,8 +1023,8 @@ inviato a un tale indirizzo verr
 \end{table}
 
 Altri indirizzi speciali sono il \textit{loopback address}, costituito da 127
-zeri ed un uno (cioè \texttt{::1}) e l'\textsl{indirizzo generico}
-costituito da tutti zeri (scritto come \texttt{0::0} o ancora più
+zeri ed un uno (cioè \texttt{::1}) e l'\textsl{indirizzo generico}
+costituito da tutti zeri (scritto come \texttt{0::0} o ancora più
 semplicemente come \texttt{:}) usato in genere quando si vuole indicare
 l'accettazione di una connessione da qualunque host.
 
@@ -1036,8 +1036,8 @@ l'accettazione di una connessione da qualunque host.
 Gli indirizzi \textit{multicast} sono usati per inviare un pacchetto a un
 gruppo di interfacce; l'indirizzo identifica uno specifico gruppo di
 \textit{multicast} e il pacchetto viene inviato a tutte le interfacce di detto
-gruppo.  Un'interfaccia può appartenere ad un numero qualunque numero di
-gruppi di \textit{multicast}. Il formato degli indirizzi \textit{multicast} è
+gruppo.  Un'interfaccia può appartenere ad un numero qualunque numero di
+gruppi di \textit{multicast}. Il formato degli indirizzi \textit{multicast} è
 riportato in tab.~\ref{tab:IP_ipv6_multicast}:
 
 \begin{table}[htb]
@@ -1060,16 +1060,16 @@ riportato in tab.~\ref{tab:IP_ipv6_multicast}:
 \label{tab:IP_ipv6_multicast}
 \end{table}
 
-Il prefisso di formato per tutti gli indirizzi \textit{multicast} è
-\texttt{FF}, ad esso seguono i due campi il cui significato è il seguente:
+Il prefisso di formato per tutti gli indirizzi \textit{multicast} è
+\texttt{FF}, ad esso seguono i due campi il cui significato è il seguente:
 
 \begin{itemize}
 \item \textsl{flag}: un insieme di 4 bit, di cui i primi tre sono riservati e
-  posti a zero, l'ultimo è zero se l'indirizzo è permanente (cioè un
-  indirizzo noto, assegnato dalla IANA), ed è uno se invece l'indirizzo è
+  posti a zero, l'ultimo è zero se l'indirizzo è permanente (cioè un
+  indirizzo noto, assegnato dalla IANA), ed è uno se invece l'indirizzo è
   transitorio.
-\item \textsl{scop} è un numero di quattro bit che indica il raggio di
-  validità dell'indirizzo, i valori assegnati per ora sono riportati in
+\item \textsl{scop} è un numero di quattro bit che indica il raggio di
+  validità dell'indirizzo, i valori assegnati per ora sono riportati in
   tab.~\ref{tab:IP_ipv6_multiscope}.
 \end{itemize}
 
@@ -1099,9 +1099,9 @@ Il prefisso di formato per tutti gli indirizzi \textit{multicast} 
 \end{table}
 
 Infine l'ultimo campo identifica il gruppo di \textit{multicast}, sia
-permanente che transitorio, all'interno del raggio di validità del medesimo.
+permanente che transitorio, all'interno del raggio di validità del medesimo.
 Alcuni indirizzi \textit{multicast}, riportati in tab.~\ref{tab:multiadd} sono
-già riservati per il funzionamento della rete.
+già riservati per il funzionamento della rete.
 
 \begin{table}[!htb]
   \centering 
@@ -1132,7 +1132,7 @@ gi
 \end{table}
 
 L'utilizzo del campo di \textit{scope} e di questi indirizzi predefiniti serve
-a recuperare le funzionalità del \itindex{broadcast} \textit{broadcasting} (ad
+a recuperare le funzionalità del \itindex{broadcast} \textit{broadcasting} (ad
 esempio inviando un pacchetto all'indirizzo \texttt{FF02:0:0:0:0:0:0:1} si
 raggiungono tutti i nodi locali).
 
@@ -1143,18 +1143,18 @@ raggiungono tutti i nodi locali).
 
 Gli indirizzi \textit{anycast} sono indirizzi che vengono assegnati ad un
 gruppo di interfacce: un pacchetto indirizzato a questo tipo di indirizzo
-viene inviato al componente del gruppo più ``\textsl{vicino}'' secondo la
+viene inviato al componente del gruppo più ``\textsl{vicino}'' secondo la
 distanza di instradamento calcolata dai router.
 
 Questi indirizzi sono allocati nello stesso spazio degli indirizzi unicast,
 usando uno dei formati disponibili, e per questo, sono da essi assolutamente
-indistinguibili. Quando un indirizzo unicast viene assegnato a più interfacce
-(trasformandolo in un anycast) il computer su cui è l'interfaccia deve essere
+indistinguibili. Quando un indirizzo unicast viene assegnato a più interfacce
+(trasformandolo in un anycast) il computer su cui è l'interfaccia deve essere
 configurato per tener conto del fatto.
 
 Gli indirizzi anycast consentono a un nodo sorgente di inviare pacchetti a una
 destinazione su un gruppo di possibili interfacce selezionate. La sorgente non
-deve curarsi di come scegliere l'interfaccia più vicina, compito che tocca al
+deve curarsi di come scegliere l'interfaccia più vicina, compito che tocca al
 sistema di instradamento (in sostanza la sorgente non ha nessun controllo
 sulla selezione).
 
@@ -1168,26 +1168,26 @@ intestazione di instradamento o per identificare insiemi di router connessi a
 una particolare sottorete, o che forniscono l'accesso a un certo sotto
 dominio.
 
-L'idea alla base degli indirizzi anycast è perciò quella di utilizzarli per
-poter raggiungere il fornitore di servizio più vicino; ma restano aperte tutta
+L'idea alla base degli indirizzi anycast è perciò quella di utilizzarli per
+poter raggiungere il fornitore di servizio più vicino; ma restano aperte tutta
 una serie di problematiche, visto che una connessione con uno di questi
-indirizzi non è possibile, dato che per una variazione delle distanze di
-routing non è detto che due pacchetti successivi finiscano alla stessa
+indirizzi non è possibile, dato che per una variazione delle distanze di
+routing non è detto che due pacchetti successivi finiscano alla stessa
 interfaccia.
 
-La materia è pertanto ancora controversa e in via di definizione.
+La materia è pertanto ancora controversa e in via di definizione.
 
 
 \subsection{Le estensioni}
 \label{sec:IP_ipv6_extens}
 
-Come già detto in precedenza IPv6 ha completamente cambiato il trattamento
+Come già detto in precedenza IPv6 ha completamente cambiato il trattamento
 delle opzioni; queste ultime infatti sono state tolte dall'intestazione del
 pacchetto, e poste in apposite \textsl{intestazioni di estensione} (o
 \textit{extension header}) poste fra l'intestazione di IPv6 e l'intestazione
 del protocollo di trasporto.
 
-Per aumentare la velocità di elaborazione, sia dei dati del livello seguente
+Per aumentare la velocità di elaborazione, sia dei dati del livello seguente
 che di ulteriori opzioni, ciascuna estensione deve avere una lunghezza
 multipla di 8 byte per mantenere l'allineamento a 64~bit di tutti le
 intestazioni seguenti.
@@ -1198,7 +1198,7 @@ alla destinazione finale, questa scelta ha consentito un miglioramento delle
 prestazioni rispetto a IPv4 dove la presenza di un'opzione comportava l'esame
 di tutte quante.
 
-Un secondo miglioramento è che rispetto a IPv4 le opzioni possono essere di
+Un secondo miglioramento è che rispetto a IPv4 le opzioni possono essere di
 lunghezza arbitraria e non limitate a 40 byte; questo, insieme al modo in cui
 vengono trattate, consente di utilizzarle per scopi come l'autenticazione e la
 sicurezza, improponibili con IPv4.
@@ -1207,30 +1207,30 @@ Le estensioni definite al momento sono le seguenti:
 \begin{itemize}
 \item \textbf{Hop by hop} devono seguire immediatamente l'intestazione
   principale; indicano le opzioni che devono venire processate ad ogni
-  passaggio da un router, fra di esse è da menzionare la \textit{jumbo
+  passaggio da un router, fra di esse è da menzionare la \textit{jumbo
     payload} che segnala la presenza di un pacchetto di dati di dimensione
   superiore a 65535 byte.
 \item \textbf{Destination options} opzioni che devono venire esaminate al nodo
-  di ricevimento, nessuna di esse è tuttora definita.
+  di ricevimento, nessuna di esse è tuttora definita.
 \item \textbf{Routing} definisce una \textit{source route} (come la analoga
-  opzione di IPv4) cioè una lista di indirizzi IP di nodi per i quali il
+  opzione di IPv4) cioè una lista di indirizzi IP di nodi per i quali il
   pacchetto deve passare. 
 \item \textbf{Fragmentation} viene generato automaticamente quando un host
-  vuole frammentare un pacchetto, ed è riprocessato automaticamente alla
+  vuole frammentare un pacchetto, ed è riprocessato automaticamente alla
   destinazione che riassembla i frammenti.
 \item \textbf{Authentication} gestisce l'autenticazione e il controllo di
-  integrità dei pacchetti; è documentato
+  integrità dei pacchetti; è documentato
   dall'\href{http://www.ietf.org/rfc/rfc1826.txt}{RFC~1826}.
 \item \textbf{Encapsulation} serve a gestire la segretezza del contenuto
-  trasmesso; è documentato
+  trasmesso; è documentato
   dall'\href{http://www.ietf.org/rfc/rfc1827.txt}{RFC~1827}.
 \end{itemize}
 
-La presenza di opzioni è rilevata dal valore del campo \textit{next header}
-che indica qual è l'intestazione successiva a quella di IPv6; in assenza di
-opzioni questa sarà l'intestazione di un protocollo di trasporto del livello
-superiore, per cui il campo assumerà lo stesso valore del campo
-\textit{protocol} di IPv4, altrimenti assumerà il valore dell'opzione
+La presenza di opzioni è rilevata dal valore del campo \textit{next header}
+che indica qual è l'intestazione successiva a quella di IPv6; in assenza di
+opzioni questa sarà l'intestazione di un protocollo di trasporto del livello
+superiore, per cui il campo assumerà lo stesso valore del campo
+\textit{protocol} di IPv4, altrimenti assumerà il valore dell'opzione
 presente; i valori possibili sono riportati in
 tab.~\ref{tab:IP_ipv6_nexthead}.
 
@@ -1267,67 +1267,67 @@ tab.~\ref{tab:IP_ipv6_nexthead}.
   \end{center}
 \end{table}
 
-Questo meccanismo permette la presenza di più opzioni in successione prima
+Questo meccanismo permette la presenza di più opzioni in successione prima
 del pacchetto del protocollo di trasporto; l'ordine raccomandato per le
-estensioni è quello riportato nell'elenco precedente con la sola differenza
+estensioni è quello riportato nell'elenco precedente con la sola differenza
 che le opzioni di destinazione sono inserite nella posizione ivi indicata solo
 se, come per il tunnelling, devono essere esaminate dai router, quelle che
 devono essere esaminate solo alla destinazione finale vanno in coda.
 
 
-\subsection{Qualità di servizio}
+\subsection{Qualità di servizio}
 \label{sec:IP_ipv6_qos}
 
-Una delle caratteristiche innovative di IPv6 è quella di avere introdotto un
-supporto per la qualità di servizio che è importante per applicazioni come
+Una delle caratteristiche innovative di IPv6 è quella di avere introdotto un
+supporto per la qualità di servizio che è importante per applicazioni come
 quelle multimediali o ``real-time'' che richiedono un qualche grado di
-controllo sulla stabilità della banda di trasmissione, sui ritardi o la
+controllo sulla stabilità della banda di trasmissione, sui ritardi o la
 dispersione dei temporale del flusso dei pacchetti.
 
 
 \subsection{Etichette di flusso}
 \label{sec:IP_ipv6_flow}
-L'introduzione del campo \textit{flow label} può essere usata dall'origine
+L'introduzione del campo \textit{flow label} può essere usata dall'origine
 della comunicazione per etichettare quei pacchetti per i quali si vuole un
 trattamento speciale da parte dei router come un una garanzia di banda minima
 assicurata o un tempo minimo di instradamento/trasmissione garantito.
 
-Questo aspetto di IPv6 è ancora sperimentale per cui i router che non
+Questo aspetto di IPv6 è ancora sperimentale per cui i router che non
 supportino queste funzioni devono porre a zero il \textit{flow label} per i
 pacchetti da loro originanti e lasciare invariato il campo per quelli in
 transito.
 
-Un flusso è una sequenza di pacchetti da una particolare origine a una
+Un flusso è una sequenza di pacchetti da una particolare origine a una
 particolare destinazione per il quale l'origine desidera un trattamento
 speciale da parte dei router che lo manipolano; la natura di questo
-trattamento può essere comunicata ai router in vari modi (come un protocollo
+trattamento può essere comunicata ai router in vari modi (come un protocollo
 di controllo o con opzioni del tipo \textit{hop-by-hop}). 
 
-Ci possono essere più flussi attivi fra un'origine e una destinazione, come
+Ci possono essere più flussi attivi fra un'origine e una destinazione, come
 del traffico non assegnato a nessun flusso, un flusso viene identificato
 univocamente dagli indirizzi di origine e destinazione e da una etichetta di
 flusso diversa da zero, il traffico normale deve avere l'etichetta di flusso
 posta a zero.
 
-L'etichetta di flusso è assegnata dal nodo di origine, i valori devono
+L'etichetta di flusso è assegnata dal nodo di origine, i valori devono
 essere scelti in maniera (pseudo)casuale nel range fra 1 e FFFFFF in modo da
 rendere utilizzabile un qualunque sottoinsieme dei bit come chiavi di hash per
 i router.
 
-\subsection{Priorità}
+\subsection{Priorità}
 \label{sec:IPv6_prio}
 
-Il campo di priorità consente di indicare il livello di priorità dei
+Il campo di priorità consente di indicare il livello di priorità dei
 pacchetti relativamente agli altri pacchetti provenienti dalla stessa
 sorgente. I valori sono divisi in due intervalli, i valori da 0 a 7 sono usati
-per specificare la priorità del traffico per il quale la sorgente provvede
-un controllo di congestione cioè per il traffico che può essere ``tirato
+per specificare la priorità del traffico per il quale la sorgente provvede
+un controllo di congestione cioè per il traffico che può essere ``tirato
 indietro'' in caso di congestione come quello di TCP, i valori da 8 a 15 sono
 usati per i pacchetti che non hanno questa caratteristica, come i pacchetti
 ``real-time'' inviati a ritmo costante.
 
 Per il traffico con controllo di congestione sono raccomandati i seguenti
-valori di priorità a seconda del tipo di applicazione:
+valori di priorità a seconda del tipo di applicazione:
 
 \begin{table}[htb]
   \centering
@@ -1349,9 +1349,9 @@ valori di priorit
 \label{tab:priority}
 \end{table}
 
-Per il traffico senza controllo di congestione la priorità più bassa
+Per il traffico senza controllo di congestione la priorità più bassa
 dovrebbe essere usata per quei pacchetti che si preferisce siano scartati
-più facilmente in caso di congestione.
+più facilmente in caso di congestione.
 
 
 \subsection{Sicurezza a livello IP}
@@ -1359,43 +1359,43 @@ pi
 
 La attuale implementazione di Internet presenta numerosi problemi di
 sicurezza, in particolare i dati presenti nelle intestazioni dei vari
-protocolli sono assunti essere corretti, il che da adito alla possibilità di
+protocolli sono assunti essere corretti, il che da adito alla possibilità di
 varie tipologie di attacco forgiando pacchetti false, inoltre tutti questi
 dati passano in chiaro sulla rete e sono esposti all'osservazione di chiunque
 si trovi in mezzo.
 
-Con IPv4 non è possibile realizzare un meccanismo di autenticazione e
+Con IPv4 non è possibile realizzare un meccanismo di autenticazione e
 riservatezza a un livello inferiore al primo (quello di applicazione), con
-IPv6 è stato progettata la possibilità di intervenire al livello di rete (il
+IPv6 è stato progettata la possibilità di intervenire al livello di rete (il
 terzo) prevedendo due apposite estensioni che possono essere usate per fornire
 livelli di sicurezza a seconda degli utenti. La codifica generale di questa
-architettura è riportata
+architettura è riportata
 nell'\href{http://www.ietf.org/rfc/rfc2401.txt}{RFC~2401}.
 
 Il meccanismo in sostanza si basa su due estensioni:
 \begin{itemize}
 \item una intestazione di sicurezza (\textit{authentication header}) che
-  garantisce al destinatario l'autenticità del pacchetto
+  garantisce al destinatario l'autenticità del pacchetto
 \item un carico di sicurezza (\textit{Encrypted Security Payload}) che
-  assicura che solo il legittimo ricevente può leggere il pacchetto.
+  assicura che solo il legittimo ricevente può leggere il pacchetto.
 \end{itemize}
 
-Perché tutto questo funzioni le stazioni sorgente e destinazione devono
+Perché tutto questo funzioni le stazioni sorgente e destinazione devono
 usare una stessa chiave crittografica e gli stessi algoritmi, l'insieme degli
 accordi fra le due stazioni per concordare chiavi e algoritmi usati va sotto
 il nome di associazione di sicurezza.
 
 I pacchetti autenticati e crittografati portano un indice dei parametri di
 sicurezza (SPI, \textit{Security Parameter Index}) che viene negoziato prima
-di ogni comunicazione ed è definito dalla stazione sorgente. Nel caso di
-\textit{multicast} dovrà essere lo stesso per tutte le stazioni del gruppo.
+di ogni comunicazione ed è definito dalla stazione sorgente. Nel caso di
+\textit{multicast} dovrà essere lo stesso per tutte le stazioni del gruppo.
 
 \subsection{Autenticazione}
 \label{sec:auth} 
 
-Il primo meccanismo di sicurezza è quello dell'intestazione di autenticazione
+Il primo meccanismo di sicurezza è quello dell'intestazione di autenticazione
 (\textit{authentication header}) che fornisce l'autenticazione e il controllo
-di integrità (ma senza riservatezza) dei pacchetti IP.
+di integrità (ma senza riservatezza) dei pacchetti IP.
 
 L'intestazione di autenticazione ha il formato descritto in
 fig.~\ref{fig:autent_estens}: il campo \textit{Next Header} indica
@@ -1407,10 +1407,10 @@ stabilito nella associazione di sicurezza, e un numero di sequenza che la
 stazione sorgente deve incrementare di pacchetto in pacchetto.
 
 Completano l'intestazione i dati di autenticazione che contengono un valore di
-controllo di integrità (ICV, \textit{Integrity Check Value}), che deve essere
-di dimensione pari a un multiplo intero di 32 bit e può contenere un padding
+controllo di integrità (ICV, \textit{Integrity Check Value}), che deve essere
+di dimensione pari a un multiplo intero di 32 bit e può contenere un padding
 per allineare l'intestazione a 64 bit. Tutti gli algoritmi di autenticazione
-devono provvedere questa capacità.
+devono provvedere questa capacità.
 
 \begin{figure}[!htb]
   \centering
@@ -1419,13 +1419,13 @@ devono provvedere questa capacit
     \label{fig:autent_estens}
 \end{figure}
 
-L'intestazione di autenticazione può essere impiegata in due modi diverse
-modalità: modalità trasporto e modalità tunnel.
+L'intestazione di autenticazione può essere impiegata in due modi diverse
+modalità: modalità trasporto e modalità tunnel.
 
-La modalità trasporto è utilizzabile solo per comunicazioni fra stazioni
+La modalità trasporto è utilizzabile solo per comunicazioni fra stazioni
 singole che supportino l'autenticazione. In questo caso l'intestazione di
-autenticazione è inserita dopo tutte le altre intestazioni di estensione
-eccezion fatta per la \textit{Destination Option} che può comparire sia
+autenticazione è inserita dopo tutte le altre intestazioni di estensione
+eccezion fatta per la \textit{Destination Option} che può comparire sia
 prima che dopo. 
 
 \begin{figure}[!htb]
@@ -1435,29 +1435,29 @@ prima che dopo.
   \label{fig:AH_autent_head}
 \end{figure}
 
-La modalità tunnel può essere utilizzata sia per comunicazioni fra stazioni
-singole che con un gateway di sicurezza; in questa modalità ...
+La modalità tunnel può essere utilizzata sia per comunicazioni fra stazioni
+singole che con un gateway di sicurezza; in questa modalità ...
 
 
-L'intestazione di autenticazione è una intestazione di estensione inserita
+L'intestazione di autenticazione è una intestazione di estensione inserita
 dopo l'intestazione principale e prima del carico dei dati. La sua presenza
-non ha perciò alcuna influenza sui livelli superiori dei protocolli di
+non ha perciò alcuna influenza sui livelli superiori dei protocolli di
 trasmissione come il TCP.
 
 
-La procedura di autenticazione cerca di garantire l'autenticità del pacchetto
+La procedura di autenticazione cerca di garantire l'autenticità del pacchetto
 nella massima estensione possibile, ma dato che alcuni campi dell'intestazione
 di IP possono variare in maniera impredicibile alla sorgente, il loro valore
-non può essere protetto dall'autenticazione.
+non può essere protetto dall'autenticazione.
 
 Il calcolo dei dati di autenticazione viene effettuato alla sorgente su una
 versione speciale del pacchetto in cui il numero di salti nell'intestazione
-principale è impostato a zero, così come le opzioni che possono essere
-modificate nella trasmissione, e l'intestazione di routing (se usata) è posta
+principale è impostato a zero, così come le opzioni che possono essere
+modificate nella trasmissione, e l'intestazione di routing (se usata) è posta
 ai valori che deve avere all'arrivo.
 
-L'estensione è indipendente dall'algoritmo particolare, e il protocollo è
-ancora in fase di definizione; attualmente è stato suggerito l'uso di una
+L'estensione è indipendente dall'algoritmo particolare, e il protocollo è
+ancora in fase di definizione; attualmente è stato suggerito l'uso di una
 modifica dell'MD5 chiamata \textit{keyed MD5} che combina alla codifica anche
 una chiave che viene inserita all'inizio e alla fine degli altri campi.
 
@@ -1465,15 +1465,15 @@ una chiave che viene inserita all'inizio e alla fine degli altri campi.
 \subsection{Riservatezza}
 \label{sec:ecry}
 
-Per garantire una trasmissione riservata dei dati, è stata previsto la
-possibilità di trasmettere pacchetti con i dati criptati: il cosiddetto ESP,
+Per garantire una trasmissione riservata dei dati, è stata previsto la
+possibilità di trasmettere pacchetti con i dati criptati: il cosiddetto ESP,
 \textit{Encripted Security Payload}. Questo viene realizzato usando con una
 apposita opzione che deve essere sempre l'ultima delle intestazioni di
 estensione; ad essa segue il carico del pacchetto che viene criptato.
 
 Un pacchetto crittografato pertanto viene ad avere una struttura del tipo di
 quella mostrata in fig.~\ref{fig:ESP_criptopack}, tutti i campi sono in chiaro
-fino al vettore di inizializzazione, il resto è crittografato.
+fino al vettore di inizializzazione, il resto è crittografato.
 
 
 
@@ -1489,42 +1489,42 @@ fino al vettore di inizializzazione, il resto 
 \subsection{Auto-configurazione}
 \label{sec:IP_ipv6_autoconf}
 
-Una delle caratteristiche salienti di IPv6 è quella dell'auto-configurazione,
-il protocollo infatti fornisce la possibilità ad un nodo di scoprire
+Una delle caratteristiche salienti di IPv6 è quella dell'auto-configurazione,
+il protocollo infatti fornisce la possibilità ad un nodo di scoprire
 automaticamente il suo indirizzo acquisendo i parametri necessari per potersi
 connettere a internet.
 
 L'auto-configurazione sfrutta gli indirizzi link-local; qualora sul nodo sia
 presente una scheda di rete che supporta lo standard IEEE802 (ethernet) questo
 garantisce la presenza di un indirizzo fisico a 48 bit unico; pertanto il nodo
-può assumere automaticamente senza pericoli di collisione l'indirizzo
-link-local \texttt{FE80::xxxx:xxxx:xxxx} dove \texttt{xxxx:xxxx:xxxx} è
+può assumere automaticamente senza pericoli di collisione l'indirizzo
+link-local \texttt{FE80::xxxx:xxxx:xxxx} dove \texttt{xxxx:xxxx:xxxx} è
 l'indirizzo hardware della scheda di rete. 
 
 Nel caso in cui non sia presente una scheda che supporta lo standard IEEE802
-allora il nodo assumerà ugualmente un indirizzo link-local della forma
-precedente, ma il valore di \texttt{xxxx:xxxx:xxxx} sarà generato
-casualmente; in questo caso la probabilità di collisione è di 1 su 300
-milioni. In ogni caso per prevenire questo rischio il nodo invierà un
+allora il nodo assumerà ugualmente un indirizzo link-local della forma
+precedente, ma il valore di \texttt{xxxx:xxxx:xxxx} sarà generato
+casualmente; in questo caso la probabilità di collisione è di 1 su 300
+milioni. In ogni caso per prevenire questo rischio il nodo invierà un
 messaggio ICMP \textit{Solicitation} all'indirizzo scelto attendendo un certo
-lasso di tempo; in caso di risposta l'indirizzo è duplicato e il
-procedimento dovrà essere ripetuto con un nuovo indirizzo (o interrotto
+lasso di tempo; in caso di risposta l'indirizzo è duplicato e il
+procedimento dovrà essere ripetuto con un nuovo indirizzo (o interrotto
 richiedendo assistenza).
 
 Una volta ottenuto un indirizzo locale valido diventa possibile per il nodo
-comunicare con la rete locale; sono pertanto previste due modalità di
+comunicare con la rete locale; sono pertanto previste due modalità di
 auto-configurazione, descritte nelle seguenti sezioni. In ogni caso
 l'indirizzo link-local resta valido.
 
 \subsection{Auto-configurazione stateless}
 \label{sec:stateless}
 
-Questa è la forma più semplice di auto-configurazione, possibile quando
-l'indirizzo globale può essere ricavato dall'indirizzo link-local cambiando
+Questa è la forma più semplice di auto-configurazione, possibile quando
+l'indirizzo globale può essere ricavato dall'indirizzo link-local cambiando
 semplicemente il prefisso a quello assegnato dal provider per ottenere un
 indirizzo globale.
 
-La procedura di configurazione è la seguente: all'avvio tutti i nodi IPv6
+La procedura di configurazione è la seguente: all'avvio tutti i nodi IPv6
 iniziano si devono aggregare al gruppo di \itindex{multicast}
 \textit{multicast} \textit{all-nodes} programmando la propria interfaccia per
 ricevere i messaggi dall'indirizzo \textit{multicast} \texttt{FF02::1} (vedi
@@ -1533,9 +1533,9 @@ ICMP \textit{Router solicitation} a tutti i router locali usando l'indirizzo
 \itindex{multicast} \textit{multicast} \texttt{FF02::2} usando come sorgente
 il proprio indirizzo link-local.
 
-Il router risponderà con un messaggio ICMP \textit{Router Advertisement} che
-fornisce il prefisso e la validità nel tempo del medesimo, questo tipo di
-messaggio può essere trasmesso anche a intervalli regolari. Il messaggio
+Il router risponderà con un messaggio ICMP \textit{Router Advertisement} che
+fornisce il prefisso e la validità nel tempo del medesimo, questo tipo di
+messaggio può essere trasmesso anche a intervalli regolari. Il messaggio
 contiene anche l'informazione che autorizza un nodo a autocostruire
 l'indirizzo, nel qual caso, se il prefisso unito all'indirizzo link-local non
 supera i 128 bit, la stazione ottiene automaticamente il suo indirizzo
@@ -1544,36 +1544,36 @@ globale.
 \subsection{Auto-configurazione stateful}
 \label{sec:stateful}
 
-Benché estremamente semplice l'auto-configurazione stateless presenta alcuni
-problemi; il primo è che l'uso degli indirizzi delle schede di rete è
+Benché estremamente semplice l'auto-configurazione stateless presenta alcuni
+problemi; il primo è che l'uso degli indirizzi delle schede di rete è
 molto inefficiente; nel caso in cui ci siano esigenze di creare una gerarchia
 strutturata su parecchi livelli possono non restare 48~bit per l'indirizzo
-della singola stazione; il secondo problema è di sicurezza, dato che basta
+della singola stazione; il secondo problema è di sicurezza, dato che basta
 introdurre in una rete una stazione autoconfigurante per ottenere un accesso
 legale.
 
-Per questi motivi è previsto anche un protocollo stateful basato su un server
+Per questi motivi è previsto anche un protocollo stateful basato su un server
 che offra una versione IPv6 del DHCP; un apposito gruppo di \textit{multicast}
-\texttt{FF02::1:0} è stato riservato per questi server; in questo caso il nodo
-interrogherà il server su questo indirizzo di \textit{multicast} con
-l'indirizzo link-local e riceverà un indirizzo unicast globale.
+\texttt{FF02::1:0} è stato riservato per questi server; in questo caso il nodo
+interrogherà il server su questo indirizzo di \textit{multicast} con
+l'indirizzo link-local e riceverà un indirizzo unicast globale.
 
 
 \section{Il protocollo ICMP}
 \label{sec:ICMP_protocol}
 
-Come già accennato nelle sezioni precedenti, l'\textit{Internet Control
-  Message Protocol} è un protocollo di servizio fondamentale per il
+Come già accennato nelle sezioni precedenti, l'\textit{Internet Control
+  Message Protocol} è un protocollo di servizio fondamentale per il
 funzionamento del livello di rete. Il protocollo ICMP viene trasportato
 direttamente su IP, ma proprio per questa sua caratteristica di protocollo di
-servizio è da considerarsi a tutti gli effetti appartenente al livello di
+servizio è da considerarsi a tutti gli effetti appartenente al livello di
 rete.
 
 \subsection{L'intestazione di ICMP}
 \label{sec:ICMP_header}
 
-Il protocollo ICMP è estremamente semplice, ed il suo unico scopo è quello di
-inviare messaggi di controllo; in fig.~\ref{fig:ICMP_header} si è riportata la
+Il protocollo ICMP è estremamente semplice, ed il suo unico scopo è quello di
+inviare messaggi di controllo; in fig.~\ref{fig:ICMP_header} si è riportata la
 struttura dell'intestazione di un pacchetto ICMP generico. 
 
 \begin{figure}[htb]
@@ -1582,7 +1582,7 @@ struttura dell'intestazione di un pacchetto ICMP generico.
   \label{fig:ICMP_header}
 \end{figure}
 
-Ciascun pacchetto ICMP è contraddistinto dal valore del primo campo, il tipo,
+Ciascun pacchetto ICMP è contraddistinto dal valore del primo campo, il tipo,
 che indica appunto che tipo di messaggio di controllo viene veicolato dal
 pacchetto in questione; i valori possibili per questo campo, insieme al
 relativo significato, sono riportati in tab.~\ref{tab:ICMP_type}.
@@ -1603,7 +1603,7 @@ relativo significato, sono riportati in tab.~\ref{tab:ICMP_type}.
                                         irraggiungibile, viene
                                         inviato all'IP sorgente di un
                                         pacchetto quando un router realizza
-                                        che questo non può essere inviato a
+                                        che questo non può essere inviato a
                                         destinazione.\\
     \textit{source-quench}          &4& Inviato in caso di congestione della
                                         rete per indicare all'IP sorgente di
@@ -1644,7 +1644,7 @@ specifica ulteriormente la natura del messaggio; i soli messaggi che
 utilizzano un valore per questo campo sono quelli di tipo
 \textit{destination-unreachable}, \textit{redirect}, \textit{time-exceeded} e
 \textit{parameter-problem}. I possibili valori del codice relativi a ciascuno
-di essi sono stati riportati nelle quattro sezioni in cui si è suddivisa
+di essi sono stati riportati nelle quattro sezioni in cui si è suddivisa
 tab.~\ref{tab:ICMP_code}, rispettivamente nell'ordine con cui sono appena
 elencati i tipi a cui essi fanno riferimento. 
 
diff --git a/network.tex b/network.tex
index 00fb841..2e322c4 100644
--- a/network.tex
+++ b/network.tex
@@ -12,16 +12,16 @@
 \chapter{Introduzione alla programmazione di rete}
 \label{cha:network}
 
-In questo capitolo sarà fatta un'introduzione ai concetti generali che servono
+In questo capitolo sarà fatta un'introduzione ai concetti generali che servono
 come prerequisiti per capire la programmazione di rete, non tratteremo quindi
-aspetti specifici ma faremo una breve introduzione al modello più comune usato
+aspetti specifici ma faremo una breve introduzione al modello più comune usato
 nella programmazione di rete, per poi passare ad un esame a grandi linee dei
 protocolli di rete e di come questi sono organizzati e interagiscono. 
 
 In particolare, avendo assunto l'ottica di un'introduzione mirata alla
-programmazione, ci concentreremo sul protocollo più diffuso, il TCP/IP, che è
+programmazione, ci concentreremo sul protocollo più diffuso, il TCP/IP, che è
 quello che sta alla base di internet, avendo cura di sottolineare i concetti
-più importanti da conoscere per la scrittura dei programmi.
+più importanti da conoscere per la scrittura dei programmi.
 
 
 
@@ -29,12 +29,12 @@ pi
 \label{sec:net_prog_model}
 
 
-La differenza principale fra un'applicazione di rete e un programma normale è
+La differenza principale fra un'applicazione di rete e un programma normale è
 che quest'ultima per definizione concerne la comunicazione fra processi
-diversi, che in generale non girano neanche sulla stessa macchina. Questo già
+diversi, che in generale non girano neanche sulla stessa macchina. Questo già
 prefigura un cambiamento completo rispetto all'ottica del programma monolitico
 all'interno del quale vengono eseguite tutte le istruzioni, e chiaramente
-presuppone un sistema operativo multitasking in grado di eseguire più processi
+presuppone un sistema operativo multitasking in grado di eseguire più processi
 contemporaneamente.
 
 In questa prima sezione esamineremo brevemente i principali modelli di
@@ -46,22 +46,22 @@ gli scopi del testo approfondire questi argomenti.
 \label{sec:net_cliserv}
 
 L'architettura fondamentale su cui si basa gran parte della programmazione di
-rete sotto Linux (e sotto Unix in generale) è il modello
+rete sotto Linux (e sotto Unix in generale) è il modello
 \textit{client-server} caratterizzato dalla presenza di due categorie di
 soggetti, i programmi di servizio, chiamati \textit{server}, che ricevono le
 richieste e forniscono le risposte, ed i programmi di utilizzo, detti
 \textit{client}.
 
-In generale un server può (di norma deve) essere in grado di rispondere a più
-di un client, per cui è possibile che molti programmi possano interagire
-contemporaneamente, quello che contraddistingue il modello però è che
-l'architettura dell'interazione è sempre nei termini di molti verso uno, il
+In generale un server può (di norma deve) essere in grado di rispondere a più
+di un client, per cui è possibile che molti programmi possano interagire
+contemporaneamente, quello che contraddistingue il modello però è che
+l'architettura dell'interazione è sempre nei termini di molti verso uno, il
 server, che viene ad assumere un ruolo privilegiato.
 
 Seguono questo modello tutti i servizi fondamentali di internet, come le
 pagine web, la posta elettronica, ftp, telnet, ssh e praticamente ogni
 servizio che viene fornito tramite la rete, anche se, come abbiamo visto, il
-modello è utilizzato in generale anche per programmi che, come gli esempi che
+modello è utilizzato in generale anche per programmi che, come gli esempi che
 abbiamo usato in cap.~\ref{cha:IPC} a proposito della comunicazione fra
 processi nello stesso sistema, non fanno necessariamente uso della rete.
 
@@ -75,7 +75,7 @@ diventa di nuovo disponibile.
 Un \textsl{server concorrente} al momento di trattare la richiesta crea un
 processo figlio (o un \itindex{thread} \textit{thread}) incaricato di fornire
 i servizi richiesti, per porsi immediatamente in attesa di ulteriori
-richieste. In questo modo, con sistemi multitasking, più richieste possono
+richieste. In questo modo, con sistemi multitasking, più richieste possono
 essere soddisfatte contemporaneamente. Una volta che il processo figlio ha
 concluso il suo lavoro esso di norma viene terminato, mentre il server
 originale resta sempre attivo.
@@ -85,13 +85,13 @@ originale resta sempre attivo.
 \label{sec:net_peertopeer}
 
 Come abbiamo visto il tratto saliente dell'architettura \textit{client-server}
-è quello della preminenza del server rispetto ai client, le architetture
-\textit{peer-to-peer} si basano su un approccio completamente opposto che è
+è quello della preminenza del server rispetto ai client, le architetture
+\textit{peer-to-peer} si basano su un approccio completamente opposto che è
 quello di non avere nessun programma che svolga un ruolo preminente.
 
 Questo vuol dire che in generale ciascun programma viene ad agire come un nodo
 in una rete potenzialmente paritetica; ciascun programma si trova pertanto a
-ricevere ed inviare richieste ed a ricevere ed inviare risposte, e non c'è più
+ricevere ed inviare richieste ed a ricevere ed inviare risposte, e non c'è più
 la separazione netta dei compiti che si ritrova nelle architetture
 \textit{client-server}.
 
@@ -101,8 +101,8 @@ buon esempio di architetture \textit{peer-to-peer}, in cui ciascun nodo,
 tramite il demone che gestisce il routing, richiede ed invia informazioni ad
 altri nodi.
 
-In realtà in molti casi di architetture classificate come \textit{peer-to-peer}
-non è detto che la struttura sia totalmente paritetica e ci sono parecchi
+In realtà in molti casi di architetture classificate come \textit{peer-to-peer}
+non è detto che la struttura sia totalmente paritetica e ci sono parecchi
 esempi in cui alcuni servizi vengono centralizzati o distribuiti
 gerarchicamente, come per lo stesso Napster, in cui le ricerche venivano
 effettuate su un server centrale.
@@ -112,47 +112,47 @@ effettuate su un server centrale.
 \subsection{Il modello \textit{three-tier}}
 \label{sec:net_three_tier}
 
-Benché qui sia trattato a parte, il modello \textit{three-tier} in realtà è
+Benché qui sia trattato a parte, il modello \textit{three-tier} in realtà è
 una estensione del modello \textit{client-server}. Con il crescere della
-quantità dei servizi forniti in rete (in particolare su internet) ed al numero
-di accessi richiesto. Si è così assistito anche ad una notevole crescita di
-complessità, in cui diversi servizi venivano ad essere integrati fra di loro.
+quantità dei servizi forniti in rete (in particolare su internet) ed al numero
+di accessi richiesto. Si è così assistito anche ad una notevole crescita di
+complessità, in cui diversi servizi venivano ad essere integrati fra di loro.
 
-In particolare sempre più spesso si assiste ad una integrazione di servizi di
+In particolare sempre più spesso si assiste ad una integrazione di servizi di
 database con servizi di web, in cui le pagine vengono costruite dinamicamente
 sulla base dei dati contenuti nel database. In tutti questi casi il problema
-fondamentale di una architettura \textit{client-server} è che la richiesta di
+fondamentale di una architettura \textit{client-server} è che la richiesta di
 un servizio da parte di un gran numero di client si scontra con il collo di
 bottiglia dell'accesso diretto ad un unico server, con gravi problemi di
-scalabilità.
+scalabilità.
 
-Rispondere a queste esigenze di scalabilità il modello più semplice (chiamato
-talvolta \textit{two-tier}) da adottare è stata quello di distribuire il
-carico delle richieste su più server identici, mantenendo quindi
+Rispondere a queste esigenze di scalabilità il modello più semplice (chiamato
+talvolta \textit{two-tier}) da adottare è stata quello di distribuire il
+carico delle richieste su più server identici, mantenendo quindi
 sostanzialmente inalterata l'architettura \textit{client-server} originale.
 
-Nel far questo ci si scontra però con gravi problemi di manutenibilità dei
+Nel far questo ci si scontra però con gravi problemi di manutenibilità dei
 servizi, in particolare per quanto riguarda la sincronizzazione dei dati, e di
-inefficienza dell'uso delle risorse. Il problema è particolarmente grave ad
+inefficienza dell'uso delle risorse. Il problema è particolarmente grave ad
 esempio per i database che non possono essere replicati e sincronizzati
-facilmente, e che sono molto onerosi, la loro replicazione è costosa e
+facilmente, e che sono molto onerosi, la loro replicazione è costosa e
 complessa.
 
-È a partire da queste problematiche che nasce il modello \textit{three-tier},
+È a partire da queste problematiche che nasce il modello \textit{three-tier},
 che si struttura, come dice il nome, su tre livelli. Il primo livello, quello
 dei client che eseguono le richieste e gestiscono l'interfaccia con l'utente,
 resta sostanzialmente lo stesso del modello \textit{client-server}, ma la
 parte server viene suddivisa in due livelli, introducendo un
 \textit{middle-tier}, su cui deve appoggiarsi tutta la logica di analisi delle
-richieste dei client per ottimizzare l'accesso al terzo livello, che è quello
+richieste dei client per ottimizzare l'accesso al terzo livello, che è quello
 che si limita a fornire i dati dinamici che verranno usati dalla logica
 implementata nel \textit{middle-tier} per eseguire le operazioni richieste dai
 client.
 
-In questo modo si può disaccoppiare la logica dai dati, replicando la prima,
-che è molto meno soggetta a cambiamenti ed evoluzione, e non soffre di
+In questo modo si può disaccoppiare la logica dai dati, replicando la prima,
+che è molto meno soggetta a cambiamenti ed evoluzione, e non soffre di
 problemi di sincronizzazione, e centralizzando opportunamente i secondi. In
-questo modo si può distribuire il carico ed accedere in maniera efficiente i
+questo modo si può distribuire il carico ed accedere in maniera efficiente i
 dati.
 
 
@@ -162,17 +162,17 @@ dati.
 Parlando di reti di computer si parla in genere di un insieme molto vasto ed
 eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra
 ottica, alle comunicazioni via satellite o via radio; per rendere possibile la
-comunicazione attraverso un così variegato insieme di mezzi sono stati
-adottati una serie di protocolli, il più famoso dei quali, quello alla base
-del funzionamento di internet, è il protocollo TCP/IP.
+comunicazione attraverso un così variegato insieme di mezzi sono stati
+adottati una serie di protocolli, il più famoso dei quali, quello alla base
+del funzionamento di internet, è il protocollo TCP/IP.
 
 \subsection{Il modello ISO/OSI}
 \label{sec:net_iso_osi}
 
-Una caratteristica comune dei protocolli di rete è il loro essere strutturati
+Una caratteristica comune dei protocolli di rete è il loro essere strutturati
 in livelli sovrapposti; in questo modo ogni protocollo di un certo livello
-realizza le sue funzionalità basandosi su un protocollo del livello
-sottostante.  Questo modello di funzionamento è stato standardizzato dalla
+realizza le sue funzionalità basandosi su un protocollo del livello
+sottostante.  Questo modello di funzionamento è stato standardizzato dalla
 \textit{International Standards Organization} (ISO) che ha preparato fin dal
 1984 il Modello di Riferimento \textit{Open Systems Interconnection} (OSI),
 strutturato in sette livelli, secondo quanto riportato in
@@ -198,21 +198,21 @@ tab.~\ref{tab:net_osilayers}.
 \label{tab:net_osilayers}
 \end{table}
 
-Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione della
-serie di protocolli X.25 per la commutazione di pacchetto; come si vede è un
+Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione della
+serie di protocolli X.25 per la commutazione di pacchetto; come si vede è un
 modello abbastanza complesso\footnote{infatti per memorizzarne i vari livelli
-  è stata creata la frase \textit{All people seem to need data processing}, in
+  è stata creata la frase \textit{All people seem to need data processing}, in
   cui ciascuna parola corrisponde all'iniziale di uno dei livelli.}, tanto che
 usualmente si tende a suddividerlo in due parti, secondo lo schema mostrato in
 fig.~\ref{fig:net_osi_tcpip_comp}, con un \textit{upper layer} che riguarda
 solo le applicazioni, che viene realizzato in user space, ed un \textit{lower
-  layer} in cui si mescolano la gestione fatta dal kernel e le funzionalità
+  layer} in cui si mescolano la gestione fatta dal kernel e le funzionalità
 fornite dall'hardware.
 
 Il modello ISO/OSI mira ad effettuare una classificazione completamente
-generale di ogni tipo di protocollo di rete; nel frattempo però era stato
-sviluppato anche un altro modello, relativo al protocollo TCP/IP, che è quello
-su cui è basata internet, che è diventato uno standard de facto.  Questo
+generale di ogni tipo di protocollo di rete; nel frattempo però era stato
+sviluppato anche un altro modello, relativo al protocollo TCP/IP, che è quello
+su cui è basata internet, che è diventato uno standard de facto.  Questo
 modello viene talvolta chiamato anche modello \textit{DoD} (sigla che sta per
 \textit{Department of Defense}), dato che fu sviluppato dall'agenzia ARPA per
 il Dipartimento della Difesa Americano.
@@ -225,12 +225,12 @@ il Dipartimento della Difesa Americano.
   \label{fig:net_osi_tcpip_comp}
 \end{figure}
 
-La scelta fra quale dei due modelli utilizzare dipende per lo più dai gusti
-personali. Come caratteristiche generali il modello ISO/OSI è più teorico e
-generico, basato separazioni funzionali, mentre il modello TCP/IP è più vicino
+La scelta fra quale dei due modelli utilizzare dipende per lo più dai gusti
+personali. Come caratteristiche generali il modello ISO/OSI è più teorico e
+generico, basato separazioni funzionali, mentre il modello TCP/IP è più vicino
 alla separazione concreta dei vari strati del sistema operativo; useremo
-pertanto quest'ultimo, anche per la sua maggiore semplicità.\footnote{questa
-  semplicità ha un costo quando si fa riferimento agli strati più bassi, che
+pertanto quest'ultimo, anche per la sua maggiore semplicità.\footnote{questa
+  semplicità ha un costo quando si fa riferimento agli strati più bassi, che
   sono in effetti descritti meglio dal modello ISO/OSI, in quanto gran parte
   dei protocolli di trasmissione hardware sono appunto strutturati sui due
   livelli di \textit{Data Link} e \textit{Connection}.}
@@ -238,13 +238,13 @@ pertanto quest'ultimo, anche per la sua maggiore semplicit
 \subsection{Il modello TCP/IP (o DoD)}
 \label{sec:net_tcpip_overview}
 
-Così come ISO/OSI anche il modello del TCP/IP è stato strutturato in livelli
-(riassunti in tab.~\ref{tab:net_layers}); un confronto fra i due è riportato
+Così come ISO/OSI anche il modello del TCP/IP è stato strutturato in livelli
+(riassunti in tab.~\ref{tab:net_layers}); un confronto fra i due è riportato
 in fig.~\ref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la
-corrispondenza fra i rispettivi livelli (che comunque è approssimativa) e su
+corrispondenza fra i rispettivi livelli (che comunque è approssimativa) e su
 come essi vanno ad inserirsi all'interno del sistema rispetto alla divisione
 fra user space e kernel space spiegata in
-sez.~\ref{sec:intro_unix_struct}.\footnote{in realtà è sempre possibile
+sez.~\ref{sec:intro_unix_struct}.\footnote{in realtà è sempre possibile
   accedere dallo user space, attraverso una opportuna interfaccia (come
   vedremo in sez.~\ref{sec:sock_sa_packet}), ai livelli inferiori del
   protocollo.}
@@ -268,38 +268,38 @@ sez.~\ref{sec:intro_unix_struct}.\footnote{in realt
 \label{tab:net_layers}
 \end{table}
 
-Come si può notare come il modello TCP/IP è più semplice del modello ISO/OSI
-ed è strutturato in soli quattro livelli. Il suo nome deriva dai due
+Come si può notare come il modello TCP/IP è più semplice del modello ISO/OSI
+ed è strutturato in soli quattro livelli. Il suo nome deriva dai due
 principali protocolli che lo compongono, il TCP (\textit{Trasmission Control
   Protocol}) che copre il livello 3 e l'IP (\textit{Internet Protocol}) che
 copre il livello 2. Le funzioni dei vari livelli sono le seguenti:
 
 \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
-\item[\textbf{Applicazione}] É relativo ai programmi di interfaccia con la
+\item[\textbf{Applicazione}] É relativo ai programmi di interfaccia con la
   rete, in genere questi vengono realizzati secondo il modello client-server
   (vedi sez.~\ref{sec:net_cliserv}), realizzando una comunicazione secondo un
-  protocollo che è specifico di ciascuna applicazione.
+  protocollo che è specifico di ciascuna applicazione.
 \item[\textbf{Trasporto}] Fornisce la comunicazione tra le due stazioni
   terminali su cui girano gli applicativi, regola il flusso delle
-  informazioni, può fornire un trasporto affidabile, cioè con recupero degli
+  informazioni, può fornire un trasporto affidabile, cioè con recupero degli
   errori o inaffidabile. I protocolli principali di questo livello sono il TCP
   e l'UDP.
 \item[\textbf{Rete}] Si occupa dello smistamento dei singoli pacchetti su una
   rete complessa e interconnessa, a questo stesso livello operano i protocolli
   per il reperimento delle informazioni necessarie allo smistamento, per lo
   scambio di messaggi di controllo e per il monitoraggio della rete. Il
-  protocollo su cui si basa questo livello è IP (sia nella attuale versione,
+  protocollo su cui si basa questo livello è IP (sia nella attuale versione,
   IPv4, che nella nuova versione, IPv6).
-\item[\textbf{Collegamento}] È responsabile per l'interfacciamento al
+\item[\textbf{Collegamento}] È responsabile per l'interfacciamento al
   dispositivo elettronico che effettua la comunicazione fisica, gestendo
   l'invio e la ricezione dei pacchetti da e verso l'hardware.
 \end{basedescript}
 
-La comunicazione fra due stazioni remote avviene secondo le modalità
-illustrate in fig.~\ref{fig:net_tcpip_data_flux}, dove si è riportato il flusso
+La comunicazione fra due stazioni remote avviene secondo le modalità
+illustrate in fig.~\ref{fig:net_tcpip_data_flux}, dove si è riportato il flusso
 dei dati reali e i protocolli usati per lo scambio di informazione su ciascun
-livello. Si è genericamente indicato \textit{ethernet} per il livello 1, anche
-se in realtà i protocolli di trasmissione usati possono essere molti altri.
+livello. Si è genericamente indicato \textit{ethernet} per il livello 1, anche
+se in realtà i protocolli di trasmissione usati possono essere molti altri.
 
 \begin{figure}[!htb]
   \centering \includegraphics[width=13cm]{img/tcp_data_flux}
@@ -311,15 +311,15 @@ se in realt
 Per chiarire meglio la struttura della comunicazione attraverso i vari
 protocolli mostrata in fig.~\ref{fig:net_tcpip_data_flux}, conviene prendere in
 esame i singoli passaggi fatti per passare da un livello al sottostante,
-la procedura si può riassumere nei seguenti passi:
+la procedura si può riassumere nei seguenti passi:
 \begin{itemize}
 \item Le singole applicazioni comunicano scambiandosi i dati ciascuna secondo
   un suo specifico formato. Per applicazioni generiche, come la posta o le
   pagine web, viene di solito definito ed implementato quello che viene
   chiamato un protocollo di applicazione (esempi possono essere HTTP, POP,
-  SMTP, ecc.), ciascuno dei quali è descritto in un opportuno standard (di
+  SMTP, ecc.), ciascuno dei quali è descritto in un opportuno standard (di
   solito attraverso un RFC\footnote{l'acronimo RFC sta per \textit{Request For
-      Comment} ed è la procedura attraverso la quale vengono proposti gli
+      Comment} ed è la procedura attraverso la quale vengono proposti gli
     standard per Internet.}).
 \item I dati delle applicazioni vengono inviati al livello di trasporto usando
   un'interfaccia opportuna (i \textit{socket}, che esamineremo in dettaglio in
@@ -329,14 +329,14 @@ la procedura si pu
   processo viene svolto direttamente nel kernel, ad esempio dallo stack TCP,
   nel caso il protocollo di trasporto usato sia questo.
 \item Una volta composto il pacchetto nel formato adatto al protocollo di
-  trasporto usato questo sarà passato al successivo livello, quello di rete,
+  trasporto usato questo sarà passato al successivo livello, quello di rete,
   che si occupa di inserire le opportune informazioni per poter effettuare
   l'instradamento nella rete ed il recapito alla destinazione finale. In
-  genere questo è il livello di IP (Internet Protocol), a cui vengono inseriti
+  genere questo è il livello di IP (Internet Protocol), a cui vengono inseriti
   i numeri IP che identificano i computer su internet.
-\item L'ultimo passo è il trasferimento del pacchetto al driver della
+\item L'ultimo passo è il trasferimento del pacchetto al driver della
   interfaccia di trasmissione, che si incarica di incapsularlo nel relativo
-  protocollo di trasmissione. Questo può avvenire sia in maniera diretta, come
+  protocollo di trasmissione. Questo può avvenire sia in maniera diretta, come
   nel caso di ethernet, in cui i pacchetti vengono inviati sulla linea
   attraverso le schede di rete, che in maniera indiretta con protocolli come
   PPP o SLIP, che vengono usati come interfaccia per far passare i dati su
@@ -347,56 +347,56 @@ la procedura si pu
 \subsection{Criteri generali dell'architettura del TCP/IP}
 \label{sec:net_tcpip_design}
 
-La filosofia architetturale del TCP/IP è semplice: costruire una rete che
+La filosofia architetturale del TCP/IP è semplice: costruire una rete che
 possa sopportare il carico in transito, ma permettere ai singoli nodi di
-scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
+scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
 errati o non recapitabili.
 
 L'incarico di rendere il recapito pacchetti affidabile non spetta al livello
-di rete, ma ai livelli superiori. Pertanto il protocollo IP è per sua natura
-inaffidabile, in quanto non è assicurata né una percentuale di successo né un
+di rete, ma ai livelli superiori. Pertanto il protocollo IP è per sua natura
+inaffidabile, in quanto non è assicurata né una percentuale di successo né un
 limite sui tempi di consegna dei pacchetti.
 
-È il livello di trasporto che si deve occupare (qualora necessiti) del
-controllo del flusso dei dati e del recupero degli errori; questo è realizzato
-dal protocollo TCP. La sede principale di "\textit{intelligenza}" della rete è
+È il livello di trasporto che si deve occupare (qualora necessiti) del
+controllo del flusso dei dati e del recupero degli errori; questo è realizzato
+dal protocollo TCP. La sede principale di "\textit{intelligenza}" della rete è
 pertanto al livello di trasporto o ai livelli superiori.
 
 Infine le singole stazioni collegate alla rete non fungono soltanto da punti
 terminali di comunicazione, ma possono anche assumere il ruolo di
 \textit{router} (\textsl{instradatori}), per l'interscambio di pacchetti da
-una rete ad un'altra. Questo rende possibile la flessibilità della rete che è
+una rete ad un'altra. Questo rende possibile la flessibilità della rete che è
 in grado di adattarsi ai mutamenti delle interconnessioni.
 
-La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
+La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
 a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato
 nel formato del livello successivo, fino al livello del collegamento fisico.
 In questo modo il pacchetto ricevuto ad un livello \textit{n} dalla stazione
-di destinazione è esattamente lo stesso spedito dal livello \textit{n} dalla
+di destinazione è esattamente lo stesso spedito dal livello \textit{n} dalla
 sorgente.  Questo rende facile il progettare il software facendo riferimento
 unicamente a quanto necessario ad un singolo livello, con la confidenza che
-questo poi sarà trattato uniformemente da tutti i nodi della rete.
+questo poi sarà trattato uniformemente da tutti i nodi della rete.
 
 
 \section{Il protocollo TCP/IP}
 \label{sec:net_tpcip}
 
-Come accennato in sez.~\ref{sec:net_protocols} il protocollo TCP/IP è un
+Come accennato in sez.~\ref{sec:net_protocols} il protocollo TCP/IP è un
 insieme di protocolli diversi, che operano su 4 livelli diversi. Per gli
-interessi della programmazione di rete però sono importanti principalmente i
+interessi della programmazione di rete però sono importanti principalmente i
 due livelli centrali, e soprattutto quello di trasporto.
 
 La principale interfaccia usata nella programmazione di rete, quella dei
-socket (vedi sez.~\ref{cha:socket_intro}), è infatti un'interfaccia nei
-confronti di quest'ultimo.  Questo avviene perché al di sopra del livello di
+socket (vedi sez.~\ref{cha:socket_intro}), è infatti un'interfaccia nei
+confronti di quest'ultimo.  Questo avviene perché al di sopra del livello di
 trasporto i programmi hanno a che fare solo con dettagli specifici delle
 applicazioni, mentre al di sotto vengono curati tutti i dettagli relativi alla
-comunicazione. È pertanto naturale definire una interfaccia di programmazione
-su questo confine, tanto più che è proprio lì (come evidenziato in
+comunicazione. È pertanto naturale definire una interfaccia di programmazione
+su questo confine, tanto più che è proprio lì (come evidenziato in
 fig.~\ref{fig:net_osi_tcpip_comp}) che nei sistemi Unix (e non solo) viene
 inserita la divisione fra kernel space e user space.
 
-In realtà in un sistema Unix è possibile accedere anche agli altri livelli
+In realtà in un sistema Unix è possibile accedere anche agli altri livelli
 inferiori (e non solo a quello di trasporto) con opportune interfacce di
 programmazione (vedi sez.~\ref{sec:sock_sa_packet}), ma queste vengono usate
 solo quando si debbano fare applicazioni di sistema per il controllo della
@@ -411,8 +411,8 @@ per il ruolo centrale che svolge nella maggior parte delle applicazioni.
 \subsection{Il quadro generale}
 \label{sec:net_tcpip_general}
 
-Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
-molti membri. In fig.~\ref{fig:net_tcpip_overview} si è riportato uno schema
+Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
+molti membri. In fig.~\ref{fig:net_tcpip_overview} si è riportato uno schema
 che mostra un panorama sui principali protocolli della famiglia, e delle loro
 relazioni reciproche e con alcune dalle principali applicazioni che li usano.
 
@@ -426,88 +426,88 @@ relazioni reciproche e con alcune dalle principali applicazioni che li usano.
 I vari protocolli riportati in fig.~\ref{fig:net_tcpip_overview} sono i
 seguenti:
 \begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
-\item[\textsl{IPv4}] \textit{Internet Protocol version 4}. È quello che
-  comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
-  cui è costruita internet. Usa indirizzi a 32 bit, e mantiene tutte le
+\item[\textsl{IPv4}] \textit{Internet Protocol version 4}. È quello che
+  comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
+  cui è costruita internet. Usa indirizzi a 32 bit, e mantiene tutte le
   informazioni di instradamento e controllo per la trasmissione dei pacchetti
   sulla rete; tutti gli altri protocolli della suite (eccetto ARP e RARP, e
   quelli specifici di IPv6) vengono trasmessi attraverso di esso.
-\item[\textsl{IPv6}] \textit{Internet Protocol version 6}. È stato progettato
-  a metà degli anni '90 per rimpiazzare IPv4. Ha uno spazio di indirizzi
-  ampliato 128 bit che consente più gerarchie di indirizzi,
+\item[\textsl{IPv6}] \textit{Internet Protocol version 6}. È stato progettato
+  a metà degli anni '90 per rimpiazzare IPv4. Ha uno spazio di indirizzi
+  ampliato 128 bit che consente più gerarchie di indirizzi,
   l'auto-configurazione, ed un nuovo tipo di indirizzi, gli \textit{anycast},
   che consentono di inviare un pacchetto ad una stazione su un certo gruppo.
   Effettua lo stesso servizio di trasmissione dei pacchetti di IPv4 di cui
   vuole essere un sostituto.
-\item[\textsl{TCP}] \textit{Trasmission Control Protocol}. È un protocollo
+\item[\textsl{TCP}] \textit{Trasmission Control Protocol}. È un protocollo
   orientato alla connessione che provvede un trasporto affidabile per un
   flusso di dati bidirezionale fra due stazioni remote. Il protocollo ha cura
   di tutti gli aspetti del trasporto, come l'acknoweledgment, i timeout, la
-  ritrasmissione, ecc. È usato dalla maggior parte delle applicazioni.
-\item[\textsl{UDP}] \textit{User Datagram Protocol}. È un protocollo senza
+  ritrasmissione, ecc. È usato dalla maggior parte delle applicazioni.
+\item[\textsl{UDP}] \textit{User Datagram Protocol}. È un protocollo senza
   connessione, per l'invio di dati a pacchetti. Contrariamente al TCP il
-  protocollo non è affidabile e non c'è garanzia che i pacchetti raggiungano
+  protocollo non è affidabile e non c'è garanzia che i pacchetti raggiungano
   la loro destinazione, si perdano, vengano duplicati, o abbiano un
   particolare ordine di arrivo.
-\item[\textsl{ICMP}] \textit{Internet Control Message Protocol}. È il
+\item[\textsl{ICMP}] \textit{Internet Control Message Protocol}. È il
   protocollo usato a livello 2 per gestire gli errori e trasportare le
-  informazioni di controllo fra stazioni remote e instradatori (cioè fra
+  informazioni di controllo fra stazioni remote e instradatori (cioè fra
   \textit{host} e \textit{router}). I messaggi sono normalmente generati dal
-  software del kernel che gestisce la comunicazione TCP/IP, anche se ICMP può
+  software del kernel che gestisce la comunicazione TCP/IP, anche se ICMP può
   venire usato direttamente da alcuni programmi come \cmd{ping}. A volte ci
   si riferisce ad esso come ICPMv4 per distinguerlo da ICMPv6.
-\item[\textsl{IGMP}] \textit{Internet Group Management Protocol}. É un
+\item[\textsl{IGMP}] \textit{Internet Group Management Protocol}. É un
   protocollo di livello 2 usato per il \itindex{multicast}
   \textit{multicast} (vedi sez.~\ref{sec:xxx_multicast}).  Permette
   alle stazioni remote di notificare ai router che supportano questa
   comunicazione a quale gruppo esse appartengono.  Come ICMP viene
   implementato direttamente sopra IP.
-\item[\textsl{ARP}] \textit{Address Resolution Protocol}. È il protocollo che
-  mappa un indirizzo IP in un indirizzo hardware sulla rete locale. È usato in
+\item[\textsl{ARP}] \textit{Address Resolution Protocol}. È il protocollo che
+  mappa un indirizzo IP in un indirizzo hardware sulla rete locale. È usato in
   reti di tipo \itindex{broadcast} \textit{broadcast} come Ethernet, Token
   Ring o FDDI che hanno associato un indirizzo fisico (il \textit{MAC
     address}) alla interfaccia, ma non serve in connessioni punto-punto.
-\item[\textsl{RARP}] \textit{Reverse Address Resolution Protocol}. È il
+\item[\textsl{RARP}] \textit{Reverse Address Resolution Protocol}. È il
   protocollo che esegue l'operazione inversa rispetto ad ARP (da cui il nome)
   mappando un indirizzo hardware in un indirizzo IP. Viene usato a volte per
   durante l'avvio per assegnare un indirizzo IP ad una macchina.
 \item[\textsl{ICMPv6}] \textit{Internet Control Message Protocol, version 6}.
-  Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
-\item[\textsl{EGP}] \textit{Exterior Gateway Protocol}. È un protocollo di
+  Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
+\item[\textsl{EGP}] \textit{Exterior Gateway Protocol}. È un protocollo di
   routing usato per comunicare lo stato fra gateway vicini a livello di
   \textsl{sistemi autonomi}\footnote{vengono chiamati \textit{autonomous
-      systems} i raggruppamenti al livello più alto della rete.}, con
+      systems} i raggruppamenti al livello più alto della rete.}, con
   meccanismi che permettono di identificare i vicini, controllarne la
-  raggiungibilità e scambiare informazioni sullo stato della rete. Viene
+  raggiungibilità e scambiare informazioni sullo stato della rete. Viene
   implementato direttamente sopra IP. 
-\item[\textsl{OSPF}] \textit{Open Shortest Path First}. È in protocollo di
+\item[\textsl{OSPF}] \textit{Open Shortest Path First}. È in protocollo di
   routing per router su reti interne, che permette a questi ultimi di
   scambiarsi informazioni sullo stato delle connessioni e dei legami che
   ciascuno ha con gli altri. Viene implementato direttamente sopra IP.
-\item[\textsl{GRE}] \textit{Generic Routing Encapsulation}. È un protocollo
+\item[\textsl{GRE}] \textit{Generic Routing Encapsulation}. È un protocollo
   generico di incapsulamento che permette di incapsulare un qualunque altro
   protocollo all'interno di IP. 
 \item[\textsl{AH}] \textit{Authentication Header}. Provvede l'autenticazione
-  dell'integrità e dell'origine di un pacchetto. È una opzione nativa in IPv6
-  e viene implementato come protocollo a sé su IPv4. Fa parte della suite di
+  dell'integrità e dell'origine di un pacchetto. È una opzione nativa in IPv6
+  e viene implementato come protocollo a sé su IPv4. Fa parte della suite di
   IPSEC che provvede la trasmissione cifrata ed autenticata a livello IP.
 \item[\textsl{ESP}] \textit{Encapsulating Security Payload}. Provvede la
-  cifratura insieme all'autenticazione dell'integrità e dell'origine di un
-  pacchetto. Come per AH è opzione nativa in IPv6 e viene implementato come
-  protocollo a sé su IPv4.
-\item[\textsl{PPP}] \textit{Point-to-Point Protocol}. È un protocollo a
+  cifratura insieme all'autenticazione dell'integrità e dell'origine di un
+  pacchetto. Come per AH è opzione nativa in IPv6 e viene implementato come
+  protocollo a sé su IPv4.
+\item[\textsl{PPP}] \textit{Point-to-Point Protocol}. È un protocollo a
   livello 1 progettato per lo scambio di pacchetti su connessioni punto punto.
   Viene usato per configurare i collegamenti, definire i protocolli di rete
-  usati ed incapsulare i pacchetti di dati. È un protocollo complesso con
+  usati ed incapsulare i pacchetti di dati. È un protocollo complesso con
   varie componenti.
-\item[\textsl{SLIP}] \textit{Serial Line over IP}. È un protocollo di livello
+\item[\textsl{SLIP}] \textit{Serial Line over IP}. È un protocollo di livello
   1 che permette di trasmettere un pacchetto IP attraverso una linea seriale.
 \end{basedescript}
 
 Gran parte delle applicazioni comunicano usando TCP o UDP, solo alcune, e per
 scopi particolari si rifanno direttamente ad IP (ed i suoi correlati ICMP e
-IGMP); benché sia TCP che UDP siano basati su IP e sia possibile intervenire a
-questo livello con i \textit{raw socket} questa tecnica è molto meno diffusa e
+IGMP); benché sia TCP che UDP siano basati su IP e sia possibile intervenire a
+questo livello con i \textit{raw socket} questa tecnica è molto meno diffusa e
 a parte applicazioni particolari si preferisce sempre usare i servizi messi a
 disposizione dai due protocolli precedenti.  Per questo, motivo a parte alcuni
 brevi accenni su IP in questa sezione, ci concentreremo sul livello di
@@ -517,54 +517,54 @@ trasporto.
 \label{sec:net_ip}
 
 Quando si parla di IP ci si riferisce in genere alla versione attualmente in
-uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
+uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
 venne standardizzata nel 1981
 dall'\href{http://www.ietf.org/rfc/rfc0719.txt}{RFC~719}.
 
 Internet Protocol nasce per disaccoppiare le applicazioni della struttura
 hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
-dei dati indipendente dal sottostante substrato di rete, che può essere
-realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, ecc.).
-Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
+dei dati indipendente dal sottostante substrato di rete, che può essere
+realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, ecc.).
+Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
 all'altro della rete; le caratteristiche essenziali con cui questo viene
 realizzato in IPv4 sono due:
 
 \begin{itemize}
 \item \textit{Universal addressing} la comunicazione avviene fra due stazioni
-  remote identificate univocamente con un indirizzo a 32 bit che può
+  remote identificate univocamente con un indirizzo a 32 bit che può
   appartenere ad una sola interfaccia di rete.
 \item \textit{Best effort} viene assicurato il massimo impegno nella
-  trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla
-  percentuale di successo né sul tempo di consegna dei pacchetti di dati.
+  trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla
+  percentuale di successo né sul tempo di consegna dei pacchetti di dati.
 \end{itemize}
 
 Negli anni '90 la crescita vertiginosa del numero di macchine connesse a
 internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i
-problemi si è perciò definita una nuova versione del protocollo, che (saltando
-un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
+problemi si è perciò definita una nuova versione del protocollo, che (saltando
+un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
 IPv4, mantenendone inalterate le funzioni che si sono dimostrate valide,
 eliminando quelle inutili e aggiungendone poche altre per mantenere il
-protocollo il più snello e veloce possibile.
+protocollo il più snello e veloce possibile.
 
 I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
 grandi linee nei seguenti punti:
 \begin{itemize}
-\item l'espansione delle capacità di indirizzamento e instradamento, per
-  supportare una gerarchia con più livelli di indirizzamento, un numero di
+\item l'espansione delle capacità di indirizzamento e instradamento, per
+  supportare una gerarchia con più livelli di indirizzamento, un numero di
   nodi indirizzabili molto maggiore e una auto-configurazione degli indirizzi.
 \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
   si aggiunge agli usuali \textit{unicast} e \itindex{multicast}
   \textit{multicast}.
 \item la semplificazione del formato dell'intestazione (\textit{header}) dei
   pacchetti, eliminando o rendendo opzionali alcuni dei campi di IPv4, per
-  eliminare la necessità di rielaborazione della stessa da parte dei router e
+  eliminare la necessità di rielaborazione della stessa da parte dei router e
   contenere l'aumento di dimensione dovuto all'ampliamento degli indirizzi.
 \item un supporto per le opzioni migliorato, per garantire una trasmissione
-  più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
-  delle opzioni, e la flessibilità necessaria per introdurne di nuove in
+  più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
+  delle opzioni, e la flessibilità necessaria per introdurne di nuove in
   futuro.
-\item il supporto per delle capacità di \textsl{qualità di servizio} (QoS) che
-  permettano di identificare gruppi di dati per i quali si può provvedere un
+\item il supporto per delle capacità di \textsl{qualità di servizio} (QoS) che
+  permettano di identificare gruppi di dati per i quali si può provvedere un
   trattamento speciale (in vista dell'uso di internet per applicazioni
   multimediali e/o ``real-time'').
 \end{itemize}
@@ -576,141 +576,141 @@ protocollo IP sono forniti nell'appendice sez.~\ref{sec:ip_protocol}.
 \subsection{User Datagram Protocol (UDP)}
 \label{sec:net_udp}
 
-UDP è un protocollo di trasporto molto semplice; la sua descrizione completa è
+UDP è un protocollo di trasporto molto semplice; la sua descrizione completa è
 contenuta dell'\href{http://www.ietf.org/rfc/rfc0768.txt}{RFC~768}, ma in
-sostanza esso è una semplice interfaccia al protocollo IP dal livello di
+sostanza esso è una semplice interfaccia al protocollo IP dal livello di
 trasporto. Quando un'applicazione usa UDP essa scrive un pacchetto di dati (il
 cosiddetto \textit{datagram} che da il nome al protocollo) su un socket, al
-pacchetto viene aggiunto un header molto semplice (per una descrizione più
+pacchetto viene aggiunto un header molto semplice (per una descrizione più
 accurata vedi sez.~\ref{sec:udp_protocol}), e poi viene passato al livello
 superiore (IPv4 o IPv6 che sia) che lo spedisce verso la destinazione.  Dato
-che né IPv4 né IPv6 garantiscono l'affidabilità niente assicura che il
-pacchetto arrivi a destinazione, né che più pacchetti arrivino nello stesso
+che né IPv4 né IPv6 garantiscono l'affidabilità niente assicura che il
+pacchetto arrivi a destinazione, né che più pacchetti arrivino nello stesso
 ordine in cui sono stati spediti.
 
-Pertanto il problema principale che si affronta quando si usa UDP è la
-mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
-destinazione occorrerà provvedere con l'applicazione, all'interno della quale
-si dovrà inserire tutto quanto necessario a gestire la notifica di
+Pertanto il problema principale che si affronta quando si usa UDP è la
+mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
+destinazione occorrerà provvedere con l'applicazione, all'interno della quale
+si dovrà inserire tutto quanto necessario a gestire la notifica di
 ricevimento, la ritrasmissione, il timeout. 
 
 Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello
-stesso ordine in cui sono stati trasmessi, e può anche accadere che i
+stesso ordine in cui sono stati trasmessi, e può anche accadere che i
 pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto
 questo di nuovo deve tenere conto l'applicazione.
 
-Un altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
+Un altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
 destinazione esso viene passato all'applicazione ricevente in tutta la sua
-lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
+lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
 viene anche essa trasmessa all'applicazione all'atto del ricevimento.
 
-Infine UDP è un protocollo che opera senza connessione
-(\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
-relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
-in cui un client può scrivere su uno stesso socket pacchetti destinati a
+Infine UDP è un protocollo che opera senza connessione
+(\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
+relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
+in cui un client può scrivere su uno stesso socket pacchetti destinati a
 server diversi, o un server ricevere su un socket pacchetti provenienti da
-client diversi.  Il modo più semplice di immaginarsi il funzionamento di UDP è
-quello della radio, in cui si può \textsl{trasmettere} e \textsl{ricevere} da
-più stazioni usando la stessa frequenza.
+client diversi.  Il modo più semplice di immaginarsi il funzionamento di UDP è
+quello della radio, in cui si può \textsl{trasmettere} e \textsl{ricevere} da
+più stazioni usando la stessa frequenza.
 
-Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
-grande pregio della velocità, che in certi casi è essenziale; inoltre si
-presta bene per le applicazioni in cui la connessione non è necessaria, e
+Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
+grande pregio della velocità, che in certi casi è essenziale; inoltre si
+presta bene per le applicazioni in cui la connessione non è necessaria, e
 costituirebbe solo un peso in termini di prestazioni, mentre una perdita di
-pacchetti può essere tollerata: ad esempio le applicazioni di streaming e
+pacchetti può essere tollerata: ad esempio le applicazioni di streaming e
 quelle che usano il \itindex{multicast} \textit{multicast}.
 
 \subsection{Transport Control Protocol (TCP)}
 \label{sec:net_tcp}
 
-Il TCP è un protocollo molto complesso, definito
+Il TCP è un protocollo molto complesso, definito
 nell'\href{http://www.ietf.org/rfc/rfc0739.txt}{RFC~739} e completamente
 diverso da UDP; alla base della sua progettazione infatti non stanno
-semplicità e velocità, ma la ricerca della massima affidabilità possibile
+semplicità e velocità, ma la ricerca della massima affidabilità possibile
 nella trasmissione dei dati.
 
-La prima differenza con UDP è che TCP provvede sempre una connessione diretta
+La prima differenza con UDP è che TCP provvede sempre una connessione diretta
 fra un client e un server, attraverso la quale essi possono comunicare; per
-questo il paragone più appropriato per questo protocollo è quello del
+questo il paragone più appropriato per questo protocollo è quello del
 collegamento telefonico, in quanto prima viene stabilita una connessione fra
 due i due capi della comunicazione su cui poi effettuare quest'ultima.
 
-Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
+Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
 inviati attraverso una connessione ne viene richiesto un ``\textsl{ricevuto}''
 (il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
 ritrasmessi per un determinato numero di tentativi, intervallati da un periodo
-di tempo crescente, fino a che sarà considerata fallita o caduta la
-connessione (e sarà generato un errore di \textit{timeout}); il periodo di
-tempo dipende dall'implementazione e può variare far i quattro e i dieci
+di tempo crescente, fino a che sarà considerata fallita o caduta la
+connessione (e sarà generato un errore di \textit{timeout}); il periodo di
+tempo dipende dall'implementazione e può variare far i quattro e i dieci
 minuti.
 
-Inoltre, per tenere conto delle diverse condizioni in cui può trovarsi la
+Inoltre, per tenere conto delle diverse condizioni in cui può trovarsi la
 linea di comunicazione, TCP comprende anche un algoritmo di calcolo dinamico
 del tempo di andata e ritorno dei pacchetti fra un client e un server (il
 cosiddetto RTT, \itindex{Round~Trip~Time} \textit{Round Trip Time}), che lo
 rende in grado di adattarsi alle condizioni della rete per non generare
 inutili ritrasmissioni o cadere facilmente in timeout.
 
-Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
+Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
 sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
 byte su un socket TCP, questi potranno essere spezzati dal protocollo in due
-segmenti (le unità di dati passate da TCP a IP vengono chiamate
-\textit{segment}) di 1500 byte, di cui il primo conterrà il numero di sequenza
+segmenti (le unità di dati passate da TCP a IP vengono chiamate
+\textit{segment}) di 1500 byte, di cui il primo conterrà il numero di sequenza
 $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se i
 segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
-più volte a causa di ritrasmissioni dovute alla perdita degli
-\textit{acknowlegment}, all'arrivo sarà comunque possibile riordinare i dati e
+più volte a causa di ritrasmissioni dovute alla perdita degli
+\textit{acknowlegment}, all'arrivo sarà comunque possibile riordinare i dati e
 scartare i duplicati.
 
 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
-cioè specifica sempre all'altro capo della trasmissione quanti dati può
+cioè specifica sempre all'altro capo della trasmissione quanti dati può
 ricevere tramite una \itindex{advertised~window} \textit{advertised window}
 (letteralmente ``\textsl{finestra annunciata}''), che indica lo spazio
-disponibile nel buffer di ricezione, cosicché nella trasmissione non vengano
-inviati più dati di quelli che possono essere ricevuti.
+disponibile nel buffer di ricezione, cosicché nella trasmissione non vengano
+inviati più dati di quelli che possono essere ricevuti.
 
 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
 socket ed aumentando con la lettura di quest'ultimo da parte
-dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
+dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
 verranno accettati altri dati.  Si noti che UDP non provvede niente di tutto
-ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un ritmo che il
-ricevente non può sostenere.
+ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un ritmo che il
+ricevente non può sostenere.
 
-Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese si
-dice che è \textit{full-duplex}). È cioè possibile sia trasmettere che
+Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese si
+dice che è \textit{full-duplex}). È cioè possibile sia trasmettere che
 ricevere allo stesso tempo, il che comporta che quanto dicevamo a proposito
-del controllo di flusso e della gestione della sequenzialità dei dati viene
+del controllo di flusso e della gestione della sequenzialità dei dati viene
 effettuato per entrambe le direzioni di comunicazione.
 
-% TODO mettere riferimento alla appendice su TCP quando ci sarà
-%% Una descrizione più accurata del protocollo è fornita in appendice
+% TODO mettere riferimento alla appendice su TCP quando ci sarà
+%% Una descrizione più accurata del protocollo è fornita in appendice
 %% sez.~\ref{sec:tcp_protocol}.
 
 \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
 \label{sec:net_lim_dim}
 
 Un aspetto di cui bisogna tenere conto nella programmazione di rete, e che
-ritornerà in seguito, quando tratteremo gli aspetti più avanzati, è che ci sono
+ritornerà in seguito, quando tratteremo gli aspetti più avanzati, è che ci sono
 una serie di limiti a cui la trasmissione dei dati attraverso i vari livelli
-del protocollo deve sottostare; limiti che è opportuno tenere presente perché
+del protocollo deve sottostare; limiti che è opportuno tenere presente perché
 in certi casi si possono avere delle conseguenze sul comportamento delle
 applicazioni.
 
 Un elenco di questi limiti, insieme ad un breve accenno alle loro origini ed
-alle eventuali implicazioni che possono avere, è il seguente:
+alle eventuali implicazioni che possono avere, è il seguente:
 \begin{itemize}
-\item La dimensione massima di un pacchetto IP è di 65535 byte, compresa
-  l'intestazione. Questo è dovuto al fatto che la dimensione è indicata da un
-  campo apposito nell'header di IP che è lungo 16 bit (vedi
+\item La dimensione massima di un pacchetto IP è di 65535 byte, compresa
+  l'intestazione. Questo è dovuto al fatto che la dimensione è indicata da un
+  campo apposito nell'header di IP che è lungo 16 bit (vedi
   fig.~\ref{fig:IP_ipv4_head}).
-\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte;
-  il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
-  dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
-  suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
+\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte;
+  il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
+  dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
+  suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
   un pacchetto usando la \textit{jumbo payload option}.
 \item Molte reti fisiche hanno una MTU \itindex{Maximum~Transfer~Unit}
   (\textit{Maximum Transfer Unit}) che dipende dal protocollo specifico usato
-  al livello di connessione fisica. Il più comune è quello di ethernet che è
+  al livello di connessione fisica. Il più comune è quello di ethernet che è
   pari a 1500 byte, una serie di altri valori possibili sono riportati in
   tab.~\ref{tab:net_mtu_values}.
 \end{itemize}
@@ -718,10 +718,10 @@ alle eventuali implicazioni che possono avere, 
 \itindbeg{Maximum~Transfer~Unit}
 Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
 dimensioni eccedono la MTU viene eseguita la cosiddetta
-\textit{frammentazione}, i pacchetti cioè vengono suddivisi\footnote{questo
+\textit{frammentazione}, i pacchetti cioè vengono suddivisi\footnote{questo
   accade sia per IPv4 che per IPv6, anche se i pacchetti frammentati sono
-  gestiti con modalità diverse, IPv4 usa un flag nell'header, IPv6 una
-  opportuna opzione, si veda sez.~\ref{sec:ipv6_protocol}.}) in blocchi più
+  gestiti con modalità diverse, IPv4 usa un flag nell'header, IPv6 una
+  opportuna opzione, si veda sez.~\ref{sec:ipv6_protocol}.}) in blocchi più
 piccoli che possono essere trasmessi attraverso l'interfaccia.
 
 \begin{table}[!htb]
@@ -744,27 +744,27 @@ piccoli che possono essere trasmessi attraverso l'interfaccia.
   \label{tab:net_mtu_values}
 \end{table}
 
-La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
-  MTU}, che dice qual è la lunghezza massima oltre la quale un pacchetto
+La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
+  MTU}, che dice qual è la lunghezza massima oltre la quale un pacchetto
 inviato da una stazione ad un'altra verrebbe senz'altro frammentato. Si tenga
-conto che non è affatto detto che la \textit{path MTU} sia la stessa in
-entrambe le direzioni, perché l'instradamento può essere diverso nei due
+conto che non è affatto detto che la \textit{path MTU} sia la stessa in
+entrambe le direzioni, perché l'instradamento può essere diverso nei due
 sensi, con diverse tipologie di rete coinvolte.
 
-Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
+Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
 essere eseguita solo alla sorgente, questo vuol dire che i router IPv6 non
 frammentano i pacchetti che ritrasmettono (anche se possono frammentare i
 pacchetti che generano loro stessi), al contrario di quanto fanno i router
 IPv4. In ogni caso una volta frammentati i pacchetti possono essere
 riassemblati solo alla destinazione.
 
-Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
+Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
 pacchetto non deve essere frammentato; un router che riceva un pacchetto le
-cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un
+cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un
 messaggio di errore ICMPv4 di tipo \textit{destination unreachable,
   fragmentation needed but DF bit set}.  Dato che i router IPv6 non possono
 effettuare la frammentazione la ricezione di un pacchetto di dimensione
-eccessiva per la ritrasmissione genererà sempre un messaggio di errore ICMPv6
+eccessiva per la ritrasmissione genererà sempre un messaggio di errore ICMPv6
 di tipo \textit{packet too big}.
 
 Dato che il meccanismo di frammentazione e riassemblaggio dei pacchetti
@@ -775,20 +775,20 @@ fra due stazioni; per la realizzazione del procedimento si usa il flag
 opportune serie di pacchetti (per i dettagli vedere
 l'\href{http://www.ietf.org/rfc/rfc1191.txt}{RFC~1191} per IPv4 e
 l'\href{http://www.ietf.org/rfc/rfc1981.txt}{RFC~1981} per IPv6) fintanto che
-non si hanno più errori.
+non si hanno più errori.
 
-Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 è
+Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 è
 opzionale, mentre diventa obbligatorio per IPv6.  Per IPv6 infatti, non
-potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
+potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
 conoscere da subito il \textit{path MTU}.
 
 Infine TCP definisce una \itindex{Maximum~Segment~Size} \textit{Maximum
   Segment Size} (da qui in avanti abbreviata in MSS) che annuncia all'altro
 capo della connessione la dimensione massima dimensione del segmento di dati
-che può essere ricevuto, così da evitare la frammentazione. Di norma viene
+che può essere ricevuto, così da evitare la frammentazione. Di norma viene
 impostato alla dimensione della MTU dell'interfaccia meno la lunghezza delle
 intestazioni di IP e TCP, in Linux il default, mantenuto nella costante
-\const{TCP\_MSS} è 512.
+\const{TCP\_MSS} è 512.
 
 \itindend{Maximum~Transfer~Unit}
 
diff --git a/othersock.tex b/othersock.tex
index 6ebdcb8..abf0f78 100644
--- a/othersock.tex
+++ b/othersock.tex
@@ -13,35 +13,35 @@
 \label{cha:other_socket}
 
 Dopo aver trattato in cap.~\ref{cha:TCP_socket} i socket TCP, che
-costituiscono l'esempio più comune dell'interfaccia dei socket, esamineremo in
+costituiscono l'esempio più comune dell'interfaccia dei socket, esamineremo in
 questo capitolo gli altri tipi di socket, a partire dai socket UDP, e i socket
-\textit{Unix domain} già incontrati in sez.~\ref{sec:ipc_socketpair}.
+\textit{Unix domain} già incontrati in sez.~\ref{sec:ipc_socketpair}.
 
 
 \section{I socket UDP}
 \label{sec:UDP_socket}
 
-Dopo i socket TCP i socket più utilizzati nella programmazione di rete sono i
+Dopo i socket TCP i socket più utilizzati nella programmazione di rete sono i
 socket UDP: protocolli diffusi come NFS o il DNS usano principalmente questo
 tipo di socket. Tratteremo in questa sezione le loro caratteristiche
-principali e le modalità per il loro utilizzo.
+principali e le modalità per il loro utilizzo.
 
 
 \subsection{Le caratteristiche di un socket UDP}
 \label{sec:UDP_characteristics}
 
-Come illustrato in sez.\ref{sec:net_udp} UDP è un protocollo molto semplice che
-non supporta le connessioni e non è affidabile: esso si appoggia direttamente
+Come illustrato in sez.\ref{sec:net_udp} UDP è un protocollo molto semplice che
+non supporta le connessioni e non è affidabile: esso si appoggia direttamente
 sopra IP (per i dettagli sul protocollo si veda sez.~\ref{sec:udp_protocol}).
-I dati vengono inviati in forma di pacchetti, e non ne è assicurata né la
-effettiva ricezione né l'arrivo nell'ordine in cui vengono inviati. Il
-vantaggio del protocollo è la velocità, non è necessario trasmettere le
-informazioni di controllo ed il risultato è una trasmissione di dati più
+I dati vengono inviati in forma di pacchetti, e non ne è assicurata né la
+effettiva ricezione né l'arrivo nell'ordine in cui vengono inviati. Il
+vantaggio del protocollo è la velocità, non è necessario trasmettere le
+informazioni di controllo ed il risultato è una trasmissione di dati più
 veloce ed immediata.
 
 Questo significa che a differenza dei socket TCP i socket UDP non supportano
 una comunicazione di tipo \textit{stream} in cui si ha a disposizione un
-flusso continuo di dati che può essere letto un po' alla volta, ma piuttosto
+flusso continuo di dati che può essere letto un po' alla volta, ma piuttosto
 una comunicazione di tipo \textit{datagram}, in cui i dati arrivano in singoli
 blocchi che devono essere letti integralmente.
 
@@ -52,12 +52,12 @@ essere aperti quando si usa la funzione \func{socket} (si riveda quanto
 illustrato a suo tempo in tab.~\ref{tab:sock_sock_valid_combinations})
 utilizzando per il tipo di socket il valore \const{SOCK\_DGRAM}.
 
-Questa differenza comporta ovviamente che anche le modalità con cui si usano i
+Questa differenza comporta ovviamente che anche le modalità con cui si usano i
 socket UDP sono completamente diverse rispetto ai socket TCP, ed in
 particolare non esistendo il concetto di connessione non esiste il meccanismo
-del \itindex{three~way~handshake} \textit{three way handshake} né quello degli
-stati del protocollo. In realtà tutto quello che avviene nella comunicazione
-attraverso dei socket UDP è la trasmissione di un pacchetto da un client ad un
+del \itindex{three~way~handshake} \textit{three way handshake} né quello degli
+stati del protocollo. In realtà tutto quello che avviene nella comunicazione
+attraverso dei socket UDP è la trasmissione di un pacchetto da un client ad un
 server o viceversa, secondo lo schema illustrato in
 fig.~\ref{fig:UDP_packet-exchange}.
 
@@ -71,24 +71,24 @@ fig.~\ref{fig:UDP_packet-exchange}.
 
 Come illustrato in fig.~\ref{fig:UDP_packet-exchange} la struttura generica di
 un server UDP prevede, una volta creato il socket, la chiamata a \func{bind}
-per mettersi in ascolto dei dati. Questa è l'unica parte comune con un server
+per mettersi in ascolto dei dati. Questa è l'unica parte comune con un server
 TCP: non essendovi il concetto di connessione le funzioni \func{listen} ed
 \func{accept} non sono mai utilizzate nel caso di server UDP. La ricezione dei
 dati dal client avviene attraverso la funzione \func{recvfrom}, mentre una
-eventuale risposta sarà inviata con la funzione \func{sendto}.
+eventuale risposta sarà inviata con la funzione \func{sendto}.
 
-Da parte del client invece, una volta creato il socket non sarà necessario
+Da parte del client invece, una volta creato il socket non sarà necessario
 connettersi con \func{connect} (anche se, come vedremo in
-sez.~\ref{sec:UDP_connect}, è possibile usare questa funzione, con un
-significato comunque diverso) ma si potrà effettuare direttamente una
-richiesta inviando un pacchetto con la funzione \func{sendto} e si potrà
+sez.~\ref{sec:UDP_connect}, è possibile usare questa funzione, con un
+significato comunque diverso) ma si potrà effettuare direttamente una
+richiesta inviando un pacchetto con la funzione \func{sendto} e si potrà
 leggere una eventuale risposta con la funzione \func{recvfrom}.
 
-Anche se UDP è completamente diverso rispetto a TCP resta identica la
-possibilità di gestire più canali di comunicazione fra due macchine
-utilizzando le porte. In questo caso il server dovrà usare comunque la
+Anche se UDP è completamente diverso rispetto a TCP resta identica la
+possibilità di gestire più canali di comunicazione fra due macchine
+utilizzando le porte. In questo caso il server dovrà usare comunque la
 funzione \func{bind} per scegliere la porta su cui ricevere i dati, e come nel
-caso dei socket TCP si potrà usare il comando \cmd{netstat} per
+caso dei socket TCP si potrà usare il comando \cmd{netstat} per
 verificare quali socket sono in ascolto:
 \begin{verbatim}
 [piccardi@gont gapil]# netstat -anu
@@ -103,9 +103,9 @@ in questo caso abbiamo attivi il DNS (sulla porta 53, e sulla 32768 per la
 connessione di controllo del server \cmd{named}) ed un server DHCP (sulla
 porta 67).
 
-Si noti però come in questo caso la colonna che indica lo stato sia vuota. I
+Si noti però come in questo caso la colonna che indica lo stato sia vuota. I
 socket UDP infatti non hanno uno stato. Inoltre anche in presenza di traffico
-non si avranno indicazioni delle connessioni attive, proprio perché questo
+non si avranno indicazioni delle connessioni attive, proprio perché questo
 concetto non esiste per i socket UDP, il kernel si limita infatti a ricevere i
 pacchetti ed inviarli al processo in ascolto sulla porta cui essi sono
 destinati, oppure a scartarli inviando un messaggio \textit{ICMP port
@@ -117,26 +117,26 @@ destinati, oppure a scartarli inviando un messaggio \textit{ICMP port
 
 Come accennato in sez.~\ref{sec:UDP_characteristics} le due funzioni
 principali usate per la trasmissione di dati attraverso i socket UDP sono
-\func{sendto} e \func{recvfrom}. La necessità di usare queste funzioni è
+\func{sendto} e \func{recvfrom}. La necessità di usare queste funzioni è
 dovuta al fatto che non esistendo con UDP il concetto di connessione, non si
 ha neanche a disposizione un \textsl{socket connesso} su cui sia possibile
-usare direttamente \func{read} e \func{write} avendo già stabilito (grazie
+usare direttamente \func{read} e \func{write} avendo già stabilito (grazie
 alla chiamata ad \func{accept} che lo associa ad una connessione) quali sono
 sorgente e destinazione dei dati.
 
 Per questo motivo nel caso di UDP diventa essenziale utilizzare queste due
 funzioni, che sono comunque utilizzabili in generale per la trasmissione di
 dati attraverso qualunque tipo di socket. Esse hanno la caratteristica di
-prevedere tre argomenti aggiuntivi attraverso i quali è possibile specificare
+prevedere tre argomenti aggiuntivi attraverso i quali è possibile specificare
 la destinazione dei dati trasmessi o ottenere l'origine dei dati ricevuti. La
-prima di queste funzioni è \funcd{sendto} ed il suo prototipo\footnote{il
-  prototipo illustrato è quello utilizzato dalle \acr{glibc}, che seguono le
+prima di queste funzioni è \funcd{sendto} ed il suo prototipo\footnote{il
+  prototipo illustrato è quello utilizzato dalle \acr{glibc}, che seguono le
   \textit{Single Unix Specification}, l'argomento \param{flags} era di tipo
   \texttt{int} nei vari BSD4.*, mentre nelle \acr{libc4} e \acr{libc5} veniva
   usato un \texttt{unsigned int}; l'argomento \param{len} era \texttt{int} nei
   vari BSD4.* e nelle \acr{libc4}, ma \type{size\_t} nelle \acr{libc5}; infine
   l'argomento \param{tolen} era \texttt{int} nei vari BSD4.* nelle \acr{libc4}
-  e nelle \acr{libc5}.} è:
+  e nelle \acr{libc5}.} è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{sys/socket.h}
@@ -150,29 +150,29 @@ prima di queste funzioni 
     successo e -1 per un errore; nel qual caso \var{errno} viene impostata al
     rispettivo codice di errore:
   \begin{errlist}
-  \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma
+  \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma
     l'operazione richiede che la funzione si blocchi.
   \item[\errcode{ECONNRESET}] l'altro capo della comunicazione ha resettato la
     connessione.
-  \item[\errcode{EDESTADDRREQ}] il socket non è di tipo connesso, e non si è
+  \item[\errcode{EDESTADDRREQ}] il socket non è di tipo connesso, e non si è
     specificato un indirizzo di destinazione.
-  \item[\errcode{EISCONN}] il socket è già connesso, ma si è specificato un
+  \item[\errcode{EISCONN}] il socket è già connesso, ma si è specificato un
     destinatario.
   \item[\errcode{EMSGSIZE}] il tipo di socket richiede l'invio dei dati in un
     blocco unico, ma la dimensione del messaggio lo rende impossibile.
-  \item[\errcode{ENOBUFS}] la coda di uscita dell'interfaccia è già piena (di
+  \item[\errcode{ENOBUFS}] la coda di uscita dell'interfaccia è già piena (di
     norma Linux non usa questo messaggio ma scarta silenziosamente i
     pacchetti).
-  \item[\errcode{ENOTCONN}] il socket non è connesso e non si è specificata
+  \item[\errcode{ENOTCONN}] il socket non è connesso e non si è specificata
     una destinazione.
-  \item[\errcode{EOPNOTSUPP}] il valore di \param{flag} non è appropriato per
+  \item[\errcode{EOPNOTSUPP}] il valore di \param{flag} non è appropriato per
     il tipo di socket usato.
-  \item[\errcode{EPIPE}] il capo locale della connessione è stato chiuso, si
-    riceverà anche un segnale di \const{SIGPIPE}, a meno di non aver impostato
+  \item[\errcode{EPIPE}] il capo locale della connessione è stato chiuso, si
+    riceverà anche un segnale di \const{SIGPIPE}, a meno di non aver impostato
     \const{MSG\_NOSIGNAL} in \param{flags}.
   \end{errlist}
   ed anche \errval{EFAULT}, \errval{EBADF}, \errval{EINVAL}, \errval{EINTR},
-  \errval{ENOMEM}, \errval{ENOTSOCK} più gli eventuali altri errori relativi
+  \errval{ENOMEM}, \errval{ENOTSOCK} più gli eventuali altri errori relativi
   ai protocolli utilizzati.}
 \end{functions}
 
@@ -180,12 +180,12 @@ I primi tre argomenti sono identici a quelli della funzione \func{write} e
 specificano il socket \param{sockfd} a cui si fa riferimento, il buffer
 \param{buf} che contiene i dati da inviare e la relativa lunghezza
 \param{len}.  Come per \func{write} la funzione ritorna il numero di byte
-inviati; nel caso di UDP però questo deve sempre corrispondere alla dimensione
+inviati; nel caso di UDP però questo deve sempre corrispondere alla dimensione
 totale specificata da \param{len} in quanto i dati vengono sempre inviati in
 forma di pacchetto e non possono essere spezzati in invii successivi.  Qualora
 non ci sia spazio nel buffer di uscita la funzione si blocca (a meno di non
-avere aperto il socket in modalità non bloccante), se invece non è possibile
-inviare il messaggio all'interno di un unico pacchetto (ad esempio perché
+avere aperto il socket in modalità non bloccante), se invece non è possibile
+inviare il messaggio all'interno di un unico pacchetto (ad esempio perché
 eccede le dimensioni massime del protocollo sottostante utilizzato) essa
 fallisce con l'errore di \errcode{EMSGSIZE}. 
 
@@ -193,38 +193,38 @@ I due argomenti \param{to} e \param{tolen} servono a specificare la
 destinazione del messaggio da inviare, e indicano rispettivamente la struttura
 contenente l'indirizzo di quest'ultima e la sua dimensione; questi argomenti
 vanno specificati stessa forma in cui li si sarebbero usati con
-\func{connect}. Nel nostro caso \param{to} dovrà puntare alla struttura
+\func{connect}. Nel nostro caso \param{to} dovrà puntare alla struttura
 contenente l'indirizzo IP e la porta di destinazione verso cui si vogliono
-inviare i dati (questo è indifferente rispetto all'uso di TCP o UDP, usando
+inviare i dati (questo è indifferente rispetto all'uso di TCP o UDP, usando
 socket diversi si sarebbero dovute utilizzare le rispettive strutture degli
 indirizzi).
 
-Se il socket è di un tipo che prevede le connessioni (ad esempio un socket
-TCP), questo deve essere già connesso prima di poter eseguire la funzione, in
-caso contrario si riceverà un errore di \errcode{ENOTCONN}. In questo
+Se il socket è di un tipo che prevede le connessioni (ad esempio un socket
+TCP), questo deve essere già connesso prima di poter eseguire la funzione, in
+caso contrario si riceverà un errore di \errcode{ENOTCONN}. In questo
 specifico caso in cui gli argomenti \param{to} e \param{tolen} non servono
 essi dovranno essere inizializzati rispettivamente a \const{NULL} e 0;
 normalmente quando si opera su un socket connesso essi vengono ignorati, ma
-qualora si sia specificato un indirizzo è possibile ricevere un errore di
+qualora si sia specificato un indirizzo è possibile ricevere un errore di
 \errcode{EISCONN}.
 
-Finora abbiamo tralasciato l'argomento \param{flags}; questo è un intero usato
-come maschera binaria che permette di impostare una serie di modalità di
+Finora abbiamo tralasciato l'argomento \param{flags}; questo è un intero usato
+come maschera binaria che permette di impostare una serie di modalità di
 funzionamento della comunicazione attraverso il socket (come
 \const{MSG\_NOSIGNAL} che impedisce l'invio del segnale \const{SIGPIPE} quando
-si è già chiuso il capo locale della connessione). Torneremo con maggiori
+si è già chiuso il capo locale della connessione). Torneremo con maggiori
 dettagli sul significato di questo argomento in sez.~\ref{sec:net_sendmsg},
-dove tratteremo le funzioni avanzate dei socket, per il momento ci si può
+dove tratteremo le funzioni avanzate dei socket, per il momento ci si può
 limitare ad usare sempre un valore nullo.
 
-La seconda funzione utilizzata nella comunicazione fra socket UDP è
+La seconda funzione utilizzata nella comunicazione fra socket UDP è
 \funcd{recvfrom}, che serve a ricevere i dati inviati da un altro socket; il
-suo prototipo\footnote{il prototipo è quello delle \acr{glibc} che seguono le
+suo prototipo\footnote{il prototipo è quello delle \acr{glibc} che seguono le
   \textit{Single Unix Specification}, i vari BSD4.*, le \acr{libc4} e le
   \acr{libc5} usano un \texttt{int} come valore di ritorno; per gli argomenti
   \param{flags} e \param{len} vale quanto detto a proposito di \func{sendto};
-  infine l'argomento \param{fromlen} è \texttt{int} per i vari BSD4.*, le
-  \acr{libc4} e le \acr{libc5}.} è:
+  infine l'argomento \param{fromlen} è \texttt{int} per i vari BSD4.*, le
+  \acr{libc4} e le \acr{libc5}.} è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{sys/socket.h}
@@ -235,19 +235,19 @@ suo prototipo\footnote{il prototipo 
   Riceve un messaggio ad un socket.
   
   \bodydesc{La funzione restituisce il numero di byte ricevuti in caso di
-    successo e -1 in caso di errore; nel qual caso \var{errno} assumerà il
+    successo e -1 in caso di errore; nel qual caso \var{errno} assumerà il
     valore:
   \begin{errlist}
-  \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma
-    l'operazione richiede che la funzione si blocchi, oppure si è impostato un
-    timeout in ricezione e questo è scaduto.
+  \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma
+    l'operazione richiede che la funzione si blocchi, oppure si è impostato un
+    timeout in ricezione e questo è scaduto.
   \item[\errcode{ECONNREFUSED}] l'altro capo della comunicazione ha rifiutato
-    la connessione (in genere perché il relativo servizio non è disponibile).
-  \item[\errcode{ENOTCONN}] il socket è di tipo connesso, ma non si è eseguita
+    la connessione (in genere perché il relativo servizio non è disponibile).
+  \item[\errcode{ENOTCONN}] il socket è di tipo connesso, ma non si è eseguita
     la connessione.
   \end{errlist}
   ed anche \errval{EFAULT}, \errval{EBADF}, \errval{EINVAL}, \errval{EINTR},
-  \errval{ENOMEM}, \errval{ENOTSOCK} più gli eventuali altri errori relativi
+  \errval{ENOMEM}, \errval{ENOTSOCK} più gli eventuali altri errori relativi
   ai protocolli utilizzati.}
 \end{functions}
 
@@ -257,40 +257,40 @@ buffer \param{buf}. A seconda del tipo di socket (se di tipo \textit{datagram}
 o di tipo \textit{stream}) i byte in eccesso che non sono stati letti possono
 rispettivamente andare persi o restare disponibili per una lettura successiva.
 Se non sono disponibili dati la funzione si blocca, a meno di non aver aperto
-il socket in modalità non bloccante, nel qual caso si avrà il solito errore di
+il socket in modalità non bloccante, nel qual caso si avrà il solito errore di
 \errcode{EAGAIN}.  Qualora \param{len} ecceda la dimensione del pacchetto la
-funzione legge comunque i dati disponibili, ed il suo valore di ritorno è
+funzione legge comunque i dati disponibili, ed il suo valore di ritorno è
 comunque il numero di byte letti.
 
 I due argomenti \param{from} e \param{fromlen} sono utilizzati per ottenere
-l'indirizzo del mittente del pacchetto che è stato ricevuto, e devono essere
+l'indirizzo del mittente del pacchetto che è stato ricevuto, e devono essere
 opportunamente inizializzati; il primo deve contenere il puntatore alla
-struttura (di tipo \ctyp{sockaddr}) che conterrà l'indirizzo e il secondo il
+struttura (di tipo \ctyp{sockaddr}) che conterrà l'indirizzo e il secondo il
 puntatore alla variabile con la dimensione di detta struttura. Si tenga
 presente che mentre il contenuto della struttura \ctyp{sockaddr} cui punta
-\param{from} può essere qualunque, la variabile puntata da \param{fromlen}
+\param{from} può essere qualunque, la variabile puntata da \param{fromlen}
 deve essere opportunamente inizializzata a \code{sizeof(sockaddr)},
 assicurandosi che la dimensione sia sufficiente a contenere tutti i dati
-dell'indirizzo.\footnote{si ricordi che \ctyp{sockaddr} è un tipo generico che
+dell'indirizzo.\footnote{si ricordi che \ctyp{sockaddr} è un tipo generico che
   serve ad indicare la struttura corrispondente allo specifico tipo di
   indirizzo richiesto, il valore di \param{fromlen} pone un limite alla
-  quantità di dati che verranno scritti sulla struttura puntata da
-  \param{from} e se è insufficiente l'indirizzo risulterà corrotto.}  Al
+  quantità di dati che verranno scritti sulla struttura puntata da
+  \param{from} e se è insufficiente l'indirizzo risulterà corrotto.}  Al
 ritorno della funzione si otterranno i dati dell'indirizzo e la sua effettiva
-lunghezza, (si noti che \param{fromlen} è un valore intero ottenuto come
-\itindex{value~result~argument} \textit{value result argument}).  Se non si è
+lunghezza, (si noti che \param{fromlen} è un valore intero ottenuto come
+\itindex{value~result~argument} \textit{value result argument}).  Se non si è
 interessati a questa informazione, entrambi gli argomenti devono essere
 inizializzati al valore \const{NULL}.
 
 Una differenza fondamentale del comportamento di queste funzioni rispetto alle
-usuali \func{read} e \func{write} che abbiamo usato con i socket TCP è che in
-questo caso è perfettamente legale inviare con \func{sendto} un pacchetto
-vuoto (che nel caso conterrà solo le intestazioni di IP e di UDP),
-specificando un valore nullo per \param{len}. Allo stesso modo è possibile
+usuali \func{read} e \func{write} che abbiamo usato con i socket TCP è che in
+questo caso è perfettamente legale inviare con \func{sendto} un pacchetto
+vuoto (che nel caso conterrà solo le intestazioni di IP e di UDP),
+specificando un valore nullo per \param{len}. Allo stesso modo è possibile
 ricevere con \func{recvfrom} un valore di ritorno di 0 byte, senza che questo
 possa configurarsi come una chiusura della connessione\footnote{dato che la
   connessione non esiste, non ha senso parlare di chiusura della connessione,
-  questo significa anche che con i socket UDP non è necessario usare
+  questo significa anche che con i socket UDP non è necessario usare
   \func{close} o \func{shutdown} per terminare la comunicazione.} o come una
 cessazione delle comunicazioni.
 
@@ -302,9 +302,9 @@ cessazione delle comunicazioni.
 Vediamo allora come implementare un primo client elementare con dei socket
 UDP.  Ricalcando quanto fatto nel caso dei socket TCP prenderemo come primo
 esempio l'uso del servizio \textit{daytime}, utilizzando questa volta UDP. Il
-servizio è definito nell'\href{http://www.ietf.org/rfc/rfc0862.txt}{RFC~867},
+servizio è definito nell'\href{http://www.ietf.org/rfc/rfc0862.txt}{RFC~867},
 che nel caso di uso di UDP prescrive che il client debba inviare un pacchetto
-UDP al server (di contenuto non specificato), il quale risponderà a inviando a
+UDP al server (di contenuto non specificato), il quale risponderà a inviando a
 sua volta un pacchetto UDP contenente la data.
 
 \begin{figure}[!htb] 
@@ -318,10 +318,10 @@ sua volta un pacchetto UDP contenente la data.
   \label{fig:UDP_daytime_client}
 \end{figure}
 
-In fig.~\ref{fig:UDP_daytime_client} è riportato la sezione principale del
+In fig.~\ref{fig:UDP_daytime_client} è riportato la sezione principale del
 codice del nostro client, il sorgente completo si trova nel file
 \file{UDP\_daytime.c} distribuito con gli esempi allegati alla guida; al
-solito si è tralasciato di riportare in figura la sezione relativa alla
+solito si è tralasciato di riportare in figura la sezione relativa alla
 gestione delle opzioni a riga di comando (nel caso praticamente assenti).
 
 Il programma inizia (\texttt{\small 9--12}) con la creazione del socket, al
@@ -331,7 +331,7 @@ fig.~\ref{fig:TCP_daytime_client_code} si sia usato per il tipo di socket il
 valore \const{SOCK\_DGRAM}, pur mantenendosi nella stessa famiglia data da
 \const{AF\_INET}.
 
-Il passo successivo (\texttt{\small 13--21}) è l'inizializzazione della
+Il passo successivo (\texttt{\small 13--21}) è l'inizializzazione della
 struttura degli indirizzi; prima (\texttt{\small 14}) si cancella
 completamente la stessa con \func{memset}, (\texttt{\small 15}) poi si imposta
 la famiglia dell'indirizzo ed infine (\texttt{\small 16} la porta. Infine
@@ -339,25 +339,25 @@ la famiglia dell'indirizzo ed infine (\texttt{\small 16} la porta. Infine
 dall'argomento passato a riga di comando, convertendolo con \func{inet\_pton}.
 Si noti come questa sezione sia identica a quella del client TCP di
 fig.~\ref{fig:TCP_daytime_client_code}, in quanto la determinazione dell'uso
-di UDP al posto di TCP è stata effettuata quando si è creato il socket.
+di UDP al posto di TCP è stata effettuata quando si è creato il socket.
 
 Una volta completate le inizializzazioni inizia il corpo principale del
-programma, il primo passo è inviare, come richiesto dal protocollo, un
+programma, il primo passo è inviare, come richiesto dal protocollo, un
 pacchetto al server. Questo lo si fa (\texttt{\small 16}) inviando un
 pacchetto vuoto (si ricordi quanto detto in
 sez.~\ref{sec:UDP_sendto_recvfrom}) con \func{sendto}, avendo cura di passare
 un valore nullo per il puntatore al buffer e la lunghezza del messaggio. In
-realtà il protocollo non richiede che il pacchetto sia vuoto, ma dato che il
-server comunque ne ignorerà il contenuto, è inutile inviare dei dati.
+realtà il protocollo non richiede che il pacchetto sia vuoto, ma dato che il
+server comunque ne ignorerà il contenuto, è inutile inviare dei dati.
 
 Verificato (\texttt{\small 24--27}) che non ci siano stati errori nell'invio
 si provvede (\texttt{\small 28}) ad invocare \func{recvfrom} per ricevere la
 risposta del server. Si controlla poi (\texttt{\small 29--32}) che non vi
 siano stati errori in ricezione (uscendo con un messaggio in caso contrario);
-se è tutto a posto la variabile \var{nread} conterrà la dimensione del
-messaggio di risposta inviato dal server che è stato memorizzato su
-\var{buffer}, se (\texttt{\small 34}) pertanto il valore è positivo si
-provvederà (\texttt{\small 35}) a terminare la stringa contenuta nel buffer di
+se è tutto a posto la variabile \var{nread} conterrà la dimensione del
+messaggio di risposta inviato dal server che è stato memorizzato su
+\var{buffer}, se (\texttt{\small 34}) pertanto il valore è positivo si
+provvederà (\texttt{\small 35}) a terminare la stringa contenuta nel buffer di
 lettura\footnote{si ricordi che, come illustrato in
   sez.~\ref{sec:TCP_daytime_client}, il server invia in risposta una stringa
   contenente la data, terminata dai due caratteri CR e LF, che pertanto prima
@@ -366,8 +366,8 @@ stamparla (\texttt{\small 36}) sullo standard output, controllando anche in
 questo caso (\texttt{\small 36--38}) l'esito dell'operazione, ed uscendo con
 un messaggio in caso di errore.
 
-Se pertanto si è avuto cura di attivare il server del servizio
-\textit{daytime}\footnote{di norma questo è un servizio standard fornito dal
+Se pertanto si è avuto cura di attivare il server del servizio
+\textit{daytime}\footnote{di norma questo è un servizio standard fornito dal
   \textsl{superdemone} \cmd{inetd}, per cui basta abilitarlo nel file di
   configurazione di quest'ultimo, avendo cura di predisporre il servizio su
   UDP.} potremo verificare il funzionamento del nostro client interrogando
@@ -386,15 +386,15 @@ tcpdump: listening on lo
 23:41:21.645710 localhost.daytime > localhost.32780: udp 26 (DF)
 \end{verbatim}
 
-Una differenza fondamentale del nostro client è che in questo caso, non
-disponendo di una connessione, è per lui impossibile riconoscere errori di
+Una differenza fondamentale del nostro client è che in questo caso, non
+disponendo di una connessione, è per lui impossibile riconoscere errori di
 invio relativi alla rete. La funzione \func{sendto} infatti riporta solo
 errori locali, i dati vengono comunque scritti e la funzione ritorna senza
-errori anche se il server non è raggiungibile o non esiste un server in
+errori anche se il server non è raggiungibile o non esiste un server in
 ascolto sull'indirizzo di destinazione. Questo comporta ad esempio che se si
-usa il nostro programma interrogando un server inesistente questo resterà
+usa il nostro programma interrogando un server inesistente questo resterà
 perennemente bloccato nella chiamata a \func{recvfrom}, fin quando non lo
-interromperemo. Vedremo in sez.~\ref{sec:UDP_connect} come si può porre rimedio
+interromperemo. Vedremo in sez.~\ref{sec:UDP_connect} come si può porre rimedio
 a questa problematica.
 
 
@@ -403,7 +403,7 @@ a questa problematica.
 
 Nella sezione precedente abbiamo visto come scrivere un client elementare per
 servizio \textit{daytime}, vediamo in questa come deve essere scritto un
-server.  Si ricordi che il compito di quest'ultimo è quello di ricevere un
+server.  Si ricordi che il compito di quest'ultimo è quello di ricevere un
 pacchetto di richiesta ed inviare in risposta un pacchetto contenente una
 stringa con la data corrente. 
 
@@ -418,75 +418,75 @@ stringa con la data corrente.
   \label{fig:UDP_daytime_server}
 \end{figure}
 
-In fig.~\ref{fig:UDP_daytime_server} è riportato la sezione principale del
+In fig.~\ref{fig:UDP_daytime_server} è riportato la sezione principale del
 codice del nostro client, il sorgente completo si trova nel file
 \file{UDP\_daytimed.c} distribuito con gli esempi allegati alla guida; anche
-in questo caso si è omessa la sezione relativa alla gestione delle opzioni a
-riga di comando (la sola presente è \texttt{-v} che permette di stampare a
+in questo caso si è omessa la sezione relativa alla gestione delle opzioni a
+riga di comando (la sola presente è \texttt{-v} che permette di stampare a
 video l'indirizzo associato ad ogni richiesta).
 
-Anche in questo caso la prima parte del server (\texttt{\small 9--23}) è
+Anche in questo caso la prima parte del server (\texttt{\small 9--23}) è
 sostanzialmente identica a quella dell'analogo server per TCP illustrato in
 fig.~\ref{fig:TCP_daytime_cunc_server_code}; si inizia (\texttt{\small 10})
 con il creare il socket, uscendo con un messaggio in caso di errore
 (\texttt{\small 10--13}), e di nuovo la sola differenza con il caso precedente
-è il diverso tipo di socket utilizzato. Dopo di che (\texttt{\small 14--18})
-si inizializza la struttura degli indirizzi che poi (\texttt{\small 20}) verrà
+è il diverso tipo di socket utilizzato. Dopo di che (\texttt{\small 14--18})
+si inizializza la struttura degli indirizzi che poi (\texttt{\small 20}) verrà
 usata da \func{bind}; si cancella (\texttt{\small 15}) preventivamente il
 contenuto, si imposta (\texttt{\small 16}) la famiglia dell'indirizzo, la
 porta (\texttt{\small 17}) e l'indirizzo (\texttt{\small 18}) su cui si
 riceveranno i pacchetti.  Si noti come in quest'ultimo sia l'indirizzo
 generico \const{INADDR\_ANY}; questo significa (si ricordi quanto illustrato
-in sez.~\ref{sec:TCP_func_bind}) che il server accetterà pacchetti su uno
+in sez.~\ref{sec:TCP_func_bind}) che il server accetterà pacchetti su uno
 qualunque degli indirizzi presenti sulle interfacce di rete della macchina.
 
-Completata l'inizializzazione tutto quello che resta da fare è eseguire
+Completata l'inizializzazione tutto quello che resta da fare è eseguire
 (\texttt{\small 20--23}) la chiamata a \func{bind}, controllando la presenza
 di eventuali errori, ed uscendo con un avviso qualora questo fosse il caso.
-Nel caso di socket UDP questo è tutto quello che serve per consentire al
-server di ricevere i pacchetti a lui indirizzati, e non è più necessario
+Nel caso di socket UDP questo è tutto quello che serve per consentire al
+server di ricevere i pacchetti a lui indirizzati, e non è più necessario
 chiamare successivamente \func{listen}. In questo caso infatti non esiste il
 concetto di connessione, e quindi non deve essere predisposta una coda delle
 connessioni entranti. Nel caso di UDP i pacchetti arrivano al kernel con un
 certo indirizzo ed una certa porta di destinazione, il kernel controlla se
-corrispondono ad un socket che è stato \textsl{legato} ad essi con
-\func{bind}, qualora questo sia il caso scriverà il contenuto all'interno del
-socket, così che il programma possa leggerlo, altrimenti risponderà alla
+corrispondono ad un socket che è stato \textsl{legato} ad essi con
+\func{bind}, qualora questo sia il caso scriverà il contenuto all'interno del
+socket, così che il programma possa leggerlo, altrimenti risponderà alla
 macchina che ha inviato il pacchetto con un messaggio ICMP di tipo
 \textit{port unreachable}.
 
 Una volta completata la fase di inizializzazione inizia il corpo principale
 (\texttt{\small 24--44}) del server, mantenuto all'interno di un ciclo
 infinito in cui si trattano le richieste. Il ciclo inizia (\texttt{\small 26})
-con una chiamata a \func{recvfrom}, che si bloccherà in attesa di pacchetti
-inviati dai client. Lo scopo della funzione è quello di ritornare tutte le
+con una chiamata a \func{recvfrom}, che si bloccherà in attesa di pacchetti
+inviati dai client. Lo scopo della funzione è quello di ritornare tutte le
 volte che un pacchetto viene inviato al server, in modo da poter ricavare da
 esso l'indirizzo del client a cui inviare la risposta in \var{addr}. Per
 questo motivo in questo caso (al contrario di quanto fatto in
-fig.~\ref{fig:UDP_daytime_client}) si è avuto cura di passare gli argomenti
+fig.~\ref{fig:UDP_daytime_client}) si è avuto cura di passare gli argomenti
 \var{addr} e \var{len} alla funzione.  Dopo aver controllato (\texttt{\small
   27--30}) la presenza di eventuali errori (uscendo con un messaggio di errore
-qualora ve ne siano) si verifica (\texttt{\small 31}) se è stata attivata
+qualora ve ne siano) si verifica (\texttt{\small 31}) se è stata attivata
 l'opzione \texttt{-v} (che imposta la variabile \var{verbose}) stampando nel
-caso (\texttt{\small 32--35}) l'indirizzo da cui si è appena ricevuto una
-richiesta (questa sezione è identica a quella del server TCP illustrato in
+caso (\texttt{\small 32--35}) l'indirizzo da cui si è appena ricevuto una
+richiesta (questa sezione è identica a quella del server TCP illustrato in
 fig.~\ref{fig:TCP_daytime_cunc_server_code}).
 
 Una volta ricevuta la richiesta resta solo da ottenere il tempo corrente
 (\texttt{\small 36}) e costruire (\texttt{\small 37}) la stringa di risposta,
-che poi verrà inviata (\texttt{\small 38}) al client usando \func{sendto},
+che poi verrà inviata (\texttt{\small 38}) al client usando \func{sendto},
 avendo al solito cura di controllare (\texttt{\small 40--42}) lo stato di
 uscita della funzione e trattando opportunamente la condizione di errore.
 
-Si noti come per le peculiarità del protocollo si sia utilizzato un server
+Si noti come per le peculiarità del protocollo si sia utilizzato un server
 iterativo, che processa le richieste una alla volta via via che gli arrivano.
-Questa è una caratteristica comune dei server UDP, conseguenza diretta del
-fatto che non esiste il concetto di connessione, per cui non c'è la necessità
-di trattare separatamente le singole connessioni. Questo significa anche che è
-il kernel a gestire la possibilità di richieste multiple in contemporanea;
-quello che succede è semplicemente che il kernel accumula in un buffer in
+Questa è una caratteristica comune dei server UDP, conseguenza diretta del
+fatto che non esiste il concetto di connessione, per cui non c'è la necessità
+di trattare separatamente le singole connessioni. Questo significa anche che è
+il kernel a gestire la possibilità di richieste multiple in contemporanea;
+quello che succede è semplicemente che il kernel accumula in un buffer in
 ingresso i pacchetti UDP che arrivano e li restituisce al processo uno alla
-volta per ciascuna chiamata di \func{recvfrom}; nel nostro caso sarà poi
+volta per ciascuna chiamata di \func{recvfrom}; nel nostro caso sarà poi
 compito del server distribuire le risposte sulla base dell'indirizzo da cui
 provengono le richieste.
 
@@ -495,18 +495,18 @@ provengono le richieste.
 \label{sec:UDP_problems}
 
 L'esempio del servizio \textit{daytime} illustrato nelle precedenti sezioni
-è in realtà piuttosto particolare, e non evidenzia quali possono essere i
-problemi collegati alla mancanza di affidabilità e all'assenza del concetto di
+è in realtà piuttosto particolare, e non evidenzia quali possono essere i
+problemi collegati alla mancanza di affidabilità e all'assenza del concetto di
 connessione che sono tipiche dei socket UDP. In tal caso infatti il protocollo
-è estremamente semplice, dato che la comunicazione consiste sempre in una
+è estremamente semplice, dato che la comunicazione consiste sempre in una
 richiesta seguita da una risposta, per uno scambio di dati effettuabile con un
-singolo pacchetto, per cui tutti gli eventuali problemi sarebbero assai più
+singolo pacchetto, per cui tutti gli eventuali problemi sarebbero assai più
 complessi da rilevare.
 
-Anche qui però possiamo notare che se il pacchetto di richiesta del client, o
-la risposta del server si perdono, il client resterà permanentemente bloccato
+Anche qui però possiamo notare che se il pacchetto di richiesta del client, o
+la risposta del server si perdono, il client resterà permanentemente bloccato
 nella chiamata a \func{recvfrom}. Per evidenziare meglio quali problemi si
-possono avere proviamo allora con un servizio leggermente più complesso come
+possono avere proviamo allora con un servizio leggermente più complesso come
 \textit{echo}. 
 
 \begin{figure}[!htb] 
@@ -520,15 +520,15 @@ possono avere proviamo allora con un servizio leggermente pi
   \label{fig:UDP_echo_client}
 \end{figure}
 
-In fig.~\ref{fig:UDP_echo_client} è riportato un estratto del corpo principale
+In fig.~\ref{fig:UDP_echo_client} è riportato un estratto del corpo principale
 del nostro client elementare per il servizio \textit{echo} (al solito il
-codice completo è con i sorgenti allegati). Le uniche differenze con l'analogo
+codice completo è con i sorgenti allegati). Le uniche differenze con l'analogo
 client visto in fig.~\ref{fig:TCP_echo_client_1} sono che al solito si crea
-(\texttt{\small 14}) un socket di tipo \const{SOCK\_DGRAM}, e che non è
+(\texttt{\small 14}) un socket di tipo \const{SOCK\_DGRAM}, e che non è
 presente nessuna chiamata a \func{connect}. Per il resto il funzionamento del
-programma è identico, e tutto il lavoro viene effettuato attraverso la
+programma è identico, e tutto il lavoro viene effettuato attraverso la
 chiamata (\texttt{\small 28}) alla funzione \func{ClientEcho} che stavolta
-però prende un argomento in più, che è l'indirizzo del socket.
+però prende un argomento in più, che è l'indirizzo del socket.
 
 \begin{figure}[!htb] 
   \footnotesize \centering
@@ -541,27 +541,27 @@ per
   \label{fig:UDP_echo_client_echo}
 \end{figure}
 
-Ovviamente in questo caso il funzionamento della funzione, il cui codice è
-riportato in fig.~\ref{fig:UDP_echo_client_echo}, è completamente diverso
+Ovviamente in questo caso il funzionamento della funzione, il cui codice è
+riportato in fig.~\ref{fig:UDP_echo_client_echo}, è completamente diverso
 rispetto alla analoga del server TCP, e dato che non esiste una connessione
-questa necessita anche di un terzo argomento, che è l'indirizzo del server cui
+questa necessita anche di un terzo argomento, che è l'indirizzo del server cui
 inviare i pacchetti.
 
-Data l'assenza di una connessione come nel caso di TCP il meccanismo è molto
-più semplice da gestire. Al solito si esegue un ciclo infinito (\texttt{\small
+Data l'assenza di una connessione come nel caso di TCP il meccanismo è molto
+più semplice da gestire. Al solito si esegue un ciclo infinito (\texttt{\small
   6--30}) che parte dalla lettura (\texttt{\small 7}) sul buffer di invio
-\var{sendbuff} di una stringa dallo standard input, se la stringa è vuota
-(\texttt{\small 7--9}), indicando che l'input è terminato, si ritorna
+\var{sendbuff} di una stringa dallo standard input, se la stringa è vuota
+(\texttt{\small 7--9}), indicando che l'input è terminato, si ritorna
 immediatamente causando anche la susseguente terminazione del programma.
 
 Altrimenti si procede (\texttt{\small 10--11}) all'invio della stringa al
 destinatario invocando \func{sendto}, utilizzando, oltre alla stringa appena
 letta, gli argomenti passati nella chiamata a \func{ClientEcho}, ed in
-particolare l'indirizzo del server che si è posto in \var{serv\_addr}; qualora
-(\texttt{\small 12}) si riscontrasse un errore si provvederà al solito
+particolare l'indirizzo del server che si è posto in \var{serv\_addr}; qualora
+(\texttt{\small 12}) si riscontrasse un errore si provvederà al solito
 (\texttt{\small 13--14}) ad uscire con un messaggio di errore.
 
-Il passo immediatamente seguente (\texttt{\small 17}) l'invio è quello di
+Il passo immediatamente seguente (\texttt{\small 17}) l'invio è quello di
 leggere l'eventuale risposta del server con \func{recvfrom}; si noti come in
 questo caso si sia scelto di ignorare l'indirizzo dell'eventuale pacchetto di
 risposta, controllando (\texttt{\small 18--21}) soltanto la presenza di un
@@ -572,15 +572,15 @@ sez.~\ref{sec:TCP_echo_client} non si sia controllato il caso di un messaggio
 nullo, dato che, nel caso di socket UDP, questo non significa la terminazione
 della comunicazione.
 
-L'ultimo passo (\texttt{\small 17}) è quello di terminare opportunamente la
+L'ultimo passo (\texttt{\small 17}) è quello di terminare opportunamente la
 stringa di risposta nel relativo buffer per poi provvedere alla sua stampa
 sullo standard output, eseguendo il solito controllo (ed eventuale uscita con
 adeguato messaggio informativo) in caso di errore.
 
-In genere fintanto che si esegue il nostro client in locale non sorgerà nessun
-problema, se però si proverà ad eseguirlo attraverso un collegamento remoto
+In genere fintanto che si esegue il nostro client in locale non sorgerà nessun
+problema, se però si proverà ad eseguirlo attraverso un collegamento remoto
 (nel caso dell'esempio seguente su una VPN, attraverso una ADSL abbastanza
-congestionata) e in modalità non interattiva, la probabilità di perdere
+congestionata) e in modalità non interattiva, la probabilità di perdere
 qualche pacchetto aumenta, ed infatti, eseguendo il comando come:
 \begin{verbatim}
 [piccardi@gont sources]$ cat UDP_echo.c | ./echo 192.168.1.120
@@ -593,8 +593,8 @@ qualche pacchetto aumenta, ed infatti, eseguendo il comando come:
  * Include needed headers
 
 \end{verbatim}%$
-si otterrà che, dopo aver correttamente stampato alcune righe, il programma si
-blocca completamente senza stampare più niente. Se al contempo si fosse tenuto
+si otterrà che, dopo aver correttamente stampato alcune righe, il programma si
+blocca completamente senza stampare più niente. Se al contempo si fosse tenuto
 sotto controllo il traffico UDP diretto o proveniente dal servizio
 \textit{echo} con \cmd{tcpdump} si sarebbe ottenuto:
 \begin{verbatim}
@@ -608,15 +608,15 @@ sotto controllo il traffico UDP diretto o proveniente dal servizio
 18:48:17.965408 gont.earthsea.ea.32788 > 192.168.1.120.echo: udp 4 (DF)
 \end{verbatim}
 che come si vede il traffico fra client e server si interrompe dopo l'invio di
-un pacchetto UDP per il quale non si è ricevuto risposta.
-
-Il problema è che in tutti i casi in cui un pacchetto di risposta si perde, o
-una richiesta non arriva a destinazione, il nostro programma si bloccherà
-nell'esecuzione di \func{recvfrom}. Lo stesso avviene anche se il server non è
-in ascolto, in questo caso però, almeno dal punto di vista dello scambio di
-pacchetti, il risultato è diverso, se si lancia al solito il programma e si
-prova a scrivere qualcosa si avrà ugualmente un blocco su \func{recvfrom} ma
-se si osserva il traffico con \cmd{tcpdump} si vedrà qualcosa del tipo:
+un pacchetto UDP per il quale non si è ricevuto risposta.
+
+Il problema è che in tutti i casi in cui un pacchetto di risposta si perde, o
+una richiesta non arriva a destinazione, il nostro programma si bloccherà
+nell'esecuzione di \func{recvfrom}. Lo stesso avviene anche se il server non è
+in ascolto, in questo caso però, almeno dal punto di vista dello scambio di
+pacchetti, il risultato è diverso, se si lancia al solito il programma e si
+prova a scrivere qualcosa si avrà ugualmente un blocco su \func{recvfrom} ma
+se si osserva il traffico con \cmd{tcpdump} si vedrà qualcosa del tipo:
 \begin{verbatim}
 [root@gont gapil]# tcpdump  \( dst 192.168.0.2 and src 192.168.1.120 \) \
    or \( src 192.168.0.2 and dst 192.168.1.120 \)
@@ -625,35 +625,35 @@ tcpdump: listening on eth0
 00:43:27.990560 192.168.1.120 > gont.earthsea.ea: icmp: 192.168.1.120 udp port 
 echo unreachable [tos 0xc0]
 \end{verbatim}
-cioè in questo caso si avrà in risposta un pacchetto ICMP di destinazione
+cioè in questo caso si avrà in risposta un pacchetto ICMP di destinazione
 irraggiungibile che ci segnala che la porta in questione non risponde. 
 
-Ci si può chiedere allora perché, benché la situazione di errore sia
-rilevabile, questa non venga segnalata. Il luogo più naturale in cui
-riportarla sarebbe la chiamata di \func{sendto}, in quanto è a causa dell'uso
-di un indirizzo sbagliato che il pacchetto non può essere inviato; farlo in
-questo punto però è impossibile, dato che l'interfaccia di programmazione
+Ci si può chiedere allora perché, benché la situazione di errore sia
+rilevabile, questa non venga segnalata. Il luogo più naturale in cui
+riportarla sarebbe la chiamata di \func{sendto}, in quanto è a causa dell'uso
+di un indirizzo sbagliato che il pacchetto non può essere inviato; farlo in
+questo punto però è impossibile, dato che l'interfaccia di programmazione
 richiede che la funzione ritorni non appena il kernel invia il
-pacchetto,\footnote{questo è il classico caso di \textsl{errore asincrono},
-  una situazione cioè in cui la condizione di errore viene rilevata in maniera
-  asincrona rispetto all'operazione che l'ha causata, una eventualità
+pacchetto,\footnote{questo è il classico caso di \textsl{errore asincrono},
+  una situazione cioè in cui la condizione di errore viene rilevata in maniera
+  asincrona rispetto all'operazione che l'ha causata, una eventualità
   piuttosto comune quando si ha a che fare con la rete, tutti i pacchetti ICMP
-  che segnalano errori rientrano in questa tipologia.} e non può bloccarsi in
+  che segnalano errori rientrano in questa tipologia.} e non può bloccarsi in
 una attesa di una risposta che potrebbe essere molto lunga (si noti infatti
-che il pacchetto ICMP arriva qualche decimo di secondo più tardi) o non
+che il pacchetto ICMP arriva qualche decimo di secondo più tardi) o non
 esserci affatto.
 
-Si potrebbe allora pensare di riportare l'errore nella \func{recvfrom} che è
-comunque bloccata in attesa di una risposta che nel caso non arriverà mai.  La
-ragione per cui non viene fatto è piuttosto sottile e viene spiegata da
+Si potrebbe allora pensare di riportare l'errore nella \func{recvfrom} che è
+comunque bloccata in attesa di una risposta che nel caso non arriverà mai.  La
+ragione per cui non viene fatto è piuttosto sottile e viene spiegata da
 Stevens in \cite{UNP2} con il seguente esempio: si consideri un client che
 invia tre pacchetti a tre diverse macchine, due dei quali vengono regolarmente
 ricevuti, mentre al terzo, non essendo presente un server sulla relativa
 macchina, viene risposto con un messaggio ICMP come il precedente. Detto
-messaggio conterrà anche le informazioni relative ad indirizzo e porta del
-pacchetto che ha fallito, però tutto quello che il kernel può restituire al
-programma è un codice di errore in \var{errno}, con il quale è impossibile di
-distinguere per quale dei pacchetti inviati si è avuto l'errore; per questo è
+messaggio conterrà anche le informazioni relative ad indirizzo e porta del
+pacchetto che ha fallito, però tutto quello che il kernel può restituire al
+programma è un codice di errore in \var{errno}, con il quale è impossibile di
+distinguere per quale dei pacchetti inviati si è avuto l'errore; per questo è
 stata fatta la scelta di non riportare un errore su un socket UDP, a meno che,
 come vedremo in sez.~\ref{sec:UDP_connect}, questo non sia connesso.
 
@@ -663,31 +663,31 @@ come vedremo in sez.~\ref{sec:UDP_connect}, questo non sia connesso.
 \label{sec:UDP_connect}
 
 Come illustrato in sez.~\ref{sec:UDP_characteristics} essendo i socket UDP
-privi di connessione non è necessario per i client usare \func{connect} prima
-di iniziare una comunicazione con un server. Ciò non di meno abbiamo accennato
+privi di connessione non è necessario per i client usare \func{connect} prima
+di iniziare una comunicazione con un server. Ciò non di meno abbiamo accennato
 come questa possa essere utilizzata per gestire la presenza di errori
 asincroni.
 
-Quando si chiama \func{connect} su di un socket UDP tutto quello che succede è
+Quando si chiama \func{connect} su di un socket UDP tutto quello che succede è
 che l'indirizzo passato alla funzione viene registrato come indirizzo di
 destinazione del socket. A differenza di quanto avviene con TCP non viene
-scambiato nessun pacchetto, tutto quello che succede è che da quel momento in
-qualunque cosa si scriva sul socket sarà inviata a quell'indirizzo; non sarà
-più necessario usare l'argomento \param{to} di \func{sendto} per specificare
+scambiato nessun pacchetto, tutto quello che succede è che da quel momento in
+qualunque cosa si scriva sul socket sarà inviata a quell'indirizzo; non sarà
+più necessario usare l'argomento \param{to} di \func{sendto} per specificare
 la destinazione dei pacchetti, che potranno essere inviati e ricevuti usando
-le normali funzioni \func{read} e \func{write}.\footnote{in realtà si può
+le normali funzioni \func{read} e \func{write}.\footnote{in realtà si può
   anche continuare ad usare la funzione \func{sendto}, ma in tal caso
   l'argomento \param{to} deve essere inizializzato a \const{NULL}, e
   \param{tolen} deve essere inizializzato a zero, pena un errore.}
 
-Una volta che il socket è connesso cambia però anche il comportamento in
+Una volta che il socket è connesso cambia però anche il comportamento in
 ricezione; prima infatti il kernel avrebbe restituito al socket qualunque
 pacchetto ricevuto con un indirizzo di destinazione corrispondente a quello
 del socket, senza nessun controllo sulla sorgente; una volta che il socket
 viene connesso saranno riportati su di esso solo i pacchetti con un indirizzo
-sorgente corrispondente a quello a cui ci si è connessi.
+sorgente corrispondente a quello a cui ci si è connessi.
 
-Infine quando si usa un socket connesso, venendo meno l'ambiguità segnalata
+Infine quando si usa un socket connesso, venendo meno l'ambiguità segnalata
 alla fine di sez.~\ref{sec:UDP_problems}, tutti gli eventuali errori asincroni
 vengono riportati alle funzioni che operano su di esso; pertanto potremo
 riscrivere il nostro client per il servizio \textit{echo} con le modifiche
@@ -704,9 +704,9 @@ illustrate in fig.~\ref{fig:UDP_echo_conn_cli}.
   \label{fig:UDP_echo_conn_cli}
 \end{figure}
 
-Ed in questo caso rispetto alla precedente versione, il solo cambiamento è
+Ed in questo caso rispetto alla precedente versione, il solo cambiamento è
 l'utilizzo (\texttt{\small 17}) della funzione \func{connect} prima della
-chiamata alla funzione di gestione del protocollo, che a sua volta è stata
+chiamata alla funzione di gestione del protocollo, che a sua volta è stata
 modificata eliminando l'indirizzo passato come argomento e sostituendo le
 chiamata a \func{sendto} e \func{recvfrom} con chiamate a \func{read} e
 \func{write} come illustrato dal nuovo codice riportato in
@@ -722,9 +722,9 @@ fig.~\ref{fig:UDP_echo_conn_echo_client}.
   \label{fig:UDP_echo_conn_echo_client}
 \end{figure}
 
-Utilizzando questa nuova versione del client si può verificare che quando ci
-si rivolge verso un indirizzo inesistente o su cui non è in ascolto un server
-si è in grado rilevare l'errore, se infatti eseguiamo il nuovo programma
+Utilizzando questa nuova versione del client si può verificare che quando ci
+si rivolge verso un indirizzo inesistente o su cui non è in ascolto un server
+si è in grado rilevare l'errore, se infatti eseguiamo il nuovo programma
 otterremo un qualcosa del tipo:
 \begin{verbatim}
 [piccardi@gont sources]$ ./echo 192.168.1.1
@@ -733,18 +733,18 @@ Errore in lettura: Connection refused
 \end{verbatim}%$
 
 Ma si noti che a differenza di quanto avveniva con il client TCP qui l'errore
-viene rilevato soltanto dopo che si è tentato di inviare qualcosa, ed in
-corrispondenza al tentativo di lettura della risposta. Questo avviene perché
+viene rilevato soltanto dopo che si è tentato di inviare qualcosa, ed in
+corrispondenza al tentativo di lettura della risposta. Questo avviene perché
 con UDP non esiste una connessione, e fintanto che non si invia un pacchetto
-non c'è traffico sulla rete. In questo caso l'errore sarà rilevato alla
+non c'è traffico sulla rete. In questo caso l'errore sarà rilevato alla
 ricezione del pacchetto ICMP \textit{destination unreachable} emesso dalla
-macchina cui ci si è rivolti, e questa volta, essendo il socket UDP connesso,
-il kernel potrà riportare detto errore in user space in maniera non ambigua,
-ed esso apparirà alla successiva lettura sul socket.
+macchina cui ci si è rivolti, e questa volta, essendo il socket UDP connesso,
+il kernel potrà riportare detto errore in user space in maniera non ambigua,
+ed esso apparirà alla successiva lettura sul socket.
 
 Si tenga presente infine che l'uso dei socket connessi non risolve l'altro
-problema del client, e cioè il fatto che in caso di perdita di un pacchetto
-questo resterà bloccato permanentemente in attesa di una risposta. Per
+problema del client, e cioè il fatto che in caso di perdita di un pacchetto
+questo resterà bloccato permanentemente in attesa di una risposta. Per
 risolvere questo problema l'unico modo sarebbe quello di impostare un
 \textit{timeout} o riscrivere il client in modo da usare l'I/O non bloccante.
 
@@ -756,9 +756,9 @@ risolvere questo problema l'unico modo sarebbe quello di impostare un
 \section{I socket \textit{Unix domain}}
 \label{sec:unix_socket}
 
-Benché i socket Unix domain, come meccanismo di comunicazione fra processi che
+Benché i socket Unix domain, come meccanismo di comunicazione fra processi che
 girano sulla stessa macchina, non siano strettamente attinenti alla rete, li
-tratteremo comunque in questa sezione. Nonostante le loro peculiarità infatti,
+tratteremo comunque in questa sezione. Nonostante le loro peculiarità infatti,
 l'interfaccia di programmazione che serve ad utilizzarli resta sempre quella
 dei socket.
 
diff --git a/preambolo.tex b/preambolo.tex
index efdc068..6afe1b8 100644
--- a/preambolo.tex
+++ b/preambolo.tex
@@ -12,17 +12,17 @@
 \chapter{Un preambolo}
 \label{cha:preamble}
 
-Questa guida nasce dalla mia profonda convinzione che le istanze di libertà e
+Questa guida nasce dalla mia profonda convinzione che le istanze di libertà e
 di condivisione della conoscenza che hanno dato vita a quello straordinario
 movimento di persone ed intelligenza che va sotto il nome di \textsl{software
   libero} hanno la stessa rilevanza anche quando applicate alla produzione
 culturale in genere.
 
-L'ambito più comune in cui questa filosofia viene applicata è quello della
-documentazione perché il software, per quanto possa essere libero, se non
+L'ambito più comune in cui questa filosofia viene applicata è quello della
+documentazione perché il software, per quanto possa essere libero, se non
 accompagnato da una buona documentazione che aiuti a comprenderne il
 funzionamento, rischia di essere fortemente deficitario riguardo ad una delle
-libertà fondamentali, quella di essere studiato e migliorato.
+libertà fondamentali, quella di essere studiato e migliorato.
 
 Ritengo inoltre che in campo tecnico ed educativo sia importante poter
 disporre di testi didattici (come manuali, enciclopedie, dizionari, ecc.) in
@@ -30,32 +30,32 @@ grado di crescere, essere adattati alle diverse esigenze, modificati e
 ampliati, o anche ridotti per usi specifici, nello stesso modo in cui si fa
 per il software libero.
 
-Questa guida è il mio tentativo di restituire indietro, nei limiti di quelle
-che sono le mie capacità, un po' della conoscenza che ho ricevuto, mettendo a
+Questa guida è il mio tentativo di restituire indietro, nei limiti di quelle
+che sono le mie capacità, un po' della conoscenza che ho ricevuto, mettendo a
 disposizione un testo che possa fare da riferimento a chi si avvicina alla
 programmazione su Linux, nella speranza anche di trasmettergli non solo delle
-conoscenze tecniche, ma anche un po' di quella passione per la libertà e la
+conoscenze tecniche, ma anche un po' di quella passione per la libertà e la
 condivisione della conoscenza che sono la ricchezza maggiore che ho ricevuto.
 
-E, come per il software libero, anche in questo caso è importante la
-possibilità di accedere ai sorgenti (e non solo al risultato finale, sia
-questo una stampa o un file formattato) e la libertà di modificarli per
+E, come per il software libero, anche in questo caso è importante la
+possibilità di accedere ai sorgenti (e non solo al risultato finale, sia
+questo una stampa o un file formattato) e la libertà di modificarli per
 apportarvi migliorie, aggiornamenti, ecc.
 
 Per questo motivo la Free Software Foundation ha creato una apposita licenza
 che potesse giocare lo stesso ruolo fondamentale che la GPL ha avuto per il
-software libero nel garantire la permanenza delle libertà date, ma potesse
+software libero nel garantire la permanenza delle libertà date, ma potesse
 anche tenere conto delle differenze che comunque ci sono fra un testo ed un
 programma.
 
-Una di queste differenze è che in un testo, come in questa sezione, possono
+Una di queste differenze è che in un testo, come in questa sezione, possono
 venire espresse quelle che sono le idee ed i punti di vista dell'autore, e
 mentre trovo che sia necessario permettere cambiamenti nei contenuti tecnici,
 che devono essere aggiornati e corretti, non vale lo stesso per l'espressione
 delle mie idee contenuta in questa sezione, che ho richiesto resti invariata.
 
 Il progetto pertanto prevede il rilascio della guida con licenza GNU FDL, ed
-una modalità di realizzazione aperta che permetta di accogliere i contributi
+una modalità di realizzazione aperta che permetta di accogliere i contributi
 di chiunque sia interessato. Tutti i programmi di esempio sono rilasciati con
 licenza GNU GPL.
 
diff --git a/pref.tex b/pref.tex
index 9d31a54..91c6536 100644
--- a/pref.tex
+++ b/pref.tex
@@ -12,52 +12,52 @@
 \chapter{Prefazione}
 \label{cha:preface}
 
-Questo progetto mira alla stesura di un testo il più completo e chiaro
+Questo progetto mira alla stesura di un testo il più completo e chiaro
 possibile sulla programmazione di sistema su un kernel Linux.  Essendo i
 concetti in gran parte gli stessi, il testo dovrebbe restare valido anche per
 la programmazione in ambito di sistemi Unix generici, ma resta una attenzione
 specifica alle caratteristiche peculiari del kernel Linux e delle versioni
-delle librerie del C in uso con esso; in particolare si darà ampio spazio alla
+delle librerie del C in uso con esso; in particolare si darà ampio spazio alla
 versione realizzata dal progetto GNU, le cosiddette \textit{GNU C Library} o
 \textsl{glibc}, che ormai sono usate nella stragrande maggioranza dei casi,
-senza tralasciare, là dove note, le differenze con altre implementazioni come
+senza tralasciare, là dove note, le differenze con altre implementazioni come
 le \textsl{libc5} o le \textsl{uclib}.
 
-L'obiettivo finale di questo progetto è quello di riuscire a ottenere un testo
+L'obiettivo finale di questo progetto è quello di riuscire a ottenere un testo
 utilizzabile per apprendere i concetti fondamentali della programmazione di
-sistema della stessa qualità dei libri del compianto R. W. Stevens (è un
+sistema della stessa qualità dei libri del compianto R. W. Stevens (è un
 progetto molto ambizioso ...).
 
-Infatti benché le pagine di manuale del sistema (quelle che si accedono con il
+Infatti benché le pagine di manuale del sistema (quelle che si accedono con il
 comando \cmd{man}) e il manuale delle librerie del C GNU siano una fonte
-inesauribile di informazioni (da cui si è costantemente attinto nella stesura
+inesauribile di informazioni (da cui si è costantemente attinto nella stesura
 di tutto il testo) la loro struttura li rende totalmente inadatti ad una
 trattazione che vada oltre la descrizione delle caratteristiche particolari
 dello specifico argomento in esame (ed in particolare lo \textit{GNU C Library
   Reference Manual} non brilla per chiarezza espositiva).
 
-Per questo motivo si è cercato di fare tesoro di quanto appreso dai testi di
+Per questo motivo si è cercato di fare tesoro di quanto appreso dai testi di
 R. W. Stevens (in particolare \cite{APUE} e \cite{UNP1}) per rendere la
-trattazione dei vari argomenti in una sequenza logica il più esplicativa
+trattazione dei vari argomenti in una sequenza logica il più esplicativa
 possibile, corredando il tutto, quando possibile, con programmi di esempio.
 
 Dato che sia il kernel che tutte le librerie fondamentali di GNU/Linux sono
-scritte in C, questo sarà il linguaggio di riferimento del testo. In
+scritte in C, questo sarà il linguaggio di riferimento del testo. In
 particolare il compilatore usato per provare tutti i programmi e gli esempi
-descritti nel testo è lo GNU GCC. Il testo presuppone una conoscenza media del
+descritti nel testo è lo GNU GCC. Il testo presuppone una conoscenza media del
 linguaggio, e di quanto necessario per scrivere, compilare ed eseguire un
 programma.
 
-Infine, dato che lo scopo del progetto è la produzione di un libro, si è
+Infine, dato che lo scopo del progetto è la produzione di un libro, si è
 scelto di usare \LaTeX\ come "ambiente di sviluppo" del medesimo, sia per
-l'impareggiabile qualità tipografica ottenibile, che per la congruenza dello
+l'impareggiabile qualità tipografica ottenibile, che per la congruenza dello
 strumento con il fine, tanto sul piano pratico, quanto su quello filosofico.
 
-Il testo sarà, almeno inizialmente, in italiano. Per il momento lo si è
+Il testo sarà, almeno inizialmente, in italiano. Per il momento lo si è
 suddiviso in due parti, la prima sulla programmazione di sistema, in cui si
-trattano le varie funzionalità disponibili per i programmi che devono essere
+trattano le varie funzionalità disponibili per i programmi che devono essere
 eseguiti su una singola macchina, la seconda sulla programmazione di rete, in
-cui si trattano le funzionalità per eseguire programmi che mettono in
+cui si trattano le funzionalità per eseguire programmi che mettono in
 comunicazione macchine diverse.
 
 
diff --git a/process.tex b/process.tex
index 8194013..dfb5d2b 100644
--- a/process.tex
+++ b/process.tex
@@ -12,10 +12,10 @@
 \chapter{L'interfaccia base con i processi}
 \label{cha:process_interface}
 
-Come accennato nell'introduzione il \textsl{processo} è l'unità di base con
+Come accennato nell'introduzione il \textsl{processo} è l'unità di base con
 cui un sistema unix-like alloca ed utilizza le risorse.  Questo capitolo
-tratterà l'interfaccia base fra il sistema e i processi, come vengono passati
-gli argomenti, come viene gestita e allocata la memoria, come un processo può
+tratterà l'interfaccia base fra il sistema e i processi, come vengono passati
+gli argomenti, come viene gestita e allocata la memoria, come un processo può
 richiedere servizi al sistema e cosa deve fare quando ha finito la sua
 esecuzione. Nella sezione finale accenneremo ad alcune problematiche generiche
 di programmazione.
@@ -29,14 +29,14 @@ punto di vista del programma che viene messo in esecuzione.
 
 \section{Esecuzione e conclusione di un programma}
 
-Uno dei concetti base di Unix è che un processo esegue sempre uno ed un solo
-programma: si possono avere più processi che eseguono lo stesso programma ma
-ciascun processo vedrà la sua copia del codice (in realtà il kernel fa sì che
-tutte le parti uguali siano condivise), avrà un suo spazio di indirizzi,
-variabili proprie e sarà eseguito in maniera completamente indipendente da
-tutti gli altri.\footnote{questo non è del tutto vero nel caso di un programma
+Uno dei concetti base di Unix è che un processo esegue sempre uno ed un solo
+programma: si possono avere più processi che eseguono lo stesso programma ma
+ciascun processo vedrà la sua copia del codice (in realtà il kernel fa sì che
+tutte le parti uguali siano condivise), avrà un suo spazio di indirizzi,
+variabili proprie e sarà eseguito in maniera completamente indipendente da
+tutti gli altri.\footnote{questo non è del tutto vero nel caso di un programma
   \textit{multi-thread}, ma la gestione dei \itindex{thread} \textit{thread}
-  in Linux sarà trattata a parte in cap.~\ref{cha:threads}.}
+  in Linux sarà trattata a parte in cap.~\ref{cha:threads}.}
 
 
 \subsection{La funzione \func{main}} 
@@ -48,25 +48,25 @@ le librerie condivise che servono al programma, poi effettua il collegamento
 dinamico del codice e alla fine lo esegue. Infatti, a meno di non aver
 specificato il flag \texttt{-static} durante la compilazione, tutti i
 programmi in Linux sono incompleti e necessitano di essere \textsl{collegati}
-alle librerie condivise quando vengono avviati.  La procedura è controllata da
+alle librerie condivise quando vengono avviati.  La procedura è controllata da
 alcune variabili di ambiente e dal contenuto di \conffile{/etc/ld.so.conf}. I
 dettagli sono riportati nella pagina di manuale di \cmd{ld.so}.
 
 Il sistema fa partire qualunque programma chiamando la funzione \func{main};
-sta al programmatore chiamare così la funzione principale del programma da cui
+sta al programmatore chiamare così la funzione principale del programma da cui
 si suppone iniziare l'esecuzione; in ogni caso senza questa funzione lo stesso
-\textit{linker} (si chiama così il programma che effettua i collegamenti di
+\textit{linker} (si chiama così il programma che effettua i collegamenti di
 cui sopra) darebbe luogo ad errori.  Lo standard ISO C specifica che la
-funzione \func{main} può non avere argomenti o prendere due argomenti che
+funzione \func{main} può non avere argomenti o prendere due argomenti che
 rappresentano gli argomenti passati da linea di comando, in sostanza un
-prototipo che va sempre bene è il seguente:
+prototipo che va sempre bene è il seguente:
 \includecodesnip{listati/main_def.c}
 
-In realtà nei sistemi Unix esiste un altro modo per definire la funzione
+In realtà nei sistemi Unix esiste un altro modo per definire la funzione
 \func{main}, che prevede la presenza di un terzo argomento, \code{char
   *envp[]}, che fornisce (vedi sez.~\ref{sec:proc_environ})
-l'\textsl{ambiente} del programma; questa forma però non è prevista dallo
-standard POSIX.1 per cui se si vogliono scrivere programmi portabili è meglio
+l'\textsl{ambiente} del programma; questa forma però non è prevista dallo
+standard POSIX.1 per cui se si vogliono scrivere programmi portabili è meglio
 evitarla.
 
 
@@ -74,13 +74,13 @@ evitarla.
 \label{sec:proc_conclusion}
 
 Normalmente un programma finisce quando la funzione \func{main} ritorna, una
-modalità equivalente di chiudere il programma è quella di chiamare
+modalità equivalente di chiudere il programma è quella di chiamare
 direttamente la funzione \func{exit} (che viene comunque chiamata
-automaticamente quando \func{main} ritorna).  Una forma alternativa è quella
+automaticamente quando \func{main} ritorna).  Una forma alternativa è quella
 di chiamare direttamente la system call \func{\_exit}, che restituisce il
 controllo direttamente alla funzione di conclusione dei processi del kernel.
 
-Oltre alla conclusione ``\textsl{normale}'' esiste anche la possibilità di una
+Oltre alla conclusione ``\textsl{normale}'' esiste anche la possibilità di una
 conclusione ``\textsl{anomala}'' del programma a causa della ricezione di un
 segnale (tratteremo i segnali in cap.~\ref{cha:signals}) o della chiamata alla
 funzione \func{abort}; torneremo su questo in sez.~\ref{sec:proc_termination}.
@@ -89,29 +89,29 @@ Il valore di ritorno della funzione \func{main}, o quello usato nelle chiamate
 ad \func{exit} e \func{\_exit}, viene chiamato \textsl{stato di uscita} (o
 \textit{exit status}) e passato al processo che aveva lanciato il programma
 (in genere la shell). In generale si usa questo valore per fornire
-informazioni sulla riuscita o il fallimento del programma; l'informazione è
+informazioni sulla riuscita o il fallimento del programma; l'informazione è
 necessariamente generica, ed il valore deve essere compreso fra 0 e 255.
 
-La convenzione in uso pressoché universale è quella di restituire 0 in caso di
-successo e 1 in caso di fallimento; l'unica eccezione è per i programmi che
+La convenzione in uso pressoché universale è quella di restituire 0 in caso di
+successo e 1 in caso di fallimento; l'unica eccezione è per i programmi che
 effettuano dei confronti (come \cmd{diff}), che usano 0 per indicare la
 corrispondenza, 1 per indicare la non corrispondenza e 2 per indicare
-l'incapacità di effettuare il confronto. È opportuno adottare una di queste
+l'incapacità di effettuare il confronto. È opportuno adottare una di queste
 convenzioni a seconda dei casi.  Si tenga presente che se si raggiunge la fine
 della funzione \func{main} senza ritornare esplicitamente si ha un valore di
-uscita indefinito, è pertanto consigliabile di concludere sempre in maniera
+uscita indefinito, è pertanto consigliabile di concludere sempre in maniera
 esplicita detta funzione.
 
 Un'altra convenzione riserva i valori da 128 a 256 per usi speciali: ad
-esempio 128 viene usato per indicare l'incapacità di eseguire un altro
-programma in un sottoprocesso. Benché questa convenzione non sia
-universalmente seguita è una buona idea tenerne conto.
+esempio 128 viene usato per indicare l'incapacità di eseguire un altro
+programma in un sottoprocesso. Benché questa convenzione non sia
+universalmente seguita è una buona idea tenerne conto.
 
-Si tenga presente inoltre che non è una buona idea usare il codice di errore
+Si tenga presente inoltre che non è una buona idea usare il codice di errore
 restituito dalla variabile \var{errno} (per i dettagli si veda
 sez.~\ref{sec:sys_errors}) come stato di uscita. In generale infatti una shell
-non si cura del valore se non per vedere se è diverso da zero; inoltre il
-valore dello stato di uscita è sempre troncato ad 8 bit, per cui si potrebbe
+non si cura del valore se non per vedere se è diverso da zero; inoltre il
+valore dello stato di uscita è sempre troncato ad 8 bit, per cui si potrebbe
 incorrere nel caso in cui restituendo un codice di errore 256, si otterrebbe
 uno stato di uscita uguale a zero, che verrebbe interpretato come un successo.
 
@@ -125,15 +125,15 @@ valori di tipo \ctyp{int} 0 e 1.
 \label{sec:proc_exit}
 
 Come accennato le funzioni usate per effettuare un'uscita ``\textit{normale}''
-da un programma sono due, la prima è la funzione \funcd{exit}, che è definita
-dallo standard ANSI C ed il cui prototipo è:
+da un programma sono due, la prima è la funzione \funcd{exit}, che è definita
+dallo standard ANSI C ed il cui prototipo è:
 \begin{prototype}{stdlib.h}{void exit(int status)}
   Causa la conclusione ordinaria del programma.
 
   \bodydesc{La funzione non ritorna. Il processo viene terminato.}
 \end{prototype}
 
-La funzione \func{exit} è pensata per eseguire una conclusione pulita di un
+La funzione \func{exit} è pensata per eseguire una conclusione pulita di un
 programma che usi le librerie standard del C; essa esegue tutte le funzioni
 che sono state registrate con \func{atexit} e \func{on\_exit} (vedi
 sez.~\ref{sec:proc_atexit}), e chiude tutti gli stream effettuando il
@@ -144,7 +144,7 @@ sez.~\ref{sec:file_fopen}), infine passa il controllo al kernel chiamando
 La system call \funcd{\_exit} restituisce direttamente il controllo al kernel,
 concludendo immediatamente il processo; i dati sospesi nei buffer degli stream
 non vengono salvati e le eventuali funzioni registrate con \func{atexit} e
-\func{on\_exit} non vengono eseguite. Il prototipo della funzione è:
+\func{on\_exit} non vengono eseguite. Il prototipo della funzione è:
 \begin{prototype}{unistd.h}{void \_exit(int status)}
   Causa la conclusione immediata del programma.
 
@@ -154,17 +154,17 @@ non vengono salvati e le eventuali funzioni registrate con \func{atexit} e
 La funzione chiude tutti i file descriptor appartenenti al processo; si tenga
 presente che questo non comporta il salvataggio dei dati bufferizzati degli
 stream, (torneremo sulle due interfacce dei file a partire da
-cap.~\ref{cha:file_intro}), fa sì che ogni figlio del processo sia adottato da
+cap.~\ref{cha:file_intro}), fa sì che ogni figlio del processo sia adottato da
 \cmd{init} (vedi cap.~\ref{cha:process_handling}), manda un segnale
 \const{SIGCHLD} al processo padre (vedi sez.~\ref{sec:sig_job_control}) ed
-infine ritorna lo stato di uscita specificato in \param{status} che può essere
+infine ritorna lo stato di uscita specificato in \param{status} che può essere
 raccolto usando la funzione \func{wait} (vedi sez.~\ref{sec:proc_wait}).
 
 
 \subsection{Le funzioni \func{atexit} e \func{on\_exit}}
 \label{sec:proc_atexit}
 
-Un'esigenza comune che si incontra nella programmazione è quella di dover
+Un'esigenza comune che si incontra nella programmazione è quella di dover
 effettuare una serie di operazioni di pulizia (ad esempio salvare dei dati,
 ripristinare delle impostazioni, eliminare dei file temporanei, ecc.) prima
 della conclusione di un programma. In genere queste operazioni vengono fatte
@@ -172,13 +172,13 @@ in un'apposita sezione del programma, ma quando si realizza una libreria
 diventa antipatico dover richiedere una chiamata esplicita ad una funzione di
 pulizia al programmatore che la utilizza.
 
-È invece molto meno soggetto ad errori, e completamente trasparente
-all'utente, avere la possibilità di effettuare automaticamente la chiamata ad
+È invece molto meno soggetto ad errori, e completamente trasparente
+all'utente, avere la possibilità di effettuare automaticamente la chiamata ad
 una funzione che effettui tali operazioni all'uscita dal programma. A questo
-scopo lo standard ANSI C prevede la possibilità di registrare un certo numero
+scopo lo standard ANSI C prevede la possibilità di registrare un certo numero
 di funzioni che verranno eseguite all'uscita dal programma (sia per la
 chiamata ad \func{exit} che per il ritorno di \func{main}). La prima funzione
-che si può utilizzare a tal fine è \funcd{atexit} il cui prototipo è:
+che si può utilizzare a tal fine è \funcd{atexit} il cui prototipo è:
 \begin{prototype}{stdlib.h}{void atexit(void (*function)(void))}
   Registra la funzione \param{function} per la chiamata all'uscita dal
   programma.
@@ -188,12 +188,12 @@ che si pu
 \end{prototype}
 \noindent la funzione richiede come argomento l'indirizzo di una opportuna
 funzione di pulizia da chiamare all'uscita del programma, che non deve
-prendere argomenti e non deve ritornare niente (deve essere cioè definita come
+prendere argomenti e non deve ritornare niente (deve essere cioè definita come
 \code{void function(void)}).
 
-Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che le
-\acr{glibc} includono per compatibilità con SunOS, ma che non è detto sia
-definita su altri sistemi; il suo prototipo è:
+Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che le
+\acr{glibc} includono per compatibilità con SunOS, ma che non è detto sia
+definita su altri sistemi; il suo prototipo è:
 \begin{prototype}{stdlib.h}
 {void on\_exit(void (*function)(int , void *), void *arg)}
   Registra la funzione \param{function} per la chiamata all'uscita dal
@@ -204,34 +204,34 @@ definita su altri sistemi; il suo prototipo 
 \end{prototype}
 
 In questo caso la funzione da chiamare all'uscita prende i due argomenti
-specificati nel prototipo, dovrà cioè essere definita come \code{void
-  function(int status, void *argp)}. Il primo argomento sarà inizializzato
-allo stato di uscita con cui è stata chiamata \func{exit} ed il secondo al
-puntatore \param{arg} passato come secondo argomento di \func{on\_exit}.  Così
+specificati nel prototipo, dovrà cioè essere definita come \code{void
+  function(int status, void *argp)}. Il primo argomento sarà inizializzato
+allo stato di uscita con cui è stata chiamata \func{exit} ed il secondo al
+puntatore \param{arg} passato come secondo argomento di \func{on\_exit}.  Così
 diventa possibile passare dei dati alla funzione di chiusura.
 
 Nella sequenza di chiusura tutte le funzioni registrate verranno chiamate in
 ordine inverso rispetto a quello di registrazione (ed una stessa funzione
-registrata più volte sarà chiamata più volte); poi verranno chiusi tutti gli
-stream aperti, infine verrà chiamata \func{\_exit}.
+registrata più volte sarà chiamata più volte); poi verranno chiusi tutti gli
+stream aperti, infine verrà chiamata \func{\_exit}.
 
 
 \subsection{Conclusioni}
 \label{sec:proc_term_conclusion}
 
-Data l'importanza dell'argomento è opportuno sottolineare ancora una volta che
-in un sistema Unix l'unico modo in cui un programma può essere eseguito dal
-kernel è attraverso la chiamata alla system call \func{execve} (o attraverso
+Data l'importanza dell'argomento è opportuno sottolineare ancora una volta che
+in un sistema Unix l'unico modo in cui un programma può essere eseguito dal
+kernel è attraverso la chiamata alla system call \func{execve} (o attraverso
 una delle funzioni della famiglia \func{exec} che vedremo in
 sez.~\ref{sec:proc_exec}).
 
-Allo stesso modo l'unico modo in cui un programma può concludere
-volontariamente la sua esecuzione è attraverso una chiamata alla system call
+Allo stesso modo l'unico modo in cui un programma può concludere
+volontariamente la sua esecuzione è attraverso una chiamata alla system call
 \func{\_exit}, o esplicitamente, o in maniera indiretta attraverso l'uso di
 \func{exit} o il ritorno di \func{main}.
 
-Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
-normalmente un programma è riportato in fig.~\ref{fig:proc_prog_start_stop}.
+Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
+normalmente un programma è riportato in fig.~\ref{fig:proc_prog_start_stop}.
 
 \begin{figure}[htb]
   \centering
@@ -277,8 +277,8 @@ normalmente un programma 
   \label{fig:proc_prog_start_stop}
 \end{figure}
 
-Si ricordi infine che un programma può anche essere interrotto dall'esterno
-attraverso l'uso di un segnale (modalità di conclusione non mostrata in
+Si ricordi infine che un programma può anche essere interrotto dall'esterno
+attraverso l'uso di un segnale (modalità di conclusione non mostrata in
 fig.~\ref{fig:proc_prog_start_stop}); tratteremo nei dettagli i segnali e la
 loro gestione nel capitolo \ref{cha:signals}.
 
@@ -287,8 +287,8 @@ loro gestione nel capitolo \ref{cha:signals}.
 \section{I processi e l'uso della memoria}
 \label{sec:proc_memory}
 
-Una delle risorse base che ciascun processo ha a disposizione è la memoria, e
-la gestione della memoria è appunto uno degli aspetti più complessi di un
+Una delle risorse base che ciascun processo ha a disposizione è la memoria, e
+la gestione della memoria è appunto uno degli aspetti più complessi di un
 sistema unix-like. In questa sezione, dopo una breve introduzione ai concetti
 base, esamineremo come la memoria viene vista da parte di un programma in
 esecuzione, e le varie funzioni utilizzabili per la sua gestione.
@@ -299,70 +299,70 @@ esecuzione, e le varie funzioni utilizzabili per la sua gestione.
 
 Ci sono vari modi in cui i sistemi operativi organizzano la memoria, ed i
 dettagli di basso livello dipendono spesso in maniera diretta
-dall'architettura dell'hardware, ma quello più tipico, usato dai sistemi
-unix-like come Linux è la cosiddetta \index{memoria~virtuale} \textsl{memoria
+dall'architettura dell'hardware, ma quello più tipico, usato dai sistemi
+unix-like come Linux è la cosiddetta \index{memoria~virtuale} \textsl{memoria
   virtuale} che consiste nell'assegnare ad ogni processo uno spazio virtuale
 di indirizzamento lineare, in cui gli indirizzi vanno da zero ad un qualche
 valore massimo.\footnote{nel caso di Linux fino al kernel 2.2 detto massimo
   era, per macchine a 32bit, di 2Gb. Con il kernel 2.4 ed il supporto per la
-  \textit{high-memory} il limite è stato esteso anche per macchine a 32 bit.}
+  \textit{high-memory} il limite è stato esteso anche per macchine a 32 bit.}
 
-Come accennato in cap.~\ref{cha:intro_unix} questo spazio di indirizzi è
+Come accennato in cap.~\ref{cha:intro_unix} questo spazio di indirizzi è
 virtuale e non corrisponde all'effettiva posizione dei dati nella RAM del
-computer; in genere detto spazio non è neppure continuo (cioè non tutti gli
+computer; in genere detto spazio non è neppure continuo (cioè non tutti gli
 indirizzi possibili sono utilizzabili, e quelli usabili non sono
 necessariamente adiacenti).
 
 Per la gestione da parte del kernel la memoria viene divisa in pagine di
 dimensione fissa,\footnote{inizialmente questi erano di 4kb sulle macchine a
-  32 bit e di 8kb sulle alpha, con le versioni più recenti del kernel è
+  32 bit e di 8kb sulle alpha, con le versioni più recenti del kernel è
   possibile anche utilizzare pagine di dimensioni maggiori (4Mb), per sistemi
   con grandi quantitativi di memoria in cui l'uso di pagine troppo piccole
   comporta una perdita di prestazioni.} e ciascuna pagina nello spazio di
-indirizzi virtuale è associata ad un supporto che può essere una pagina di
+indirizzi virtuale è associata ad un supporto che può essere una pagina di
 memoria reale o ad un dispositivo di stoccaggio secondario (come lo spazio
 disco riservato alla swap, o i file che contengono il codice). Per ciascun
 processo il kernel si cura di mantenere un mappa di queste corrispondenze
-nella cosiddetta \itindex{page~table} \textit{page table}.\footnote{questa è
-  una semplificazione brutale, il meccanismo è molto più complesso; una buona
+nella cosiddetta \itindex{page~table} \textit{page table}.\footnote{questa è
+  una semplificazione brutale, il meccanismo è molto più complesso; una buona
   trattazione di come Linux gestisce la memoria virtuale si trova su
   \cite{LinVM}.}
 
-Una stessa pagina di memoria reale può fare da supporto a diverse pagine di
+Una stessa pagina di memoria reale può fare da supporto a diverse pagine di
 memoria virtuale appartenenti a processi diversi (come accade in genere per le
 pagine che contengono il codice delle librerie condivise). Ad esempio il
-codice della funzione \func{printf} starà su una sola pagina di memoria reale
-che farà da supporto a tutte le pagine di memoria virtuale di tutti i processi
+codice della funzione \func{printf} starà su una sola pagina di memoria reale
+che farà da supporto a tutte le pagine di memoria virtuale di tutti i processi
 che hanno detta funzione nel loro codice.
 
 La corrispondenza fra le pagine della \index{memoria~virtuale} memoria
 virtuale di un processo e quelle della memoria fisica della macchina viene
 gestita in maniera trasparente dal kernel.\footnote{in genere con l'ausilio
   dell'hardware di gestione della memoria (la \textit{Memory Management Unit}
-  del processore), con i kernel della serie 2.6 è comunque diventato possibile
+  del processore), con i kernel della serie 2.6 è comunque diventato possibile
   utilizzare Linux anche su architetture che non dispongono di una MMU.}
-Poiché in genere la memoria fisica è solo una piccola frazione della memoria
-virtuale, è necessario un meccanismo che permetta di trasferire le pagine che
+Poiché in genere la memoria fisica è solo una piccola frazione della memoria
+virtuale, è necessario un meccanismo che permetta di trasferire le pagine che
 servono dal supporto su cui si trovano in memoria, eliminando quelle che non
-servono.  Questo meccanismo è detto \index{paginazione} \textsl{paginazione}
-(o \textit{paging}), ed è uno dei compiti principali del kernel.
+servono.  Questo meccanismo è detto \index{paginazione} \textsl{paginazione}
+(o \textit{paging}), ed è uno dei compiti principali del kernel.
 
-Quando un processo cerca di accedere ad una pagina che non è nella memoria
+Quando un processo cerca di accedere ad una pagina che non è nella memoria
 reale, avviene quello che viene chiamato un \itindex{page~fault} \textit{page
   fault}; la gestione della memoria genera un'interruzione e passa il
 controllo al kernel il quale sospende il processo e si incarica di mettere in
 RAM la pagina richiesta (effettuando tutte le operazioni necessarie per
 reperire lo spazio necessario), per poi restituire il controllo al processo.
 
-Dal punto di vista di un processo questo meccanismo è completamente
+Dal punto di vista di un processo questo meccanismo è completamente
 trasparente, e tutto avviene come se tutte le pagine fossero sempre
-disponibili in memoria.  L'unica differenza avvertibile è quella dei tempi di
+disponibili in memoria.  L'unica differenza avvertibile è quella dei tempi di
 esecuzione, che passano dai pochi nanosecondi necessari per l'accesso in RAM,
-a tempi molto più lunghi, dovuti all'intervento del kernel. 
+a tempi molto più lunghi, dovuti all'intervento del kernel. 
 
-Normalmente questo è il prezzo da pagare per avere un multitasking reale, ed
-in genere il sistema è molto efficiente in questo lavoro; quando però ci siano
-esigenze specifiche di prestazioni è possibile usare delle funzioni che
+Normalmente questo è il prezzo da pagare per avere un multitasking reale, ed
+in genere il sistema è molto efficiente in questo lavoro; quando però ci siano
+esigenze specifiche di prestazioni è possibile usare delle funzioni che
 permettono di bloccare il meccanismo della \index{paginazione} paginazione e
 mantenere fisse delle pagine in memoria (vedi sez.~\ref{sec:proc_mem_lock}).
 Inoltre per certe applicazioni gli algoritmi di gestione della memoria
@@ -371,20 +371,20 @@ Inoltre per certe applicazioni gli algoritmi di gestione della memoria
 \subsection{La struttura della memoria di un processo}
 \label{sec:proc_mem_layout}
 
-Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
-una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
-tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
-commette quando si è manipolato male un puntatore e genera quella che viene
+Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
+una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
+tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
+commette quando si è manipolato male un puntatore e genera quella che viene
 chiamata una \itindex{segment~violation} \textit{segment violation}. Se si
-tenta cioè di leggere o scrivere da un indirizzo per il quale non esiste
+tenta cioè di leggere o scrivere da un indirizzo per il quale non esiste
 un'associazione della pagina virtuale, il kernel risponde al relativo
 \itindex{page~fault} \textit{page fault} mandando un segnale \const{SIGSEGV}
 al processo, che normalmente ne causa la terminazione immediata.
 
-È pertanto importante capire come viene strutturata \index{memoria~virtuale}
+È pertanto importante capire come viene strutturata \index{memoria~virtuale}
 \textsl{la memoria virtuale} di un processo. Essa viene divisa in
-\textsl{segmenti}, cioè un insieme contiguo di indirizzi virtuali ai quali il
-processo può accedere.  Solitamente un programma C viene suddiviso nei
+\textsl{segmenti}, cioè un insieme contiguo di indirizzi virtuali ai quali il
+processo può accedere.  Solitamente un programma C viene suddiviso nei
 seguenti segmenti:
 
 \begin{enumerate}
@@ -400,54 +400,54 @@ seguenti segmenti:
   per tutto il tempo dell'esecuzione.
   
 \item Il \index{segmento!dati} segmento dei dati o \textit{data segment}.
-  Contiene le variabili globali (cioè quelle definite al di fuori di tutte le
-  funzioni che compongono il programma) e le variabili statiche (cioè quelle
-  dichiarate con l'attributo \ctyp{static}). Di norma è diviso in due parti.
+  Contiene le variabili globali (cioè quelle definite al di fuori di tutte le
+  funzioni che compongono il programma) e le variabili statiche (cioè quelle
+  dichiarate con l'attributo \ctyp{static}). Di norma è diviso in due parti.
   
-  La prima parte è il segmento dei dati inizializzati, che contiene le
-  variabili il cui valore è stato assegnato esplicitamente. Ad esempio
+  La prima parte è il segmento dei dati inizializzati, che contiene le
+  variabili il cui valore è stato assegnato esplicitamente. Ad esempio
   se si definisce:
 \includecodesnip{listati/pi.c}
-  questo valore sarà immagazzinato in questo segmento. La memoria di questo
+  questo valore sarà immagazzinato in questo segmento. La memoria di questo
   segmento viene preallocata all'avvio del programma e inizializzata ai valori
   specificati.
   
-  La seconda parte è il segmento dei dati non inizializzati, che contiene le
-  variabili il cui valore non è stato assegnato esplicitamente. Ad esempio se
+  La seconda parte è il segmento dei dati non inizializzati, che contiene le
+  variabili il cui valore non è stato assegnato esplicitamente. Ad esempio se
   si definisce:
 \includecodesnip{listati/vect.c}
-  questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
+  questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
   allocato all'avvio, e tutte le variabili vengono inizializzate a zero (ed i
   puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
-    variabili che vanno nel segmento dati, e non è affatto vero in generale.}
+    variabili che vanno nel segmento dati, e non è affatto vero in generale.}
    
   Storicamente questa seconda parte del segmento dati viene chiamata BSS (da
-  \textit{Block Started by Symbol}). La sua dimensione è fissa.
+  \textit{Block Started by Symbol}). La sua dimensione è fissa.
   
-\item Lo \itindex{heap} \textit{heap}. Tecnicamente lo si può considerare
-  l'estensione del segmento dati, a cui di solito è posto giusto di seguito. È
-  qui che avviene l'allocazione dinamica della memoria; può essere
+\item Lo \itindex{heap} \textit{heap}. Tecnicamente lo si può considerare
+  l'estensione del segmento dati, a cui di solito è posto giusto di seguito. È
+  qui che avviene l'allocazione dinamica della memoria; può essere
   ridimensionato allocando e disallocando la memoria dinamica con le apposite
   funzioni (vedi sez.~\ref{sec:proc_mem_alloc}), ma il suo limite inferiore
   (quello adiacente al segmento dati) ha una posizione fissa.
   
 \item Il segmento di \itindex{stack} \textit{stack}, che contiene quello che
   viene chiamato \textit{stack} del programma.  Tutte le volte che si effettua
-  una chiamata ad una funzione è qui che viene salvato l'indirizzo di ritorno
+  una chiamata ad una funzione è qui che viene salvato l'indirizzo di ritorno
   e le informazioni dello stato del chiamante (tipo il contenuto di alcuni
   registri della CPU), poi la funzione chiamata alloca qui lo spazio per le
   sue variabili locali. Tutti questi dati vengono \textit{impilati} (da questo
   viene il nome \itindex{stack} \textit{stack}) in sequenza uno sull'altro; in
   questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
-  della funzione lo spazio è automaticamente rilasciato e
+  della funzione lo spazio è automaticamente rilasciato e
   ``\textsl{ripulito}''.\footnote{il compilatore si incarica di generare
     automaticamente il codice necessario, seguendo quella che viene chiamata
     una \textit{calling convention}; quella standard usata con il C ed il C++
-    è detta \textit{cdecl} e prevede che gli argomenti siano caricati nello
+    è detta \textit{cdecl} e prevede che gli argomenti siano caricati nello
     \textit{stack} dal chiamante da destra a sinistra, e che si il chiamante
     stesso ad eseguire la ripulitura dello \textit{stack} al ritorno della
-    funzione, se ne possono però utilizzare di alternative (ad esempio nel
-    pascal gli argomenti sono inseriti da sinistra a destra ed è compito del
+    funzione, se ne possono però utilizzare di alternative (ad esempio nel
+    pascal gli argomenti sono inseriti da sinistra a destra ed è compito del
     chiamato ripulire lo \textit{stack}), in genere non ci si deve preoccupare
     di questo fintanto che non si mescolano funzioni scritte con linguaggi
     diversi.}
@@ -485,10 +485,10 @@ seguenti segmenti:
 \end{figure}
 
 Una disposizione tipica dei vari segmenti (testo, \itindex{heap}
-\textit{heap}, \itindex{stack} \textit{stack}, ecc.) è riportata in
+\textit{heap}, \itindex{stack} \textit{stack}, ecc.) è riportata in
 fig.~\ref{fig:proc_mem_layout}. Usando il comando \cmd{size} su un programma
-se ne può stampare le dimensioni dei segmenti di testo e di dati
-(inizializzati e BSS); si tenga presente però che il BSS non è mai salvato sul
+se ne può stampare le dimensioni dei segmenti di testo e di dati
+(inizializzati e BSS); si tenga presente però che il BSS non è mai salvato sul
 file che contiene l'eseguibile, dato che viene sempre inizializzato a zero al
 caricamento del programma.
 
@@ -497,37 +497,37 @@ caricamento del programma.
 \label{sec:proc_mem_alloc}
 
 Il C supporta direttamente, come linguaggio di programmazione, soltanto due
-modalità di allocazione della memoria: l'\textsl{allocazione statica} e
+modalità di allocazione della memoria: l'\textsl{allocazione statica} e
 l'\textsl{allocazione automatica}.
 
-L'\textsl{allocazione statica} è quella con cui sono memorizzate le variabili
-globali e le variabili statiche, cioè le variabili il cui valore deve essere
+L'\textsl{allocazione statica} è quella con cui sono memorizzate le variabili
+globali e le variabili statiche, cioè le variabili il cui valore deve essere
 mantenuto per tutta la durata del programma. Come accennato queste variabili
 vengono allocate nel \index{segmento!dati} segmento dei dati all'avvio del
 programma (come parte delle operazioni svolte da \func{exec}) e lo spazio da
 loro occupato non viene liberato fino alla sua conclusione.
 
-L'\textsl{allocazione automatica} è quella che avviene per gli argomenti di
+L'\textsl{allocazione automatica} è quella che avviene per gli argomenti di
 una funzione e per le sue variabili locali (le cosiddette \textsl{variabili
   automatiche}), che esistono solo per la durata della funzione.  Lo spazio
 per queste variabili viene allocato nello \itindex{stack} \textit{stack} quando
 viene eseguita la funzione e liberato quando si esce dalla medesima.
 
-Esiste però un terzo tipo di allocazione, l'\textsl{allocazione dinamica}
-della memoria, che non è prevista direttamente all'interno del linguaggio C,
-ma che è necessaria quando il quantitativo di memoria che serve è
+Esiste però un terzo tipo di allocazione, l'\textsl{allocazione dinamica}
+della memoria, che non è prevista direttamente all'interno del linguaggio C,
+ma che è necessaria quando il quantitativo di memoria che serve è
 determinabile solo durante il corso dell'esecuzione del programma.
 
-Il C non consente di usare variabili allocate dinamicamente, non è possibile
-cioè definire in fase di programmazione una variabile le cui dimensioni
+Il C non consente di usare variabili allocate dinamicamente, non è possibile
+cioè definire in fase di programmazione una variabile le cui dimensioni
 possano essere modificate durante l'esecuzione del programma. Per questo le
 librerie del C forniscono una serie opportuna di funzioni per eseguire
 l'allocazione dinamica di memoria (in genere nello \itindex{heap}
 \textit{heap}).
 
-Le variabili il cui contenuto è allocato in questo modo non potranno essere
+Le variabili il cui contenuto è allocato in questo modo non potranno essere
 usate direttamente come le altre (quelle nello \itindex{stack}
-\textit{stack}), ma l'accesso sarà possibile solo in maniera indiretta,
+\textit{stack}), ma l'accesso sarà possibile solo in maniera indiretta,
 attraverso i puntatori alla memoria loro riservata che si sono ottenuti dalle
 funzioni di allocazione.
 
@@ -544,161 +544,161 @@ loro prototipi sono i seguenti:
   
   La funzione restituisce il puntatore alla zona di memoria allocata in caso
   di successo e \val{NULL} in caso di fallimento, nel qual caso
-  \var{errno} assumerà il valore \errval{ENOMEM}.
+  \var{errno} assumerà il valore \errval{ENOMEM}.
 \funcdecl{void *malloc(size\_t size)}
   Alloca \param{size} byte nello \textit{heap}. La memoria non viene
   inizializzata. 
 
   La funzione restituisce il puntatore alla zona di memoria allocata in caso
   di successo e \val{NULL} in caso di fallimento, nel qual caso
-  \var{errno} assumerà il valore \errval{ENOMEM}.
+  \var{errno} assumerà il valore \errval{ENOMEM}.
 \funcdecl{void *realloc(void *ptr, size\_t size)}
   Cambia la dimensione del blocco allocato all'indirizzo \param{ptr}
   portandola a \param{size}.
 
   La funzione restituisce il puntatore alla zona di memoria allocata in caso
   di successo e \val{NULL} in caso di fallimento, nel qual caso
-  \var{errno} assumerà il valore \errval{ENOMEM}.
+  \var{errno} assumerà il valore \errval{ENOMEM}.
 \funcdecl{void free(void *ptr)}
   Disalloca lo spazio di memoria puntato da \param{ptr}.
 
   La funzione non ritorna nulla e non riporta errori.
 \end{functions}
-Il puntatore ritornato dalle funzioni di allocazione è garantito essere sempre
+Il puntatore ritornato dalle funzioni di allocazione è garantito essere sempre
 allineato correttamente per tutti i tipi di dati; ad esempio sulle macchine a
-32 bit in genere è allineato a multipli di 4 byte e sulle macchine a 64 bit a
+32 bit in genere è allineato a multipli di 4 byte e sulle macchine a 64 bit a
 multipli di 8 byte.
 
 In genere si usano le funzioni \func{malloc} e \func{calloc} per allocare
-dinamicamente la quantità di memoria necessaria al programma indicata da
+dinamicamente la quantità di memoria necessaria al programma indicata da
 \param{size},\footnote{queste funzioni presentano un comportamento diverso fra
-  le \acr{glibc} e le \acr{uClib} quando il valore di \param{size} è nullo.
-  Nel primo caso viene comunque restituito un puntatore valido, anche se non è
+  le \acr{glibc} e le \acr{uClib} quando il valore di \param{size} è nullo.
+  Nel primo caso viene comunque restituito un puntatore valido, anche se non è
   chiaro a cosa esso possa fare riferimento, nel secondo caso viene restituito
-  \val{NULL}. Il comportamento è analogo con \code{realloc(NULL, 0)}.} e
-siccome i puntatori ritornati sono di tipo generico non è necessario
+  \val{NULL}. Il comportamento è analogo con \code{realloc(NULL, 0)}.} e
+siccome i puntatori ritornati sono di tipo generico non è necessario
 effettuare un cast per assegnarli a puntatori al tipo di variabile per la
 quale si effettua l'allocazione.
 
 La memoria allocata dinamicamente deve essere esplicitamente rilasciata usando
 \func{free}\footnote{le glibc provvedono anche una funzione \func{cfree}
-  definita per compatibilità con SunOS, che è deprecata.} una volta che non
-sia più necessaria. Questa funzione vuole come argomento un puntatore
+  definita per compatibilità con SunOS, che è deprecata.} una volta che non
+sia più necessaria. Questa funzione vuole come argomento un puntatore
 restituito da una precedente chiamata a una qualunque delle funzioni di
-allocazione che non sia già stato liberato da un'altra chiamata a \func{free},
-in caso contrario il comportamento della funzione è indefinito.
+allocazione che non sia già stato liberato da un'altra chiamata a \func{free},
+in caso contrario il comportamento della funzione è indefinito.
 
 La funzione \func{realloc} si usa invece per cambiare (in genere aumentare) la
 dimensione di un'area di memoria precedentemente allocata, la funzione vuole
 in ingresso il puntatore restituito dalla precedente chiamata ad una
-\func{malloc} (se è passato un valore \val{NULL} allora la funzione si
-comporta come \func{malloc})\footnote{questo è vero per Linux e
-  l'implementazione secondo lo standard ANSI C, ma non è vero per alcune
+\func{malloc} (se è passato un valore \val{NULL} allora la funzione si
+comporta come \func{malloc})\footnote{questo è vero per Linux e
+  l'implementazione secondo lo standard ANSI C, ma non è vero per alcune
   vecchie implementazioni, inoltre alcune versioni delle librerie del C
   consentivano di usare \func{realloc} anche per un puntatore liberato con
-  \func{free} purché non ci fossero state nel frattempo altre chiamate a
-  funzioni di allocazione, questa funzionalità è totalmente deprecata e non è
+  \func{free} purché non ci fossero state nel frattempo altre chiamate a
+  funzioni di allocazione, questa funzionalità è totalmente deprecata e non è
   consentita sotto Linux.} ad esempio quando si deve far crescere la
-dimensione di un vettore. In questo caso se è disponibile dello spazio
+dimensione di un vettore. In questo caso se è disponibile dello spazio
 adiacente al precedente la funzione lo utilizza, altrimenti rialloca altrove
 un blocco della dimensione voluta, copiandoci automaticamente il contenuto; lo
 spazio aggiunto non viene inizializzato.
 
 Si deve sempre avere ben presente il fatto che il blocco di memoria restituito
-da \func{realloc} può non essere un'estensione di quello che gli si è passato
-in ingresso; per questo si dovrà \emph{sempre} eseguire la riassegnazione di
+da \func{realloc} può non essere un'estensione di quello che gli si è passato
+in ingresso; per questo si dovrà \emph{sempre} eseguire la riassegnazione di
 \param{ptr} al valore di ritorno della funzione, e reinizializzare o provvedere
 ad un adeguato aggiornamento di tutti gli altri puntatori all'interno del
 blocco di dati ridimensionato.
 
 Un errore abbastanza frequente (specie se si ha a che fare con vettori di
-puntatori) è quello di chiamare \func{free} più di una volta sullo stesso
-puntatore; per evitare questo problema una soluzione di ripiego è quella di
+puntatori) è quello di chiamare \func{free} più di una volta sullo stesso
+puntatore; per evitare questo problema una soluzione di ripiego è quella di
 assegnare sempre a \val{NULL} ogni puntatore liberato con \func{free}, dato
-che, quando l'argomento è un puntatore nullo, \func{free} non esegue nessuna
+che, quando l'argomento è un puntatore nullo, \func{free} non esegue nessuna
 operazione.
 
-Le \acr{glibc} hanno un'implementazione delle funzioni di allocazione che è
+Le \acr{glibc} hanno un'implementazione delle funzioni di allocazione che è
 controllabile dall'utente attraverso alcune variabili di ambiente (vedi
 sez.~\ref{sec:proc_environ}), in particolare diventa possibile tracciare
 questo tipo di errori usando la variabile di ambiente \val{MALLOC\_CHECK\_}
 che quando viene definita mette in uso una versione meno efficiente delle
-funzioni suddette, che però è più tollerante nei confronti di piccoli errori
+funzioni suddette, che però è più tollerante nei confronti di piccoli errori
 come quello di chiamate doppie a \func{free}.  In particolare:
 \begin{itemize}
-\item se la variabile è posta a zero gli errori vengono ignorati;
-\item se è posta ad 1 viene stampato un avviso sullo \textit{standard error}
+\item se la variabile è posta a zero gli errori vengono ignorati;
+\item se è posta ad 1 viene stampato un avviso sullo \textit{standard error}
   (vedi sez.~\ref{sec:file_std_stream});
-\item se è posta a 2 viene chiamata \func{abort}, che in genere causa
+\item se è posta a 2 viene chiamata \func{abort}, che in genere causa
   l'immediata conclusione del programma.
 \end{itemize}
 
-Il problema più comune e più difficile da risolvere che si incontra con le
-funzioni di allocazione è quando non viene opportunamente liberata la memoria
-non più utilizzata, quello che in inglese viene chiamato \itindex{memory~leak}
-\textit{memory leak}, cioè una \textsl{perdita di memoria}.
+Il problema più comune e più difficile da risolvere che si incontra con le
+funzioni di allocazione è quando non viene opportunamente liberata la memoria
+non più utilizzata, quello che in inglese viene chiamato \itindex{memory~leak}
+\textit{memory leak}, cioè una \textsl{perdita di memoria}.
 
-Un caso tipico che illustra il problema è quello in cui in una subroutine si
+Un caso tipico che illustra il problema è quello in cui in una subroutine si
 alloca della memoria per uso locale senza liberarla prima di uscire. La
-memoria resta così allocata fino alla terminazione del processo.  Chiamate
+memoria resta così allocata fino alla terminazione del processo.  Chiamate
 ripetute alla stessa subroutine continueranno ad effettuare altre allocazioni,
 causando a lungo andare un esaurimento della memoria disponibile (e la
-probabile impossibilità di proseguire l'esecuzione del programma).
+probabile impossibilità di proseguire l'esecuzione del programma).
 
-Il problema è che l'esaurimento della memoria può avvenire in qualunque
-momento, in corrispondenza ad una qualunque chiamata di \func{malloc} che può
+Il problema è che l'esaurimento della memoria può avvenire in qualunque
+momento, in corrispondenza ad una qualunque chiamata di \func{malloc} che può
 essere in una sezione del codice che non ha alcuna relazione con la subroutine
-che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
+che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
 \itindex{memory~leak} \textit{memory leak}.
 
-In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
+In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
 programmazione ad oggetti, il problema dei \itindex{memory~leak}
-\textit{memory leak} è notevolmente ridimensionato attraverso l'uso accurato
-di appositi oggetti come gli \textit{smartpointers}.  Questo però in genere va
+\textit{memory leak} è notevolmente ridimensionato attraverso l'uso accurato
+di appositi oggetti come gli \textit{smartpointers}.  Questo però in genere va
 a scapito delle prestazioni dell'applicazione in esecuzione.
 
 % TODO decidere cosa fare di questo che segue
 % In altri linguaggi come il java e recentemente il C\# il problema non si pone
-% nemmeno perché la gestione della memoria viene fatta totalmente in maniera
+% nemmeno perché la gestione della memoria viene fatta totalmente in maniera
 % automatica, ovvero il programmatore non deve minimamente preoccuparsi di
-% liberare la memoria allocata precedentemente quando non serve più, poiché
+% liberare la memoria allocata precedentemente quando non serve più, poiché
 % l'infrastruttura del linguaggio gestisce automaticamente la cosiddetta
 % \index{\textit{garbage~collection}} \textit{garbage collection}. In tal caso,
 % attraverso meccanismi simili a quelli del \textit{reference counting}, quando
-% una zona di memoria precedentemente allocata non è più riferita da nessuna
-% parte del codice in esecuzione, può essere deallocata automaticamente in
+% una zona di memoria precedentemente allocata non è più riferita da nessuna
+% parte del codice in esecuzione, può essere deallocata automaticamente in
 % qualunque momento dall'infrastruttura.
 
 % Anche questo va a scapito delle prestazioni dell'applicazione in esecuzione
 % (inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
-% eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
+% eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
 % la presenza di una infrastruttura per la loro interpretazione e pertanto hanno
-% di per sé delle prestazioni più scadenti rispetto alle stesse applicazioni
-% compilate direttamente).  Questo comporta però il problema della non
-% predicibilità del momento in cui viene deallocata la memoria precedentemente
+% di per sé delle prestazioni più scadenti rispetto alle stesse applicazioni
+% compilate direttamente).  Questo comporta però il problema della non
+% predicibilità del momento in cui viene deallocata la memoria precedentemente
 % allocata da un oggetto.
 
 Per limitare l'impatto di questi problemi, e semplificare la ricerca di
 eventuali errori, l'implementazione delle funzioni di allocazione delle
-\acr{glibc} mette a disposizione una serie di funzionalità che permettono di
+\acr{glibc} mette a disposizione una serie di funzionalità che permettono di
 tracciare le allocazioni e le disallocazioni, e definisce anche una serie di
 possibili \textit{hook} (\textsl{ganci}) che permettono di sostituire alle
-funzioni di libreria una propria versione (che può essere più o meno
+funzioni di libreria una propria versione (che può essere più o meno
 specializzata per il debugging). Esistono varie librerie che forniscono dei
 sostituti opportuni delle funzioni di allocazione in grado, senza neanche
 ricompilare il programma,\footnote{esempi sono \textit{Dmalloc}
   \href{http://dmalloc.com/}{\textsf{http://dmalloc.com/}} di Gray Watson ed
   \textit{Electric Fence} di Bruce Perens.} di eseguire diagnostiche anche
 molto complesse riguardo l'allocazione della memoria. Vedremo alcune delle
-funzionalità di ausilio presenti nelle \acr{glibc} in
+funzionalità di ausilio presenti nelle \acr{glibc} in
 sez.~\ref{sec:proc_memory_adv_management}. 
 
 Una possibile alternativa all'uso di \func{malloc}, per evitare di soffrire
 dei problemi di \itindex{memory~leak} \textit{memory leak} descritti in
-precedenza, è di allocare la memoria nel segmento di \itindex{stack}
+precedenza, è di allocare la memoria nel segmento di \itindex{stack}
 \textit{stack} della funzione corrente invece che nello \itindex{heap}
-\textit{heap}, per farlo si può usare la funzione \funcd{alloca}, la cui
-sintassi è identica a quella di \func{malloc}; il suo prototipo è:
+\textit{heap}, per farlo si può usare la funzione \funcd{alloca}, la cui
+sintassi è identica a quella di \func{malloc}; il suo prototipo è:
 \begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
   Alloca \param{size} byte nello \textit{stack}.
   
@@ -706,69 +706,69 @@ sintassi 
     allocata.}
 \end{prototype}
 
-La funzione alloca la quantità di memoria (non inizializzata) richiesta
+La funzione alloca la quantità di memoria (non inizializzata) richiesta
 dall'argomento \param{size} nel segmento di \itindex{stack} \textit{stack}
-della funzione chiamante.  Con questa funzione non è più necessario liberare
+della funzione chiamante.  Con questa funzione non è più necessario liberare
 la memoria allocata (e quindi non esiste un analogo della \func{free}) in
 quanto essa viene rilasciata automaticamente al ritorno della funzione.
 
-Come è evidente questa funzione ha molti vantaggi, anzitutto permette di
+Come è evidente questa funzione ha molti vantaggi, anzitutto permette di
 evitare alla radice i problemi di \itindex{memory~leak} \textit{memory leak},
-dato che non serve più la deallocazione esplicita; inoltre la deallocazione
+dato che non serve più la deallocazione esplicita; inoltre la deallocazione
 automatica funziona anche quando si usa \func{longjmp} per uscire da una
 subroutine con un salto non locale da una funzione (vedi
 sez.~\ref{sec:proc_longjmp}).
 
-Un altro vantaggio è che in Linux la funzione è molto più veloce di
-\func{malloc} e non viene sprecato spazio, infatti non è necessario gestire un
-pool di memoria da riservare e si evitano così anche i problemi di
+Un altro vantaggio è che in Linux la funzione è molto più veloce di
+\func{malloc} e non viene sprecato spazio, infatti non è necessario gestire un
+pool di memoria da riservare e si evitano così anche i problemi di
 frammentazione di quest'ultimo, che comportano inefficienze sia
 nell'allocazione della memoria che nell'esecuzione dell'allocazione.
 
-Gli svantaggi sono che questa funzione non è disponibile su tutti gli Unix, e
-non è inserita né nello standard POSIX né in SUSv3 (ma è presente in BSD), il
-suo utilizzo quindi limita la portabilità dei programmi. Inoltre la funzione
-non può essere usata nella lista degli argomenti di una funzione, perché lo
+Gli svantaggi sono che questa funzione non è disponibile su tutti gli Unix, e
+non è inserita né nello standard POSIX né in SUSv3 (ma è presente in BSD), il
+suo utilizzo quindi limita la portabilità dei programmi. Inoltre la funzione
+non può essere usata nella lista degli argomenti di una funzione, perché lo
 spazio verrebbe allocato nel mezzo degli stessi.
 
-Inoltre non è chiaramente possibile usare \func{alloca} per allocare memoria
+Inoltre non è chiaramente possibile usare \func{alloca} per allocare memoria
 che deve poi essere usata anche al di fuori della funzione in cui essa viene
 chiamata, dato che all'uscita dalla funzione lo spazio allocato diventerebbe
 libero, e potrebbe essere sovrascritto all'invocazione di nuove funzioni.
-Questo è lo stesso problema che si può avere con le variabili automatiche, su
+Questo è lo stesso problema che si può avere con le variabili automatiche, su
 cui torneremo in sez.~\ref{sec:proc_auto_var}.
 
 Infine non esiste un modo di sapere se l'allocazione ha avuto successo, la
 funzione infatti viene realizzata inserendo del codice \textit{inline} nel
-programma\footnote{questo comporta anche il fatto che non è possibile
+programma\footnote{questo comporta anche il fatto che non è possibile
   sostituirla con una propria versione o modificarne il comportamento
   collegando il proprio programma con un'altra libreria.} che si limita a
-modificare il puntatore nello \itindex{stack} \textit{stack} e non c'è modo di
+modificare il puntatore nello \itindex{stack} \textit{stack} e non c'è modo di
 sapere se se ne sono superate le dimensioni, per cui in caso di fallimento
-nell'allocazione il comportamento del programma può risultare indefinito,
+nell'allocazione il comportamento del programma può risultare indefinito,
 dando luogo ad una \itindex{segment~violation} \textit{segment violation} la
-prima volta che cercherà di accedere alla memoria non effettivamente
+prima volta che cercherà di accedere alla memoria non effettivamente
 disponibile. 
 
 Le due funzioni seguenti\footnote{le due funzioni sono state definite con BSD
   4.3, sono marcate obsolete in SUSv2 e non fanno parte delle librerie
   standard del C e mentre sono state esplicitamente rimosse dallo standard
-  POSIX/1-2001.} vengono utilizzate soltanto quando è necessario effettuare
+  POSIX/1-2001.} vengono utilizzate soltanto quando è necessario effettuare
 direttamente la gestione della memoria associata allo spazio dati di un
 processo, ad esempio qualora si debba implementare la propria versione delle
-funzioni di allocazione della memoria. Per poterle utilizzare è necessario
-definire una della macro di funzionalità (vedi
+funzioni di allocazione della memoria. Per poterle utilizzare è necessario
+definire una della macro di funzionalità (vedi
 sez.~\ref{sec:intro_gcc_glibc_std}) fra \macro{\_BSD\_SOURCE},
 \macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE} (ad un valore maggiore o
-ugiale di 500). La prima funzione è \funcd{brk}, ed il suo prototipo è:
+ugiale di 500). La prima funzione è \funcd{brk}, ed il suo prototipo è:
 \begin{prototype}{unistd.h}{int brk(void *end\_data\_segment)}
   Sposta la fine del segmento dei dati.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    fallimento, nel qual caso \var{errno} assumerà il valore \errval{ENOMEM}.}
+    fallimento, nel qual caso \var{errno} assumerà il valore \errval{ENOMEM}.}
 \end{prototype}
 
-La funzione è un'interfaccia all'omonima system call ed imposta l'indirizzo
+La funzione è un'interfaccia all'omonima system call ed imposta l'indirizzo
 finale del \index{segmento!dati} segmento dati di un processo all'indirizzo
 specificato da \param{end\_data\_segment}. Quest'ultimo deve essere un valore
 ragionevole, ed inoltre la dimensione totale del segmento non deve comunque
@@ -776,23 +776,23 @@ eccedere un eventuale limite (si veda sez.~\ref{sec:sys_resource_limit})
 imposto sulle dimensioni massime dello spazio dati del processo.
 
 Il valore di ritorno della funzione fa riferimento alla versione fornita dalle
-\acr{glibc}, in realtà in Linux la \textit{system call} corrispondente
+\acr{glibc}, in realtà in Linux la \textit{system call} corrispondente
 restituisce come valore di ritorno il nuovo valore della fine del
 \index{segmento!dati} segmento dati in caso di successo e quello corrente in
-caso di fallimento, è la funzione di interfaccia usata dalle \acr{glibc} che
-fornisce i valori di ritorno appena descritti, questo può non accadere se si
+caso di fallimento, è la funzione di interfaccia usata dalle \acr{glibc} che
+fornisce i valori di ritorno appena descritti, questo può non accadere se si
 usano librerie diverse.
 
 Una seconda funzione per la manipolazione diretta delle dimensioni
 \index{segmento!dati} del segmento dati\footnote{in questo caso si tratta
-  soltanto di una funzione di libreria, e non di una system call.} è
-\funcd{sbrk}, ed il suo prototipo è:
+  soltanto di una funzione di libreria, e non di una system call.} è
+\funcd{sbrk}, ed il suo prototipo è:
 \begin{prototype}{unistd.h}{void *sbrk(ptrdiff\_t increment)} 
   Incrementa la dimensione dello spazio dati.
   
   \bodydesc{La funzione restituisce il puntatore all'inizio della nuova zona
     di memoria allocata in caso di successo e \val{NULL} in caso di
-    fallimento, nel qual caso \var{errno} assumerà il valore \errval{ENOMEM}.}
+    fallimento, nel qual caso \var{errno} assumerà il valore \errval{ENOMEM}.}
 \end{prototype}
 \noindent la funzione incrementa la dimensione lo spazio dati di un programma
 di \param{increment} byte, restituendo il nuovo indirizzo finale dello stesso.
@@ -800,7 +800,7 @@ Un valore nullo permette di ottenere l'attuale posizione della fine del
 \index{segmento!dati} segmento dati.
 
 Queste funzioni sono state deliberatamente escluse dallo standard POSIX.1 e
-per i programmi normali è sempre opportuno usare le funzioni di allocazione
+per i programmi normali è sempre opportuno usare le funzioni di allocazione
 standard descritte in precedenza, che sono costruite su di esse. 
 
 
@@ -814,43 +814,43 @@ virtuale in maniera trasparente ai processi, decidendo quando rimuovere pagine
 dalla memoria per metterle nello swap, sulla base dell'utilizzo corrente da
 parte dei vari processi.
 
-Nell'uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il
+Nell'uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il
 meccanismo della \index{paginazione} paginazione riporta in RAM, ed in maniera
-trasparente, tutte le pagine che gli occorrono; esistono però esigenze
+trasparente, tutte le pagine che gli occorrono; esistono però esigenze
 particolari in cui non si vuole che questo meccanismo si attivi. In generale i
-motivi per cui si possono avere di queste necessità sono due:
+motivi per cui si possono avere di queste necessità sono due:
 \begin{itemize}
-\item \textsl{La velocità}. Il processo della \index{paginazione} paginazione
-  è trasparente solo se il programma in esecuzione non è sensibile al tempo
+\item \textsl{La velocità}. Il processo della \index{paginazione} paginazione
+  è trasparente solo se il programma in esecuzione non è sensibile al tempo
   che occorre a riportare la pagina in memoria; per questo motivo processi
   critici che hanno esigenze di tempo reale o tolleranze critiche nelle
   risposte (ad esempio processi che trattano campionamenti sonori) possono non
-  essere in grado di sopportare le variazioni della velocità di accesso dovuta
+  essere in grado di sopportare le variazioni della velocità di accesso dovuta
   alla paginazione.
   
-  In certi casi poi un programmatore può conoscere meglio dell'algoritmo di
+  In certi casi poi un programmatore può conoscere meglio dell'algoritmo di
   allocazione delle pagine le esigenze specifiche del suo programma e decidere
-  quali pagine di memoria è opportuno che restino in memoria per un aumento
+  quali pagine di memoria è opportuno che restino in memoria per un aumento
   delle prestazioni. In genere queste sono esigenze particolari e richiedono
-  anche un aumento delle priorità in esecuzione del processo (vedi
+  anche un aumento delle priorità in esecuzione del processo (vedi
   sez.~\ref{sec:proc_real_time}).
   
 \item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro
   in memoria queste possono essere portate su disco dal meccanismo della
-  \index{paginazione} paginazione. Questo rende più lungo il periodo di tempo
-  in cui detti segreti sono presenti in chiaro e più complessa la loro
-  cancellazione (un processo può cancellare la memoria su cui scrive le sue
-  variabili, ma non può toccare lo spazio disco su cui una pagina di memoria
-  può essere stata salvata). Per questo motivo di solito i programmi di
+  \index{paginazione} paginazione. Questo rende più lungo il periodo di tempo
+  in cui detti segreti sono presenti in chiaro e più complessa la loro
+  cancellazione (un processo può cancellare la memoria su cui scrive le sue
+  variabili, ma non può toccare lo spazio disco su cui una pagina di memoria
+  può essere stata salvata). Per questo motivo di solito i programmi di
   crittografia richiedono il blocco di alcune pagine di memoria.
 \end{itemize}
 
-Per ottenere informazioni sulle modalità in cui un programma sta usando la
-memoria virtuale è disponibile una apposita funzione, \funcd{mincore}, che
-però non è standardizzata da POSIX e pertanto non è disponibile su tutte le
+Per ottenere informazioni sulle modalità in cui un programma sta usando la
+memoria virtuale è disponibile una apposita funzione, \funcd{mincore}, che
+però non è standardizzata da POSIX e pertanto non è disponibile su tutte le
 versioni di kernel unix-like;\footnote{nel caso di Linux devono essere
   comunque definite le macro \macro{\_BSD\_SOURCE} e \macro{\_SVID\_SOURCE}.}
-il suo prototipo è:
+il suo prototipo è:
 \begin{functions}
   \headdecl{unistd.h} 
   \headdecl{sys/mman.h} 
@@ -859,15 +859,15 @@ il suo prototipo 
   Ritorna lo stato delle pagine di memoria occupate da un processo.
   
   \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori seguenti:
+    errore, nel qual caso \var{errno} assumerà uno dei valori seguenti:
   \begin{errlist}
   \item[\errcode{ENOMEM}] o \param{addr} + \param{length} eccede la dimensione
     della memoria usata dal processo o l'intervallo di indirizzi specificato
-    non è mappato.
-  \item[\errcode{EINVAL}] \param{addr} non è un multiplo delle dimensioni di
+    non è mappato.
+  \item[\errcode{EINVAL}] \param{addr} non è un multiplo delle dimensioni di
     una pagina.
   \item[\errcode{EFAULT}] \param{vec} punta ad un indirizzo non valido.
-  \item[\errcode{EAGAIN}] il kernel è temporaneamente non in grado di fornire
+  \item[\errcode{EAGAIN}] il kernel è temporaneamente non in grado di fornire
     una risposta.
   \end{errlist}
 }
@@ -878,44 +878,44 @@ della memoria per il processo chiamante, specificando l'intervallo da
 esaminare con l'indirizzo iniziale (indicato con l'argomento \param{addr}) e
 la lunghezza (indicata con l'argomento \param{length}). L'indirizzo iniziale
 deve essere un multiplo delle dimensioni di una pagina, mentre la lunghezza
-può essere qualunque, fintanto che si resta nello spazio di indirizzi del
-processo,\footnote{in caso contrario si avrà un errore di \errcode{ENOMEM};
+può essere qualunque, fintanto che si resta nello spazio di indirizzi del
+processo,\footnote{in caso contrario si avrà un errore di \errcode{ENOMEM};
   fino al kernel 2.6.11 in questo caso veniva invece restituito
-  \errcode{EINVAL}, in considerazione che il caso più comune in cui si
-  verifica questo errore è quando si usa per sbaglio un valore negativo
+  \errcode{EINVAL}, in considerazione che il caso più comune in cui si
+  verifica questo errore è quando si usa per sbaglio un valore negativo
   di \param{length}, che nel caso verrebbe interpretato come un intero
-  positivo di grandi dimensioni.}  ma il risultato verrà comunque fornito per
+  positivo di grandi dimensioni.}  ma il risultato verrà comunque fornito per
 l'intervallo compreso fino al multiplo successivo.
 
 I risultati della funzione vengono forniti nel vettore puntato da \param{vec},
 che deve essere allocato preventivamente e deve essere di dimensione
 sufficiente a contenere tanti byte quante sono le pagine contenute
-nell'intervallo di indirizzi specificato.\footnote{la dimensione cioè deve
+nell'intervallo di indirizzi specificato.\footnote{la dimensione cioè deve
   essere almeno pari a \code{(length+PAGE\_SIZE-1)/PAGE\_SIZE}. } Al ritorno
-della funzione il bit meno significativo di ciascun byte del vettore sarà
-acceso se la pagina di memoria corrispondente è al momento residente in
-memoria, o cancellato altrimenti. Il comportamento sugli altri bit è
+della funzione il bit meno significativo di ciascun byte del vettore sarà
+acceso se la pagina di memoria corrispondente è al momento residente in
+memoria, o cancellato altrimenti. Il comportamento sugli altri bit è
 indefinito, essendo questi al momento riservati per usi futuri. Per questo
-motivo in genere è comunque opportuno inizializzare a zero il contenuto del
-vettore, così che le pagine attualmente residenti in memoria saranno indicata
+motivo in genere è comunque opportuno inizializzare a zero il contenuto del
+vettore, così che le pagine attualmente residenti in memoria saranno indicata
 da un valore non nullo del byte corrispondente.
 
-Dato che lo stato della memoria di un processo può cambiare continuamente, il
-risultato di \func{mincore} è assolutamente provvisorio e lo stato delle
-pagine potrebbe essere già cambiato al ritorno stesso della funzione, a meno
+Dato che lo stato della memoria di un processo può cambiare continuamente, il
+risultato di \func{mincore} è assolutamente provvisorio e lo stato delle
+pagine potrebbe essere già cambiato al ritorno stesso della funzione, a meno
 che, come vedremo ora, non si sia attivato il meccanismo che forza il
 mantenimento di una pagina sulla memoria.  
 
 \itindbeg{memory~locking} 
 
 Il meccanismo che previene la \index{paginazione} paginazione di parte della
-memoria virtuale di un processo è chiamato \textit{memory locking} (o
-\textsl{blocco della memoria}). Il blocco è sempre associato alle pagine della
+memoria virtuale di un processo è chiamato \textit{memory locking} (o
+\textsl{blocco della memoria}). Il blocco è sempre associato alle pagine della
 memoria virtuale del processo, e non al segmento reale di RAM su cui essa
-viene mantenuta.  La regola è che se un segmento di RAM fa da supporto ad
+viene mantenuta.  La regola è che se un segmento di RAM fa da supporto ad
 almeno una pagina bloccata allora esso viene escluso dal meccanismo della
 \index{paginazione} paginazione. I blocchi non si accumulano, se si blocca due
-volte la stessa pagina non è necessario sbloccarla due volte, una pagina o è
+volte la stessa pagina non è necessario sbloccarla due volte, una pagina o è
 bloccata oppure no.
 
 Il \textit{memory lock} persiste fintanto che il processo che detiene la
@@ -926,7 +926,7 @@ ereditati dai processi figli,\footnote{ma siccome Linux usa il
   \itindex{copy~on~write} \textit{copy on write} (vedi
   sez.~\ref{sec:proc_fork}) gli indirizzi virtuali del figlio sono mantenuti
   sullo stesso segmento di RAM del padre, quindi fintanto che un figlio non
-  scrive su un segmento, può usufruire del \textit{memory lock} del padre.} e
+  scrive su un segmento, può usufruire del \textit{memory lock} del padre.} e
 vengono automaticamente rimossi se si pone in esecuzione un altro programma
 con \func{exec} (vedi sez.~\ref{sec:proc_exec}).
 
@@ -935,27 +935,27 @@ la memoria fisica disponibile nel sistema, questo ha un evidente impatto su
 tutti gli altri processi, per cui fino al kernel 2.6.9 solo un processo con i
 privilegi opportuni (la \itindex{capabilities} \textit{capability}
 \const{CAP\_IPC\_LOCK}, vedi sez.~\ref{sec:proc_capabilities}) aveva la
-capacità di bloccare una pagina.
+capacità di bloccare una pagina.
 
-Il sistema pone dei limiti all'ammontare di memoria di un processo che può
-essere bloccata e al totale di memoria fisica che si può dedicare a questo, lo
+Il sistema pone dei limiti all'ammontare di memoria di un processo che può
+essere bloccata e al totale di memoria fisica che si può dedicare a questo, lo
 standard POSIX.1 richiede che sia definita in \file{unistd.h} la macro
-\macro{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
-\textit{memory locking}. Inoltre in alcuni sistemi è definita la costante
+\macro{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
+\textit{memory locking}. Inoltre in alcuni sistemi è definita la costante
 \const{PAGE\_SIZE} in \file{limits.h} per indicare la dimensione di una pagina
 in byte.\footnote{con Linux questo non avviene e si deve ricorrere alla
   funzione \func{getpagesize}, vedi sez.~\ref{sec:sys_memory_res}.} 
 
-A partire dal kernel 2.6.9 anche un processo normale può bloccare la propria
-memoria\footnote{la funzionalità è stata introdotta per non essere costretti a
+A partire dal kernel 2.6.9 anche un processo normale può bloccare la propria
+memoria\footnote{la funzionalità è stata introdotta per non essere costretti a
   dare privilegi eccessivi a programmi di crittografia, che necessitano di
-  questa funzionalità, ma che devono essere usati da utenti normali.} ma
-mentre un processo privilegiato non ha limiti sulla quantità di memoria che
-può bloccare, un processo normale è soggetto al limite della risorsa
+  questa funzionalità, ma che devono essere usati da utenti normali.} ma
+mentre un processo privilegiato non ha limiti sulla quantità di memoria che
+può bloccare, un processo normale è soggetto al limite della risorsa
 \const{RLIMIT\_MEMLOCK} (vedi sez.~\ref{sec:sys_resource_limit}). In generale
-poi ogni processo può sbloccare le pagine relative alla propria memoria, se
-però diversi processi bloccano la stessa pagina questa resterà bloccata
-fintanto che ci sarà almeno un processo che la blocca.
+poi ogni processo può sbloccare le pagine relative alla propria memoria, se
+però diversi processi bloccano la stessa pagina questa resterà bloccata
+fintanto che ci sarà almeno un processo che la blocca.
 
 Le funzioni per bloccare e sbloccare la \index{paginazione} paginazione di
 singole sezioni di memoria sono \funcd{mlock} e \funcd{munlock}; i loro
@@ -970,14 +970,14 @@ prototipi sono:
   Rimuove il blocco della paginazione su un intervallo di memoria.
   
   \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e $-1$ in
-    caso di errore, nel qual caso \var{errno} assumerà uno dei
+    caso di errore, nel qual caso \var{errno} assumerà uno dei
     valori seguenti:
   \begin{errlist}
   \item[\errcode{ENOMEM}] alcuni indirizzi dell'intervallo specificato non
-    corrispondono allo spazio di indirizzi del processo o si è ecceduto
+    corrispondono allo spazio di indirizzi del processo o si è ecceduto
     il numero massimo consentito di pagine bloccate.
-  \item[\errcode{EINVAL}] \param{len} non è un valore positivo.
-  \item[\errcode{EPERM}] con un kernel successivo al 2.6.9 il processo non è
+  \item[\errcode{EINVAL}] \param{len} non è un valore positivo.
+  \item[\errcode{EPERM}] con un kernel successivo al 2.6.9 il processo non è
     privilegiato e si un limite nullo per \const{RLIMIT\_MEMLOCK}.
   \end{errlist}
   e, per \func{mlock}, anche \errval{EPERM} quando il processo non ha i
@@ -989,7 +989,7 @@ Le due funzioni permettono rispettivamente di bloccare e sbloccare la
 argomenti, che ne indicano nell'ordine l'indirizzo iniziale e la lunghezza.
 Tutte le pagine che contengono una parte dell'intervallo bloccato sono
 mantenute in RAM per tutta la durata del blocco.\footnote{con altri kernel si
-  può ottenere un errore di \errcode{EINVAL} se \param{addr} non è un multiplo
+  può ottenere un errore di \errcode{EINVAL} se \param{addr} non è un multiplo
   della dimensione delle pagine di memoria.}
 
 Altre due funzioni, \funcd{mlockall} e \funcd{munlockall}, consentono di
@@ -1011,7 +1011,7 @@ di indirizzi di un processo.  I prototipi di queste funzioni sono:
 \end{functions}
 
 L'argomento \param{flags} di \func{mlockall} permette di controllarne il
-comportamento; esso può essere specificato come l'OR aritmetico delle due
+comportamento; esso può essere specificato come l'OR aritmetico delle due
 costanti: 
 \begin{basedescript}{\desclabelwidth{2.5cm}}
 \item[\const{MCL\_CURRENT}] blocca tutte le pagine correntemente mappate nello
@@ -1034,13 +1034,13 @@ In ogni caso un processo real-time che deve entrare in una
 sufficiente prima dell'ingresso, per scongiurare l'occorrenza di un eventuale
 \itindex{page~fault} \textit{page fault} causato dal meccanismo di
 \itindex{copy~on~write} \textit{copy on write}.  Infatti se nella
-\index{sezione~critica} sezione critica si va ad utilizzare memoria che non è
+\index{sezione~critica} sezione critica si va ad utilizzare memoria che non è
 ancora stata riportata in RAM si potrebbe avere un \itindex{page~fault}
 \textit{page fault} durante l'esecuzione della stessa, con conseguente
 rallentamento (probabilmente inaccettabile) dei tempi di esecuzione.
 
 In genere si ovvia a questa problematica chiamando una funzione che ha
-allocato una quantità sufficientemente ampia di variabili automatiche, in modo
+allocato una quantità sufficientemente ampia di variabili automatiche, in modo
 che esse vengano mappate in RAM dallo \itindex{stack} \textit{stack}, dopo di
 che, per essere sicuri che esse siano state effettivamente portate in memoria,
 ci si scrive sopra.
@@ -1054,10 +1054,10 @@ ci si scrive sopra.
 \label{sec:proc_memory_adv_management}
 
 La trattazione delle funzioni di allocazione di sez.~\ref{sec:proc_mem_alloc}
-si è limitata a coprire le esigenze generiche di un programma, in cui non si
-hanno dei requisiti specifici e si lascia il controllo delle modalità di
+si è limitata a coprire le esigenze generiche di un programma, in cui non si
+hanno dei requisiti specifici e si lascia il controllo delle modalità di
 allocazione alle funzioni di libreria.  Tuttavia esistono una serie di casi in
-cui può essere necessario avere un controllo più dettagliato delle modalità
+cui può essere necessario avere un controllo più dettagliato delle modalità
 con cui la memoria viene allocata; nel qual caso potranno venire in aiuto le
 funzioni trattate in questa sezione.
 
@@ -1066,9 +1066,9 @@ allocare un blocco di memoria ``\textsl{allineato}'' ad un multiplo una certa
 dimensione. Questo tipo di esigenza emerge usualmente quando si devono
 allocare dei buffer da utilizzare per eseguire dell'I/O diretto su dispositivi
 a blocchi. In questo caso infatti il trasferimento di dati viene eseguito per
-blocchi di dimensione fissa, ed è richiesto che l'indirizzo di partenza del
+blocchi di dimensione fissa, ed è richiesto che l'indirizzo di partenza del
 buffer sia un multiplo intero di questa dimensione, usualmente 512 byte. In
-tal caso l'uso di \func{malloc} non è sufficiente, ed occorre utilizzare una
+tal caso l'uso di \func{malloc} non è sufficiente, ed occorre utilizzare una
 funzione specifica.
 
 Tradizionalmente per rispondere a questa esigenza sono state crate due
@@ -1085,30 +1085,30 @@ rispettivi prototipi sono:
   
   \bodydesc{Entrambe le funzioni ritornano un puntatore al blocco di memoria
     allocato in caso di successo e \val{NULL} in caso di errore, nel qual
-    caso \var{errno} assumerà uno dei valori seguenti:
+    caso \var{errno} assumerà uno dei valori seguenti:
   \begin{errlist}
-  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione.
-  \item[\errcode{EINVAL}] \param{boundary} non è multiplo di due.
+  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione.
+  \item[\errcode{EINVAL}] \param{boundary} non è multiplo di due.
   \end{errlist}
 }
 \end{functions}
 
 Le funzioni restituiscono il puntatore al buffer di memoria allocata, che per
-\func{memalign} sarà un multiplo di \param{boundary} mentre per \func{valloc}
+\func{memalign} sarà un multiplo di \param{boundary} mentre per \func{valloc}
 un multiplo della dimensione di una pagina di memoria. Nel caso della versione
 fornita dalle \acr{glibc} la memoria allocata con queste funzioni deve essere
-liberata con \func{free}, cosa che non è detto accada con altre
+liberata con \func{free}, cosa che non è detto accada con altre
 implementazioni.
 
 Nessuna delle due funzioni ha una chiara standardizzazione (nessuna delle due
 compare in POSIX.1), ed inoltre ci sono indicazioni discordi sui file che ne
-contengono la definizione;\footnote{secondo SUSv2 \func{valloc} è definita in
+contengono la definizione;\footnote{secondo SUSv2 \func{valloc} è definita in
   \texttt{stdlib.h}, mentre sia le \acr{glibc} che le precedenti \acr{libc4} e
   \acr{lic5} la dichiarano in \texttt{malloc.h}, lo stesso vale per
-  \func{memalign} che in alcuni sistemi è dichiarata in \texttt{stdlib.h}.}
-per questo motivo il loro uso è sconsigliato, essendo state sostituite dalla
-nuova \funcd{posix\_memalign}, che è stata standardizzata in POSIX.1d; il suo
-prototipo è:
+  \func{memalign} che in alcuni sistemi è dichiarata in \texttt{stdlib.h}.}
+per questo motivo il loro uso è sconsigliato, essendo state sostituite dalla
+nuova \funcd{posix\_memalign}, che è stata standardizzata in POSIX.1d; il suo
+prototipo è:
 \begin{prototype}{stdlib.h}{posix\_memalign(void **memptr, size\_t alignment,
     size\_t size) } 
   Alloca un buffer di memoria allineato ad un multiplo di \param{alignment}.
@@ -1121,47 +1121,47 @@ prototipo 
 La funzione restituisce il puntatore al buffer allocato all'indirizzo indicato
 da \param{memptr}. La funzione fallisce nelle stesse condizioni delle due
 funzioni precedenti, ma a differenza di \func{memalign} restituisce un codice
-di errore \errcode{EINVAL} anche se \param{alignment} non è un multiplo della
+di errore \errcode{EINVAL} anche se \param{alignment} non è un multiplo della
 la dimensione di \code{sizeof(void *)}. Come per le precedenti la memoria
-allocata con \func{posix\_memalign} può essere disallocata con
-\func{free}.\footnote{che in questo caso è quanto richiesto dallo standard.}
+allocata con \func{posix\_memalign} può essere disallocata con
+\func{free}.\footnote{che in questo caso è quanto richiesto dallo standard.}
 
 Un secondo caso in cui risulta estremamente utile poter avere un maggior
-controllo delle modalità di allocazione della memoria è quello in cui cercano
+controllo delle modalità di allocazione della memoria è quello in cui cercano
 errori di programmazione. Esempi di questi errori sono chiamate doppie alla
 funzione \func{free} con lo stesso puntatore, o i cosiddetti
-\itindex{buffer~overrun} \textit{buffer overrun}, cioè le scritture su un buffer
+\itindex{buffer~overrun} \textit{buffer overrun}, cioè le scritture su un buffer
 oltre le dimensioni della sua allocazione,\footnote{entrambe queste operazioni
   causano in genere la corruzione dei dati di controllo delle funzioni di
   allocazione, che vengono anch'essi mantenuti nello \itindex{heap}
   \textit{heap} per tenere traccia delle zone di memoria allocata.} o i
 classici \itindex{memory~leak} \textit{memory leak}.
 
-Una prima funzionalità di ausilio nella ricerca di questi errori viene fornita
+Una prima funzionalità di ausilio nella ricerca di questi errori viene fornita
 dalla \acr{glibc} tramite l'uso della variabile di ambiente
 \var{MALLOC\_CHECK\_}. Quando questa viene definita al posto della versione
 ordinaria delle funzioni di allocazione (\func{malloc}, \func{calloc},
 \func{realloc}, e \func{free}) viene usata una versione meno efficiente ma in
-grado di rilevare (e tollerare) alcuni degli errori più semplici, come le
+grado di rilevare (e tollerare) alcuni degli errori più semplici, come le
 doppie chiamate a \func{free} o i \itindex{buffer~overrun} \textit{buffer
-  overrun} di un byte.\footnote{uno degli errori più comuni, causato ad
+  overrun} di un byte.\footnote{uno degli errori più comuni, causato ad
   esempio dalla scrittura di una stringa di dimensione pari a quella del
   buffer, in cui ci si dimentica dello zero di terminazione finale.}
 
 In questo caso a seconda del valore assegnato a \var{MALLOC\_CHECK\_} si
-avranno diversi comportamenti: con 0 l'errore sarà ignorato, con 1 verrà
+avranno diversi comportamenti: con 0 l'errore sarà ignorato, con 1 verrà
 stampato un messaggio sullo \textit{standard error} (vedi
-sez.~\ref{sec:file_std_stream}), con 2 verrà invocata la funzione \func{abort}
+sez.~\ref{sec:file_std_stream}), con 2 verrà invocata la funzione \func{abort}
 (vedi sez.~\ref{sec:sig_alarm_abort}) che termina il programma, con 3 viene
-sia stampato il messaggio d'errore che abortito il programma. In genere è
+sia stampato il messaggio d'errore che abortito il programma. In genere è
 opportuno definire la variabile ad un valore diverso da zero che consente di
 rilevare un errore nel momento in cui avviene.
 
-Una modalità alternativa per effettuare dei controlli di consistenza sullo
+Una modalità alternativa per effettuare dei controlli di consistenza sullo
 stato delle allocazioni di memoria eseguite con \func{malloc}, anche questa
-fornita come estensione specifica (e non standard) delle \acr{glibc}, è quella
+fornita come estensione specifica (e non standard) delle \acr{glibc}, è quella
 di utilizzare la funzione \funcd{mcheck}, che deve essere chiamata prima di
-eseguire qualunque allocazione con \func{malloc}; il suo prototipo è:
+eseguire qualunque allocazione con \func{malloc}; il suo prototipo è:
 \begin{prototype}{mcheck.h}{mcheck(void (*abortfn) (enum mcheck\_status
     status))} 
   Attiva i controlli di consistenza delle allocazioni eseguite da \func{malloc}.
@@ -1171,19 +1171,19 @@ eseguire qualunque allocazione con \func{malloc}; il suo prototipo 
 \end{prototype}
 
 La funzione consente di registrare una funzione di emergenza, da passare come
-argomento, che verrà eseguita tutte le volte che, in una successiva esecuzione
+argomento, che verrà eseguita tutte le volte che, in una successiva esecuzione
 di \func{malloc}, venissero trovate delle inconsistenze, come delle operazioni
 di scrittura oltre i limiti dei buffer allocati. Per questo motivo la funzione
 deve essere chiamata prima di qualunque allocazione di memoria, altrimenti
-fallirà con un valore di ritorno pari a $-1$.
+fallirà con un valore di ritorno pari a $-1$.
 
-Se come argomento di \func{mcheck} si passa \var{NULL} verrà utilizzata una
+Se come argomento di \func{mcheck} si passa \var{NULL} verrà utilizzata una
 funzione predefinita che stampa un messaggio di errore ed invoca la funzione
-\func{abort} (vedi sez.~\ref{sec:sig_alarm_abort}), altrimenti si dovrà create
-una funzione personalizzata che verrà eseguita ricevendo un unico argomento di
+\func{abort} (vedi sez.~\ref{sec:sig_alarm_abort}), altrimenti si dovrà create
+una funzione personalizzata che verrà eseguita ricevendo un unico argomento di
 tipo \type{mcheck\_status},\footnote{trattasi in sostanza di un codice di
-  errore che la funzione di emergenza potrà utilizzare per prendere le
-  opportune azioni.} un tipo enumerato che può assumere soltanto i valori di
+  errore che la funzione di emergenza potrà utilizzare per prendere le
+  opportune azioni.} un tipo enumerato che può assumere soltanto i valori di
 tab.~\ref{tab:mcheck_status_value}.
 
 \begin{table}[htb]
@@ -1195,9 +1195,9 @@ tab.~\ref{tab:mcheck_status_value}.
     \hline
     \hline
     \macro{MCHECK\_OK}      & riportato (a \func{mprobe}) se nessuna
-                              inconsistenza è presente.\\
-    \macro{MCHECK\_DISABLED}& riportato (a \func{mprobe}) se si è chiamata
-                              \func{mcheck} dopo aver già usato
+                              inconsistenza è presente.\\
+    \macro{MCHECK\_DISABLED}& riportato (a \func{mprobe}) se si è chiamata
+                              \func{mcheck} dopo aver già usato
                               \func{malloc}.\\
     \macro{MCHECK\_HEAD}    & i dati immediatamente precedenti il buffer sono
                               stati modificati, avviene in genere quando si
@@ -1207,7 +1207,7 @@ tab.~\ref{tab:mcheck_status_value}.
     \macro{MCHECK\_TAIL}    & i dati immediatamente seguenti il buffer sono
                               stati modificati, succede quando si va scrivere
                               oltre la dimensione correttta del buffer.\\
-    \macro{MCHECK\_FREE}    & il buffer è già stato disallocato.\\
+    \macro{MCHECK\_FREE}    & il buffer è già stato disallocato.\\
     \hline
   \end{tabular}
   \caption{Valori dello stato dell'allocazione di memoria ottenibili dalla
@@ -1215,10 +1215,10 @@ tab.~\ref{tab:mcheck_status_value}.
   \label{tab:mcheck_status_value}
 \end{table}
 
-Una volta che si sia chiamata \func{mcheck} con successo si può anche
+Una volta che si sia chiamata \func{mcheck} con successo si può anche
 controllare esplicitamente lo stato delle allocazioni (senza aspettare un
 errore nelle relative funzioni) utilizzando la funzione \funcd{mprobe}, il cui
-prototipo è:
+prototipo è:
 \begin{prototype}{mcheck.h}{enum mcheck\_status mprobe(ptr)} 
   Esegue un controllo di consistenza delle allocazioni.
   
@@ -1230,21 +1230,21 @@ La funzione richiede che si passi come argomento un puntatore ad un blocco di
 memoria precedentemente allocato con \func{malloc} o \func{realloc}, e
 restituisce lo stesso codice di errore che si avrebbe per la funzione di
 emergenza ad una successiva chiamata di una funzione di allocazione, e poi i
-primi due codici che indicano rispettivamente quando tutto è a posto o il
-controllo non è possibile per non aver chiamato \func{mcheck} in tempo. 
+primi due codici che indicano rispettivamente quando tutto è a posto o il
+controllo non è possibile per non aver chiamato \func{mcheck} in tempo. 
 
-% TODO: trattare le altre funzionalità avanzate di \func{malloc}, mallopt,
-% mtrace, muntrace, mallinfo e gli hook con le glibc 2.10 c'è pure malloc_info
+% TODO: trattare le altre funzionalità avanzate di \func{malloc}, mallopt,
+% mtrace, muntrace, mallinfo e gli hook con le glibc 2.10 c'è pure malloc_info
 % a sostituire mallinfo, vedi http://udrepper.livejournal.com/20948.html
 
 
-\section{Argomenti, ambiente ed altre proprietà di un processo}
+\section{Argomenti, ambiente ed altre proprietà di un processo}
 \label{sec:proc_options}
 
 
 In questa sezione esamineremo le funzioni che permettono di gestire gli
 argomenti e le opzioni, e quelle che consentono di manipolare ed utilizzare le
-variabili di ambiente. Accenneremo infine alle modalità con cui si può gestire
+variabili di ambiente. Accenneremo infine alle modalità con cui si può gestire
 la localizzazione di un programma modificandone il comportamento a seconda
 della lingua o del paese a cui si vuole faccia riferimento nelle sue
 operazioni. 
@@ -1252,20 +1252,20 @@ operazioni.
 \subsection{Il formato degli argomenti}
 \label{sec:proc_par_format}
 
-Tutti i programmi hanno la possibilità di ricevere argomenti e opzioni quando
-vengono lanciati. Il passaggio degli argomenti e delle opzioni è effettuato
+Tutti i programmi hanno la possibilità di ricevere argomenti e opzioni quando
+vengono lanciati. Il passaggio degli argomenti e delle opzioni è effettuato
 attraverso gli argomenti \param{argc} e \param{argv} della funzione
 \func{main}, che vengono passati al programma dalla shell (o dal processo che
-esegue la \func{exec}, secondo le modalità che vedremo in
+esegue la \func{exec}, secondo le modalità che vedremo in
 sez.~\ref{sec:proc_exec}) quando questo viene messo in esecuzione.
 
 In genere il passaggio di argomenti ed opzioni ad un programma viene
 effettuato dalla shell, che si incarica di leggere la linea di comando e di
 effettuarne la scansione (il cosiddetto \textit{parsing}) per individuare le
-parole che la compongono, ciascuna delle quali potrà essere considerata un
+parole che la compongono, ciascuna delle quali potrà essere considerata un
 argomento o un'opzione. Di norma per individuare le parole che andranno a
 costituire la lista degli argomenti viene usato come carattere di separazione
-lo spazio o il tabulatore, ma la cosa dipende ovviamente dalle modalità con
+lo spazio o il tabulatore, ma la cosa dipende ovviamente dalle modalità con
 cui si effettua la scansione.
 
 \begin{figure}[htb]
@@ -1308,7 +1308,7 @@ essere la costruzione del vettore di puntatori \param{argv} in cui si devono
 inserire in successione i puntatori alle stringhe costituenti i vari argomenti
 ed opzioni, e della variabile \param{argc} che deve essere inizializzata al
 numero di stringhe passate. Nel caso della shell questo comporta che il primo
-argomento sia sempre il nome del programma; un esempio di questo meccanismo è
+argomento sia sempre il nome del programma; un esempio di questo meccanismo è
 mostrato in fig.~\ref{fig:proc_argv_argc}.
 
 
@@ -1321,9 +1321,9 @@ tali: un elemento di \param{argv} che inizia con il carattere \texttt{'-'} e
 che non sia un singolo \texttt{'-'} o un \texttt{'-{}-'} viene considerato
 un'opzione.  In genere le opzioni sono costituite da una lettera singola
 (preceduta dal carattere \cmd{'-'}) e possono avere o no un parametro
-associato; un comando tipico può essere quello mostrato in
+associato; un comando tipico può essere quello mostrato in
 fig.~\ref{fig:proc_argv_argc}. In quel caso le opzioni sono \cmd{-r} e \cmd{-m}
-e la prima vuole un parametro mentre la seconda no (\cmd{questofile.txt} è un
+e la prima vuole un parametro mentre la seconda no (\cmd{questofile.txt} è un
 argomento del programma, non un parametro di \cmd{-m}).
 
 Per gestire le opzioni all'interno dei argomenti a linea di comando passati in
@@ -1335,7 +1335,7 @@ Esegue il parsing degli argomenti passati da linea di comando
 riconoscendo le possibili opzioni segnalate con \param{optstring}.
 
 \bodydesc{Ritorna il carattere che segue l'opzione, \cmd{':'} se manca un
-  parametro all'opzione, \cmd{'?'} se l'opzione è sconosciuta, e $-1$ se non
+  parametro all'opzione, \cmd{'?'} se l'opzione è sconosciuta, e $-1$ se non
   esistono altre opzioni.}
 \end{prototype}
 
@@ -1345,17 +1345,17 @@ opzioni valide; la funzione effettua la scansione della lista degli argomenti
 ricercando ogni stringa che comincia con \cmd{-} e ritorna ogni volta che
 trova un'opzione valida.
 
-La stringa \param{optstring} indica quali sono le opzioni riconosciute ed è
+La stringa \param{optstring} indica quali sono le opzioni riconosciute ed è
 costituita da tutti i caratteri usati per identificare le singole opzioni, se
 l'opzione ha un parametro al carattere deve essere fatto seguire un segno di
 due punti \texttt{':'}; nel caso di fig.~\ref{fig:proc_argv_argc} ad esempio la
 stringa di opzioni avrebbe dovuto contenere \texttt{"r:m"}.
 
-La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
+La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
 funzione all'interno di un ciclo, fintanto che essa non ritorna il valore $-1$
-che indica che non ci sono più opzioni. Nel caso si incontri un'opzione non
+che indica che non ci sono più opzioni. Nel caso si incontri un'opzione non
 dichiarata in \param{optstring} viene ritornato il carattere \texttt{'?'}
-mentre se un'opzione che lo richiede non è seguita da un parametro viene
+mentre se un'opzione che lo richiede non è seguita da un parametro viene
 ritornato il carattere \texttt{':'}, infine se viene incontrato il valore
 \texttt{'-{}-'} la scansione viene considerata conclusa, anche se vi sono altri
 elementi di \param{argv} che cominciano con il carattere \texttt{'-'}.
@@ -1377,39 +1377,39 @@ carattere, in questo modo si possono eseguire azioni specifiche usando uno
 \item \var{char *optarg} contiene il puntatore alla stringa parametro
   dell'opzione.
 \item \var{int optind} alla fine della scansione restituisce l'indice del
-  primo elemento di \param{argv} che non è un'opzione.
+  primo elemento di \param{argv} che non è un'opzione.
 \item \var{int opterr} previene, se posto a zero, la stampa di un messaggio
   di errore in caso di riconoscimento di opzioni non definite.
 \item \var{int optopt} contiene il carattere dell'opzione non riconosciuta.
 \end{itemize*}
 
-In fig.~\ref{fig:proc_options_code} è mostrata la sezione del programma
+In fig.~\ref{fig:proc_options_code} è mostrata la sezione del programma
 \file{ForkTest.c} (che useremo nel prossimo capitolo per effettuare dei test
 sulla creazione dei processi) deputata alla decodifica delle opzioni a riga di
 comando. 
 
-Si può notare che si è anzitutto (\texttt{\small 1}) disabilitata la stampa di
+Si può notare che si è anzitutto (\texttt{\small 1}) disabilitata la stampa di
 messaggi di errore per opzioni non riconosciute, per poi passare al ciclo per
 la verifica delle opzioni (\texttt{\small 2-27}); per ciascuna delle opzioni
-possibili si è poi provveduto ad un'azione opportuna, ad esempio per le tre
-opzioni che prevedono un parametro si è effettuata la decodifica del medesimo
-(il cui indirizzo è contenuto nella variabile \var{optarg}) avvalorando la
+possibili si è poi provveduto ad un'azione opportuna, ad esempio per le tre
+opzioni che prevedono un parametro si è effettuata la decodifica del medesimo
+(il cui indirizzo è contenuto nella variabile \var{optarg}) avvalorando la
 relativa variabile (\texttt{\small 12-14}, \texttt{\small 15-17} e
 \texttt{\small 18-20}). Completato il ciclo troveremo in \var{optind} l'indice
 in \code{argv[]} del primo degli argomenti rimanenti nella linea di comando.
 
 Normalmente \func{getopt} compie una permutazione degli elementi di
-\param{argv} cosicché alla fine della scansione gli elementi che non sono
+\param{argv} cosicché alla fine della scansione gli elementi che non sono
 opzioni sono spostati in coda al vettore. Oltre a questa esistono altre due
-modalità di gestire gli elementi di \param{argv}; se \param{optstring} inizia
-con il carattere \texttt{'+'} (o è impostata la variabile di ambiente
+modalità di gestire gli elementi di \param{argv}; se \param{optstring} inizia
+con il carattere \texttt{'+'} (o è impostata la variabile di ambiente
 \macro{POSIXLY\_CORRECT}) la scansione viene fermata non appena si incontra un
-elemento che non è un'opzione. 
+elemento che non è un'opzione. 
 
-L'ultima modalità, usata quando un programma può gestire la mescolanza fra
+L'ultima modalità, usata quando un programma può gestire la mescolanza fra
 opzioni e argomenti, ma se li aspetta in un ordine definito, si attiva
 quando \param{optstring} inizia con il carattere \texttt{'-'}. In questo caso
-ogni elemento che non è un'opzione viene considerato comunque un'opzione e
+ogni elemento che non è un'opzione viene considerato comunque un'opzione e
 associato ad un valore di ritorno pari ad 1, questo permette di identificare
 gli elementi che non sono opzioni, ma non effettua il riordinamento del
 vettore \param{argv}.
@@ -1418,7 +1418,7 @@ vettore \param{argv}.
 \subsection{Le variabili di ambiente}
 \label{sec:proc_environ}
 
-Oltre agli argomenti passati a linea di comando esiste un'altra modalità che
+Oltre agli argomenti passati a linea di comando esiste un'altra modalità che
 permette di trasferire ad un processo delle informazioni in modo da
 modificarne il comportamento.  Ogni processo infatti riceve dal sistema, oltre
 alle variabili \param{argv} e \param{argc} anche un \textsl{ambiente} (in
@@ -1430,19 +1430,19 @@ programma.
 Anche in questo caso la lista delle \textsl{variabili di ambiente} deve essere
 costruita ed utilizzata nella chiamata alla funzione \func{exec} (torneremo su
 questo in sez.~\ref{sec:proc_exec}) quando questo viene lanciato. Come per la
-lista degli argomenti anche questa lista è un vettore di puntatori a
+lista degli argomenti anche questa lista è un vettore di puntatori a
 caratteri, ciascuno dei quali punta ad una stringa, terminata da un
 \val{NULL}. A differenza di \code{argv[]} in questo caso non si ha una
-lunghezza del vettore data da un equivalente di \param{argc}, ma la lista è
+lunghezza del vettore data da un equivalente di \param{argc}, ma la lista è
 terminata da un puntatore nullo.
 
-L'indirizzo della lista delle variabili di ambiente è passato attraverso la
+L'indirizzo della lista delle variabili di ambiente è passato attraverso la
 variabile globale \var{environ}, che viene definita automaticamente per
-cisascun processo, e a cui si può accedere attraverso una semplice
+cisascun processo, e a cui si può accedere attraverso una semplice
 dichiarazione del tipo:
 \includecodesnip{listati/env_ptr.c}
 un esempio della struttura di questa lista, contenente alcune delle variabili
-più comuni che normalmente sono definite dal sistema, è riportato in
+più comuni che normalmente sono definite dal sistema, è riportato in
 fig.~\ref{fig:proc_envirno_list}.
 \begin{figure}[htb]
   \centering
@@ -1484,15 +1484,15 @@ che vedremo a breve se le aspettano, se pertanto si dovesse costruire
 manualemente un ambiente si abbia cura di rispettare questa convenzione.
 Inoltre alcune variabili, come quelle elencate in
 fig.~\ref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
-da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
+da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
 usare nomi espressi in caratteri maiuscoli.\footnote{ma si tratta solo di una
   convenzione, niente vieta di usare caratteri minuscoli.}
 
-Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
+Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
 riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
 costituiscono un modo comodo per definire un comportamento specifico senza
 dover ricorrere all'uso di opzioni a linea di comando o di file di
-configurazione. É di norma cura della shell, quando esegue un comando, passare
+configurazione. É di norma cura della shell, quando esegue un comando, passare
 queste variabili al programma messo in esecuzione attraverso un uso opportuno
 delle relative chiamate (si veda sez.~\ref{sec:proc_exec}).
 
@@ -1500,22 +1500,22 @@ La shell ad esempio ne usa molte per il suo funzionamento, come \texttt{PATH}
 per indicare la lista delle directory in cui effettuare la ricerca dei comandi
 o \texttt{PS1} per impostare il proprio \textit{prompt}. Alcune di esse, come
 \texttt{HOME}, \texttt{USER}, ecc. sono invece definite al login (per i
-dettagli si veda sez.~\ref{sec:sess_login}), ed in genere è cura della propria
+dettagli si veda sez.~\ref{sec:sess_login}), ed in genere è cura della propria
 distribuzione definire le opportune variabili di ambiente in uno script di
 avvio. Alcune servono poi come riferimento generico per molti programmi, come
 \texttt{EDITOR} che indica l'editor preferito da invocare in caso di
-necessità. Una in particolare, \texttt{LANG}, serve a controllare la
+necessità. Una in particolare, \texttt{LANG}, serve a controllare la
 localizzazione del programma (su cui torneremo in
 sez.~\ref{sec:proc_localization}) per adattarlo alla lingua ed alle convezioni
 dei vari paesi.
 
-Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
+Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
 comuni), come riportato in tab.~\ref{tab:proc_env_var}. GNU/Linux le supporta
 tutte e ne definisce anche altre, in particolare poi alcune funzioni di
 libreria prevedono la presenza di specifiche variabili di ambiente che ne
 modificano il comportamento, come quelle usate per indicare una localizzazione
-e quelle per indicare un fuso orario; una lista più completa che comprende
-queste ed ulteriori variabili si può ottenere con il comando \cmd{man 7
+e quelle per indicare un fuso orario; una lista più completa che comprende
+queste ed ulteriori variabili si può ottenere con il comando \cmd{man 7
   environ}.
 
 \begin{table}[htb]
@@ -1545,7 +1545,7 @@ queste ed ulteriori variabili si pu
                                                     temporanei\\
     \hline
   \end{tabular}
-  \caption{Esempi delle variabili di ambiente più comuni definite da vari
+  \caption{Esempi delle variabili di ambiente più comuni definite da vari
     standard.} 
   \label{tab:proc_env_var}
 \end{table}
@@ -1553,7 +1553,7 @@ queste ed ulteriori variabili si pu
 Lo standard ANSI C prevede l'esistenza di un ambiente, e pur non entrando
 nelle specifiche di come sono strutturati i contenuti, definisce la funzione
 \funcd{getenv} che permette di ottenere i valori delle variabili di ambiente;
-il suo prototipo è:
+il suo prototipo è:
 \begin{prototype}{stdlib.h}{char *getenv(const char *name)}
   Esamina l'ambiente del processo cercando una stringa che corrisponda a
   quella specificata da \param{name}. 
@@ -1563,10 +1563,10 @@ il suo prototipo 
     \cmd{NOME=valore}).}
 \end{prototype}
 
-Oltre a questa funzione di lettura, che è l'unica definita dallo standard ANSI
+Oltre a questa funzione di lettura, che è l'unica definita dallo standard ANSI
 C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
 utilizzare per impostare e per cancellare le variabili di ambiente. Uno schema
-delle funzioni previste nei vari standard e disponibili in Linux è riportato
+delle funzioni previste nei vari standard e disponibili in Linux è riportato
 in tab.~\ref{tab:proc_env_func}.
 
 \begin{table}[htb]
@@ -1594,8 +1594,8 @@ in tab.~\ref{tab:proc_env_func}.
   \label{tab:proc_env_func}
 \end{table}
 
-In Linux\footnote{in realtà nelle libc4 e libc5 sono definite solo le prime
-  quattro, \func{clearenv} è stata introdotta con le \acr{glibc} 2.0.} sono
+In Linux\footnote{in realtà nelle libc4 e libc5 sono definite solo le prime
+  quattro, \func{clearenv} è stata introdotta con le \acr{glibc} 2.0.} sono
 definite tutte le funzioni elencate in tab.~\ref{tab:proc_env_func}. La prima,
 \func{getenv}, l'abbiamo appena esaminata; delle restanti le prime due,
 \funcd{putenv} e \funcd{setenv}, servono per assegnare nuove variabili di
@@ -1610,11 +1610,11 @@ ambiente, i loro prototipi sono i seguenti:
   all'ambiente.
   
   \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e $-1$ per un
-    errore, che è sempre \errval{ENOMEM}.}
+    errore, che è sempre \errval{ENOMEM}.}
 \end{functions}
 
 La terza funzione della lista, \funcd{unsetenv}, serve a cancellare una
-variabile dall'ambiente, il suo prototipo è:
+variabile dall'ambiente, il suo prototipo è:
 \begin{functions}
   \headdecl{stdlib.h}
   
@@ -1623,51 +1623,51 @@ variabile dall'ambiente, il suo prototipo 
 \end{functions}
 
 \noindent la funzione elimina ogni occorrenza della variabile specificata; se la
-variabile non esiste non succede nulla. Non è prevista (dato che la funzione è
+variabile non esiste non succede nulla. Non è prevista (dato che la funzione è
 \ctyp{void}) nessuna segnalazione di errore.
 
 Per modificare o aggiungere una variabile di ambiente si possono usare sia
 \func{setenv} che \func{putenv}. La prima permette di specificare
 separatamente nome e valore della variabile di ambiente, inoltre il valore di
 \param{overwrite} specifica il comportamento della funzione nel caso la
-variabile esista già, sovrascrivendola se diverso da zero, lasciandola
+variabile esista già, sovrascrivendola se diverso da zero, lasciandola
 immutata se uguale a zero.
 
 La seconda funzione prende come argomento una stringa analoga a quella
 restituita da \func{getenv}, e sempre nella forma \code{NOME=valore}. Se la
-variabile specificata non esiste la stringa sarà aggiunta all'ambiente, se
-invece esiste il suo valore sarà impostato a quello specificato da
+variabile specificata non esiste la stringa sarà aggiunta all'ambiente, se
+invece esiste il suo valore sarà impostato a quello specificato da
 \param{string}. 
 
 Si tenga presente che, seguendo lo standard SUSv2, le \acr{glibc} successive
 alla versione 2.1.2 aggiungono \param{string} alla lista delle variabili di
-ambiente;\footnote{il comportamento è lo stesso delle vecchie \acr{libc4} e
+ambiente;\footnote{il comportamento è lo stesso delle vecchie \acr{libc4} e
   \acr{libc5}; nelle \acr{glibc}, dalla versione 2.0 alla 2.1.1, veniva invece
-  fatta una copia, seguendo il comportamento di BSD4.4; dato che questo può
+  fatta una copia, seguendo il comportamento di BSD4.4; dato che questo può
   dar luogo a perdite di memoria e non rispetta lo standard. Il comportamento
-  è stato modificato a partire dalle 2.1.2, eliminando anche, sempre in
-  conformità a SUSv2, l'attributo \direct{const} dal prototipo.} pertanto ogni
+  è stato modificato a partire dalle 2.1.2, eliminando anche, sempre in
+  conformità a SUSv2, l'attributo \direct{const} dal prototipo.} pertanto ogni
 cambiamento alla stringa in questione si riflette automaticamente
 sull'ambiente, e quindi si deve evitare di passare a questa funzione una
 variabile automatica (per evitare i problemi esposti in
 sez.~\ref{sec:proc_auto_var}). Si tenga infine presente che se si passa a
-\func{putenv} solo il nome di una variabile (cioè \param{string} è nella forma
+\func{putenv} solo il nome di una variabile (cioè \param{string} è nella forma
 \texttt{NAME} e non contiene un carattere \texttt{'='}) allora questa viene
 cancellata dall'ambiente.
 
-Infine quando chiamata a \func{putenv} comporta la necessità di creare una
-nuova versione del vettore \var{environ} questo sarà allocato automaticamente,
-ma la versione corrente sarà deallocata solo se anch'essa è risultante da
+Infine quando chiamata a \func{putenv} comporta la necessità di creare una
+nuova versione del vettore \var{environ} questo sarà allocato automaticamente,
+ma la versione corrente sarà deallocata solo se anch'essa è risultante da
 un'allocazione fatta in precedenza da un'altra \func{putenv}. Questo avviene
-perché il vettore delle variabili di ambiente iniziale, creato dalla chiamata
-ad \func{exec} (vedi sez.~\ref{sec:proc_exec}) è piazzato nella memoria al di
+perché il vettore delle variabili di ambiente iniziale, creato dalla chiamata
+ad \func{exec} (vedi sez.~\ref{sec:proc_exec}) è piazzato nella memoria al di
 sopra dello \itindex{stack} stack, (vedi fig.~\ref{fig:proc_mem_layout}) e non
-nello \itindex{heap} \textit{heap} e quindi non può essere deallocato.
+nello \itindex{heap} \textit{heap} e quindi non può essere deallocato.
 Inoltre la memoria associata alle variabili di ambiente eliminate non viene
 liberata.
 
-L'ultima funzione per la gestione dell'ambiente è \funcd{clearenv}, che viene
-usata per cancellare completamente tutto l'ambiente; il suo prototipo è:
+L'ultima funzione per la gestione dell'ambiente è \funcd{clearenv}, che viene
+usata per cancellare completamente tutto l'ambiente; il suo prototipo è:
 \begin{functions}
   \headdecl{stdlib.h}
   
@@ -1680,7 +1680,7 @@ usata per cancellare completamente tutto l'ambiente; il suo prototipo 
 
 In genere si usa questa funzione in maniera precauzionale per evitare i
 problemi di sicurezza connessi nel trasmettere ai programmi che si invocano un
-ambiente che può contenere dei dati non controllati. In tal caso si provvede
+ambiente che può contenere dei dati non controllati. In tal caso si provvede
 alla cancellazione di tutto l'ambiente per costruirne una versione
 ``\textsl{sicura}'' da zero.
 
@@ -1689,7 +1689,7 @@ alla cancellazione di tutto l'ambiente per costruirne una versione
 
 Abbiamo accennato in sez.~\ref{sec:proc_environ} come la variabile di ambiente
 \texttt{LANG} sia usata per indicare ai processi il valore della cosiddetta
-\textsl{localizzazione}. Si tratta di una funzionalità fornita dalle librerie
+\textsl{localizzazione}. Si tratta di una funzionalità fornita dalle librerie
 di sistema\footnote{prenderemo in esame soltanto il caso delle \acr{glibc}.}
 che consente di gestire in maniera automatica sia la lingua in cui vengono
 stampati i vari messaggi (come i messaggi associati agli errori che vedremo in
@@ -1697,58 +1697,58 @@ sez.~\ref{sec:sys_strerror}) che le convenzioni usate nei vari paesi per una
 serie di aspetti come il formato dell'ora, quello delle date, gli ordinamenti
 alfabetici, le espressioni della valute, ecc.
 
-La localizzazione di un programma si può selezionare con la 
+La localizzazione di un programma si può selezionare con la 
 
 
-In realtà perché un programma sia effettivamente localizzato non è sufficiente 
+In realtà perché un programma sia effettivamente localizzato non è sufficiente 
 
-% TODO trattare, quando ci sarà tempo, setlocale ed il resto
+% TODO trattare, quando ci sarà tempo, setlocale ed il resto
 
 
 %\subsection{Opzioni in formato esteso}
 %\label{sec:proc_opt_extended}
 
-%Oltre alla modalità ordinaria di gestione delle opzioni trattata in
-%sez.~\ref{sec:proc_opt_handling} le \acr{glibc} forniscono una modalità
+%Oltre alla modalità ordinaria di gestione delle opzioni trattata in
+%sez.~\ref{sec:proc_opt_handling} le \acr{glibc} forniscono una modalità
 %alternativa costituita dalle cosiddette \textit{long-options}, che consente di
-%esprimere le opzioni in una forma più descrittiva che nel caso più generale è
+%esprimere le opzioni in una forma più descrittiva che nel caso più generale è
 %qualcosa del tipo di ``\texttt{-{}-option-name=parameter}''.
 
-%(NdA: questa parte verrà inserita in seguito).
+%(NdA: questa parte verrà inserita in seguito).
 
 % TODO opzioni in formato esteso
 
 \section{Problematiche di programmazione generica}
 \label{sec:proc_gen_prog}
 
-Benché questo non sia un libro di C, è opportuno affrontare alcune delle
+Benché questo non sia un libro di C, è opportuno affrontare alcune delle
 problematiche generali che possono emergere nella programmazione e di quali
 precauzioni o accorgimenti occorre prendere per risolverle. Queste
 problematiche non sono specifiche di sistemi unix-like o multitasking, ma
 avendo trattato in questo capitolo il comportamento dei processi visti come
-entità a sé stanti, le riportiamo qui.
+entità a sé stanti, le riportiamo qui.
 
 
 \subsection{Il passaggio delle variabili e dei valori di ritorno}
 \label{sec:proc_var_passing}
 
-Una delle caratteristiche standard del C è che le variabili vengono passate
+Una delle caratteristiche standard del C è che le variabili vengono passate
 alle subroutine attraverso un meccanismo che viene chiamato \textit{by value}
 (diverso ad esempio da quanto avviene con il Fortran, dove le variabili sono
-passate, come suol dirsi, \textit{by reference}, o dal C++ dove la modalità
-del passaggio può essere controllata con l'operatore \cmd{\&}).
+passate, come suol dirsi, \textit{by reference}, o dal C++ dove la modalità
+del passaggio può essere controllata con l'operatore \cmd{\&}).
 
-Il passaggio di una variabile \textit{by value} significa che in realtà quello
-che viene passato alla subroutine è una copia del valore attuale di quella
-variabile, copia che la subroutine potrà modificare a piacere, senza che il
+Il passaggio di una variabile \textit{by value} significa che in realtà quello
+che viene passato alla subroutine è una copia del valore attuale di quella
+variabile, copia che la subroutine potrà modificare a piacere, senza che il
 valore originale nella funzione chiamante venga toccato. In questo modo non
 occorre preoccuparsi di eventuali effetti delle operazioni della subroutine
 sulla variabile passata come argomento.
 
-Questo però va inteso nella maniera corretta. Il passaggio \textit{by value}
-vale per qualunque variabile, puntatori compresi; quando però in una
+Questo però va inteso nella maniera corretta. Il passaggio \textit{by value}
+vale per qualunque variabile, puntatori compresi; quando però in una
 subroutine si usano dei puntatori (ad esempio per scrivere in un buffer) in
-realtà si va a modificare la zona di memoria a cui essi puntano, per cui anche
+realtà si va a modificare la zona di memoria a cui essi puntano, per cui anche
 se i puntatori sono copie, i dati a cui essi puntano sono sempre gli stessi, e
 le eventuali modifiche avranno effetto e saranno visibili anche nella funzione
 chiamante.
@@ -1757,14 +1757,14 @@ Nella maggior parte delle funzioni di libreria e delle system call i puntatori
 vengono usati per scambiare dati (attraverso buffer o strutture) e le
 variabili semplici vengono usate per specificare argomenti; in genere le
 informazioni a riguardo dei risultati vengono passate alla funzione chiamante
-attraverso il valore di ritorno.  È buona norma seguire questa pratica anche
+attraverso il valore di ritorno.  È buona norma seguire questa pratica anche
 nella programmazione normale.
 
-Talvolta però è necessario che la funzione possa restituire indietro alla
+Talvolta però è necessario che la funzione possa restituire indietro alla
 funzione chiamante un valore relativo ad uno dei suoi argomenti.  Per far
 questo si usa il cosiddetto \itindex{value~result~argument} \textit{value
-  result argument}, si passa cioè, invece di una normale variabile, un
-puntatore alla stessa; vedremo alcuni esempi di questa modalità nelle funzioni
+  result argument}, si passa cioè, invece di una normale variabile, un
+puntatore alla stessa; vedremo alcuni esempi di questa modalità nelle funzioni
 che gestiscono i socket (in sez.~\ref{sec:TCP_functions}), in cui, per
 permettere al kernel di restituire informazioni sulle dimensioni delle
 strutture degli indirizzi utilizzate, viene usato questo meccanismo.
@@ -1773,14 +1773,14 @@ strutture degli indirizzi utilizzate, viene usato questo meccanismo.
 \subsection{Il passaggio di un numero variabile di argomenti}
 \label{sec:proc_variadic}
 
-Come vedremo nei capitoli successivi, non sempre è possibile specificare un
+Come vedremo nei capitoli successivi, non sempre è possibile specificare un
 numero fisso di argomenti per una funzione.  Lo standard ISO C prevede nella
-sua sintassi la possibilità di definire delle \index{variadic}
+sua sintassi la possibilità di definire delle \index{variadic}
 \textit{variadic function} che abbiano un numero variabile di argomenti,
 attraverso l'uso nella dichiarazione della funzione dello speciale costrutto
 ``\texttt{\textellipsis}'', che viene chiamato \textit{ellipsis}.
 
-Lo standard però non provvede a livello di linguaggio alcun meccanismo con cui
+Lo standard però non provvede a livello di linguaggio alcun meccanismo con cui
 dette funzioni possono accedere ai loro argomenti.  L'accesso viene pertanto
 realizzato a livello delle librerie standard del C che provvedono gli
 strumenti adeguati.  L'uso di una \textit{variadic function} prevede quindi
@@ -1798,7 +1798,7 @@ tre punti:
 Lo standard ISO C prevede che una \index{variadic} \textit{variadic function}
 abbia sempre almeno un argomento fisso; prima di effettuare la dichiarazione
 deve essere incluso l'apposito header file \file{stdarg.h}; un esempio di
-dichiarazione è il prototipo della funzione \func{execl} che vedremo in
+dichiarazione è il prototipo della funzione \func{execl} che vedremo in
 sez.~\ref{sec:proc_exec}:
 \includecodesnip{listati/exec_sample.c}
 in questo caso la funzione prende due argomenti fissi ed un numero variabile
@@ -1807,38 +1807,38 @@ del vettore \param{argv} passato al nuovo processo). Lo standard ISO C
 richiede inoltre che l'ultimo degli argomenti fissi sia di tipo
 \textit{self-promoting}\footnote{il linguaggio C prevede che quando si
   mescolano vari tipi di dati, alcuni di essi possano essere \textsl{promossi}
-  per compatibilità; ad esempio i tipi \ctyp{float} vengono convertiti
+  per compatibilità; ad esempio i tipi \ctyp{float} vengono convertiti
   automaticamente a \ctyp{double} ed i \ctyp{char} e gli \ctyp{short} ad
-  \ctyp{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
-  a sé stesso.} il che esclude vettori, puntatori a funzioni e interi di tipo
+  \ctyp{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
+  a sé stesso.} il che esclude vettori, puntatori a funzioni e interi di tipo
 \ctyp{char} o \ctyp{short} (con segno o meno). Una restrizione ulteriore di
-alcuni compilatori è di non dichiarare l'ultimo argomento fisso come
+alcuni compilatori è di non dichiarare l'ultimo argomento fisso come
 \direct{register}.
 
-Una volta dichiarata la funzione il secondo passo è accedere ai vari argomenti
+Una volta dichiarata la funzione il secondo passo è accedere ai vari argomenti
 quando la si va a definire. Gli argomenti fissi infatti hanno un loro nome, ma
 quelli variabili vengono indicati in maniera generica dalla \textit{ellipsis}.
 
-L'unica modalità in cui essi possono essere recuperati è pertanto quella
+L'unica modalità in cui essi possono essere recuperati è pertanto quella
 sequenziale; essi verranno estratti dallo \itindex{stack} \textit{stack}
 secondo l'ordine in cui sono stati scritti. Per fare questo in \file{stdarg.h}
-sono definite delle apposite macro; la procedura da seguire è la seguente:
+sono definite delle apposite macro; la procedura da seguire è la seguente:
 \begin{enumerate*}
 \item Inizializzare un puntatore alla lista degli argomenti di tipo
   \macro{va\_list} attraverso la macro \macro{va\_start}.
 \item Accedere ai vari argomenti opzionali con chiamate successive alla macro
-  \macro{va\_arg}, la prima chiamata restituirà il primo argomento, la seconda
-  il secondo e così via.
+  \macro{va\_arg}, la prima chiamata restituirà il primo argomento, la seconda
+  il secondo e così via.
 \item Dichiarare la conclusione dell'estrazione degli argomenti invocando la
   macro \macro{va\_end}.
 \end{enumerate*}
-In generale è perfettamente legittimo richiedere meno argomenti di quelli che
+In generale è perfettamente legittimo richiedere meno argomenti di quelli che
 potrebbero essere stati effettivamente forniti, e nella esecuzione delle
-\macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
-saranno ignorati; se invece si richiedono più argomenti di quelli forniti si
+\macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
+saranno ignorati; se invece si richiedono più argomenti di quelli forniti si
 otterranno dei valori indefiniti. Nel caso del \cmd{gcc} l'uso della macro
-\macro{va\_end} è inutile, ma si consiglia di usarlo ugualmente per
-compatibilità.
+\macro{va\_end} è inutile, ma si consiglia di usarlo ugualmente per
+compatibilità.
 
 Le definizioni delle tre macro sono le seguenti:
 \begin{functions}
@@ -1857,34 +1857,34 @@ Le definizioni delle tre macro sono le seguenti:
   \funcdecl{void va\_end(va\_list ap)} Conclude l'uso di \param{ap}.
 \end{functions}
 
-In generale si possono avere più puntatori alla lista degli argomenti,
-ciascuno andrà inizializzato con \macro{va\_start} e letto con \macro{va\_arg}
-e ciascuno potrà scandire la lista degli argomenti per conto suo. 
+In generale si possono avere più puntatori alla lista degli argomenti,
+ciascuno andrà inizializzato con \macro{va\_start} e letto con \macro{va\_arg}
+e ciascuno potrà scandire la lista degli argomenti per conto suo. 
 
 Dopo l'uso di \macro{va\_end} la variabile \param{ap} diventa indefinita e
 successive chiamate a \macro{va\_arg} non funzioneranno. Si avranno risultati
 indefiniti anche chiamando \macro{va\_arg} specificando un tipo che non
 corrisponde a quello dell'argomento.
 
-Un altro limite delle macro è che i passi 1) e 3) devono essere eseguiti nel
-corpo principale della funzione, il passo 2) invece può essere eseguito anche
+Un altro limite delle macro è che i passi 1) e 3) devono essere eseguiti nel
+corpo principale della funzione, il passo 2) invece può essere eseguito anche
 in una subroutine passandole il puntatore alla lista di argomenti; in questo
-caso però si richiede che al ritorno della funzione il puntatore non venga più
+caso però si richiede che al ritorno della funzione il puntatore non venga più
 usato (lo standard richiederebbe la chiamata esplicita di \macro{va\_end}),
 dato che il valore di \param{ap} risulterebbe indefinito.
 
-Esistono dei casi in cui è necessario eseguire più volte la scansione degli
-argomenti e poter memorizzare una posizione durante la stessa.  La cosa più
+Esistono dei casi in cui è necessario eseguire più volte la scansione degli
+argomenti e poter memorizzare una posizione durante la stessa.  La cosa più
 naturale in questo caso sembrerebbe quella di copiarsi il puntatore alla lista
 degli argomenti con una semplice assegnazione. Dato che una delle
-realizzazioni più comuni di \macro{va\_list} è quella di un puntatore nello
+realizzazioni più comuni di \macro{va\_list} è quella di un puntatore nello
 \itindex{stack} \textit{stack} all'indirizzo dove sono stati salvati gli
-argomenti, è assolutamente normale pensare di poter effettuare questa
+argomenti, è assolutamente normale pensare di poter effettuare questa
 operazione.
 
-In generale però possono esistere anche realizzazioni diverse, per questo
-motivo \macro{va\_list} è definito come \index{tipo!opaco} \textsl{tipo opaco}
-e non può essere assegnato direttamente ad un'altra variabile dello stesso
+In generale però possono esistere anche realizzazioni diverse, per questo
+motivo \macro{va\_list} è definito come \index{tipo!opaco} \textsl{tipo opaco}
+e non può essere assegnato direttamente ad un'altra variabile dello stesso
 tipo. Per risolvere questo problema lo standard ISO C99\footnote{alcuni
   sistemi che non hanno questa macro provvedono al suo posto
   \macro{\_\_va\_copy} che era il nome proposto in una bozza dello standard.}
@@ -1894,35 +1894,35 @@ puntatore alla lista degli argomenti:
   Copia l'attuale valore \param{src} del puntatore alla lista degli argomenti
   su \param{dest}.
 \end{prototype}
-\noindent anche in questo caso è buona norma chiudere ogni esecuzione di una
+\noindent anche in questo caso è buona norma chiudere ogni esecuzione di una
 \macro{va\_copy} con una corrispondente \macro{va\_end} sul nuovo puntatore
 alla lista degli argomenti.
 
 La chiamata di una funzione con un numero variabile di argomenti, posto che la
 si sia dichiarata e definita come tale, non prevede nulla di particolare;
-l'invocazione è identica alle altre, con gli argomenti, sia quelli fissi che
-quelli opzionali, separati da virgole. Quello che però è necessario tenere
-presente è come verranno convertiti gli argomenti variabili.
+l'invocazione è identica alle altre, con gli argomenti, sia quelli fissi che
+quelli opzionali, separati da virgole. Quello che però è necessario tenere
+presente è come verranno convertiti gli argomenti variabili.
 
 In Linux gli argomenti dello stesso tipo sono passati allo stesso modo, sia
 che siano fissi sia che siano opzionali (alcuni sistemi trattano diversamente
-gli opzionali), ma dato che il prototipo non può specificare il tipo degli
+gli opzionali), ma dato che il prototipo non può specificare il tipo degli
 argomenti opzionali, questi verranno sempre promossi, pertanto nella ricezione
-dei medesimi occorrerà tenerne conto (ad esempio un \ctyp{char} verrà visto da
+dei medesimi occorrerà tenerne conto (ad esempio un \ctyp{char} verrà visto da
 \macro{va\_arg} come \ctyp{int}).
 
 Uno dei problemi che si devono affrontare con le funzioni con un numero
-variabile di argomenti è che non esiste un modo generico che permetta di
+variabile di argomenti è che non esiste un modo generico che permetta di
 stabilire quanti sono gli argomenti passati effettivamente in una chiamata.
 
-Esistono varie modalità per affrontare questo problema; una delle più
-immediate è quella di specificare il numero degli argomenti opzionali come uno
-degli argomenti fissi. Una variazione di questo metodo è l'uso di un argomento
+Esistono varie modalità per affrontare questo problema; una delle più
+immediate è quella di specificare il numero degli argomenti opzionali come uno
+degli argomenti fissi. Una variazione di questo metodo è l'uso di un argomento
 per specificare anche il tipo degli argomenti (come fa la stringa di formato
 per \func{printf}). 
 
-Una modalità diversa, che può essere applicata solo quando il tipo degli
-argomenti lo rende possibile, è quella che prevede di usare un valore speciale
+Una modalità diversa, che può essere applicata solo quando il tipo degli
+argomenti lo rende possibile, è quella che prevede di usare un valore speciale
 come ultimo argomento (come fa ad esempio \func{execl} che usa un puntatore
 \val{NULL} per indicare la fine della lista degli argomenti).
 
@@ -1930,14 +1930,14 @@ come ultimo argomento (come fa ad esempio \func{execl} che usa un puntatore
 \subsection{Potenziali problemi con le variabili automatiche}
 \label{sec:proc_auto_var}
 
-Uno dei possibili problemi che si possono avere con le subroutine è quello di
+Uno dei possibili problemi che si possono avere con le subroutine è quello di
 restituire alla funzione chiamante dei dati che sono contenuti in una
 variabile automatica.  Ovviamente quando la subroutine ritorna la sezione
 dello \itindex{stack} \textit{stack} che conteneva la variabile automatica
-potrà essere riutilizzata da una nuova funzione, con le immaginabili
+potrà essere riutilizzata da una nuova funzione, con le immaginabili
 conseguenze di sovrapposizione e sovrascrittura dei dati.
 
-Per questo una delle regole fondamentali della programmazione in C è che
+Per questo una delle regole fondamentali della programmazione in C è che
 all'uscita di una funzione non deve restare nessun riferimento alle variabili
 locali; qualora sia necessario utilizzare variabili che possano essere viste
 anche dalla funzione chiamante queste devono essere allocate esplicitamente, o
@@ -1949,58 +1949,58 @@ dinamicamente con una delle funzioni della famiglia \func{malloc}.
 \label{sec:proc_longjmp}
 
 Il controllo del flusso di un programma in genere viene effettuato con le
-varie istruzioni del linguaggio C; fra queste la più bistrattata è il
+varie istruzioni del linguaggio C; fra queste la più bistrattata è il
 \code{goto}, che viene deprecato in favore dei costrutti della programmazione
-strutturata, che rendono il codice più leggibile e mantenibile. Esiste però un
-caso in cui l'uso di questa istruzione porta all'implementazione più
-efficiente e più chiara anche dal punto di vista della struttura del
+strutturata, che rendono il codice più leggibile e mantenibile. Esiste però un
+caso in cui l'uso di questa istruzione porta all'implementazione più
+efficiente e più chiara anche dal punto di vista della struttura del
 programma: quello dell'uscita in caso di errore.
 
 \index{salto~non-locale|(} 
 
-Il C però non consente di effettuare un salto ad una etichetta definita in
+Il C però non consente di effettuare un salto ad una etichetta definita in
 un'altra funzione, per cui se l'errore avviene in una funzione, e la sua
-gestione ordinaria è in un'altra, occorre usare quello che viene chiamato un
-\textsl{salto non-locale}.  Il caso classico in cui si ha questa necessità,
-citato sia in \cite{APUE} che in \cite{glibc}, è quello di un programma nel
+gestione ordinaria è in un'altra, occorre usare quello che viene chiamato un
+\textsl{salto non-locale}.  Il caso classico in cui si ha questa necessità,
+citato sia in \cite{APUE} che in \cite{glibc}, è quello di un programma nel
 cui corpo principale vengono letti dei dati in ingresso sui quali viene
 eseguita, tramite una serie di funzioni di analisi, una scansione dei
 contenuti, da cui si ottengono le indicazioni per l'esecuzione di opportune
 operazioni.
 
-Dato che l'analisi può risultare molto complessa, ed opportunamente suddivisa
-in fasi diverse, la rilevazione di un errore nei dati in ingresso può accadere
+Dato che l'analisi può risultare molto complessa, ed opportunamente suddivisa
+in fasi diverse, la rilevazione di un errore nei dati in ingresso può accadere
 all'interno di funzioni profondamente annidate l'una nell'altra. In questo
 caso si dovrebbe gestire, per ciascuna fase, tutta la casistica del passaggio
 all'indietro di tutti gli errori rilevabili dalle funzioni usate nelle fasi
-successive.  Questo comporterebbe una notevole complessità, mentre sarebbe
-molto più comodo poter tornare direttamente al ciclo di lettura principale,
+successive.  Questo comporterebbe una notevole complessità, mentre sarebbe
+molto più comodo poter tornare direttamente al ciclo di lettura principale,
 scartando l'input come errato.\footnote{a meno che, come precisa \cite{glibc},
   alla chiusura di ciascuna fase non siano associate operazioni di pulizia
   specifiche (come deallocazioni, chiusure di file, ecc.), che non potrebbero
   essere eseguite con un salto non-locale.}
 
-Tutto ciò può essere realizzato proprio con un salto non-locale; questo di
+Tutto ciò può essere realizzato proprio con un salto non-locale; questo di
 norma viene realizzato salvando il contesto dello \itindex{stack}
 \textit{stack} nel punto in cui si vuole tornare in caso di errore, e
 ripristinandolo, in modo da tornare nella funzione da cui si era partiti,
 quando serve.  La funzione che permette di salvare il contesto dello
-\itindex{stack} \textit{stack} è \funcd{setjmp}, il cui prototipo è:
+\itindex{stack} \textit{stack} è \funcd{setjmp}, il cui prototipo è:
 \begin{functions}
   \headdecl{setjmp.h}
   \funcdecl{int setjmp(jmp\_buf env)}
   
   Salva il contesto dello stack. 
 
-  \bodydesc{La funzione ritorna zero quando è chiamata direttamente e un
+  \bodydesc{La funzione ritorna zero quando è chiamata direttamente e un
     valore diverso da zero quando ritorna da una chiamata di \func{longjmp}
     che usa il contesto salvato in precedenza.}
 \end{functions}
   
 Quando si esegue la funzione il contesto corrente dello \itindex{stack}
 \textit{stack} viene salvato nell'argomento \param{env}, una variabile di tipo
-\type{jmp\_buf}\footnote{questo è un classico esempio di variabile di
-  \index{tipo!opaco} \textsl{tipo opaco}. Si definiscono così strutture ed
+\type{jmp\_buf}\footnote{questo è un classico esempio di variabile di
+  \index{tipo!opaco} \textsl{tipo opaco}. Si definiscono così strutture ed
   altri oggetti usati da una libreria, la cui struttura interna non deve
   essere vista dal programma chiamante (da cui il nome) che li devono
   utilizzare solo attraverso dalle opportune funzioni di gestione.}  che deve
@@ -2009,17 +2009,17 @@ essere stata definita in precedenza. In genere le variabili di tipo
 essere viste in tutte le funzioni del programma.
 
 Quando viene eseguita direttamente la funzione ritorna sempre zero, un valore
-diverso da zero viene restituito solo quando il ritorno è dovuto ad una
+diverso da zero viene restituito solo quando il ritorno è dovuto ad una
 chiamata di \func{longjmp} in un'altra parte del programma che ripristina lo
 \itindex{stack} \textit{stack} effettuando il salto non-locale. Si tenga conto
 che il contesto salvato in \param{env} viene invalidato se la funzione che ha
 chiamato \func{setjmp} ritorna, nel qual caso un successivo uso di
-\func{longjmp} può comportare conseguenze imprevedibili (e di norma fatali)
+\func{longjmp} può comportare conseguenze imprevedibili (e di norma fatali)
 per il processo.
   
 Come accennato per effettuare un salto non-locale ad
 un punto precedentemente stabilito con \func{setjmp} si usa la funzione
-\funcd{longjmp}; il suo prototipo è:
+\funcd{longjmp}; il suo prototipo è:
 \begin{functions}
   \headdecl{setjmp.h}
   \funcdecl{void longjmp(jmp\_buf env, int val)}
@@ -2032,22 +2032,22 @@ un punto precedentemente stabilito con \func{setjmp} si usa la funzione
 La funzione ripristina il contesto dello \itindex{stack} \textit{stack}
 salvato da una chiamata a \func{setjmp} nell'argomento \param{env}. Dopo
 l'esecuzione della funzione il programma prosegue nel codice successivo al
-ritorno della \func{setjmp} con cui si era salvato \param{env}, che restituirà
+ritorno della \func{setjmp} con cui si era salvato \param{env}, che restituirà
 il valore
 \param{val} invece di zero.  Il valore di \param{val} specificato nella
-chiamata deve essere diverso da zero, se si è specificato 0 sarà comunque
+chiamata deve essere diverso da zero, se si è specificato 0 sarà comunque
 restituito 1 al suo posto.
 
-In sostanza un \func{longjmp} è analogo ad un \code{return}, solo che invece
+In sostanza un \func{longjmp} è analogo ad un \code{return}, solo che invece
 di ritornare alla riga successiva della funzione chiamante, il programma
-ritorna alla posizione della relativa \func{setjmp}, l'altra differenza è che
-il ritorno può essere effettuato anche attraverso diversi livelli di funzioni
+ritorna alla posizione della relativa \func{setjmp}, l'altra differenza è che
+il ritorno può essere effettuato anche attraverso diversi livelli di funzioni
 annidate.
 
 L'implementazione di queste funzioni comporta alcune restrizioni dato che esse
 interagiscono direttamente con la gestione dello \itindex{stack}
 \textit{stack} ed il funzionamento del compilatore stesso. In particolare
-\func{setjmp} è implementata con una macro, pertanto non si può cercare di
+\func{setjmp} è implementata con una macro, pertanto non si può cercare di
 ottenerne l'indirizzo, ed inoltre delle chiamate a questa funzione sono sicure
 solo in uno dei seguenti casi:
 \begin{itemize}
@@ -2058,41 +2058,41 @@ solo in uno dei seguenti casi:
   iterazione;
 \item come operando per l'operatore di negazione (\code{!}) in una espressione
   di controllo di un comando condizionale, di selezione o di iterazione;
-\item come espressione a sé stante.
+\item come espressione a sé stante.
 \end{itemize}
 
 In generale, dato che l'unica differenza fra la chiamata diretta e quella
-ottenuta da un \func{longjmp} è costituita dal valore di ritorno di
-\func{setjmp}, essa è usualmente chiamata all'interno di un comando \code{if}.
+ottenuta da un \func{longjmp} è costituita dal valore di ritorno di
+\func{setjmp}, essa è usualmente chiamata all'interno di un comando \code{if}.
 
-Uno dei punti critici dei salti non-locali è quello del valore delle
+Uno dei punti critici dei salti non-locali è quello del valore delle
 variabili, ed in particolare quello delle variabili automatiche della funzione
 a cui si ritorna. In generale le variabili globali e statiche mantengono i
 valori che avevano al momento della chiamata di \func{longjmp}, ma quelli
 delle variabili automatiche (o di quelle dichiarate
 \direct{register}\footnote{la direttiva \direct{register} del compilatore
   chiede che la variabile dichiarata tale sia mantenuta, nei limiti del
-  possibile, all'interno di un registro del processore. Questa direttiva è
+  possibile, all'interno di un registro del processore. Questa direttiva è
   originaria dell'epoca dai primi compilatori, quando stava al programmatore
-  scrivere codice ottimizzato, riservando esplicitamente alle variabili più
-  usate l'uso dei registri del processore. Oggi questa direttiva è in disuso
+  scrivere codice ottimizzato, riservando esplicitamente alle variabili più
+  usate l'uso dei registri del processore. Oggi questa direttiva è in disuso
   dato che tutti i compilatori sono normalmente in grado di valutare con
   maggior efficacia degli stessi programmatori quando sia il caso di eseguire
   questa ottimizzazione.}) sono in genere indeterminati.
 
-Quello che succede infatti è che i valori delle variabili che sono tenute in
+Quello che succede infatti è che i valori delle variabili che sono tenute in
 memoria manterranno il valore avuto al momento della chiamata di
 \func{longjmp}, mentre quelli tenuti nei registri del processore (che nella
 chiamata ad un'altra funzione vengono salvati nel contesto nello
 \itindex{stack} \textit{stack}) torneranno al valore avuto al momento della
 chiamata di \func{setjmp}; per questo quando si vuole avere un comportamento
-coerente si può bloccare l'ottimizzazione che porta le variabili nei registri
+coerente si può bloccare l'ottimizzazione che porta le variabili nei registri
 dichiarandole tutte come \direct{volatile}.\footnote{la direttiva
-  \direct{volatile} informa il compilatore che la variabile che è dichiarata
-  può essere modificata, durante l'esecuzione del nostro, da altri programmi.
+  \direct{volatile} informa il compilatore che la variabile che è dichiarata
+  può essere modificata, durante l'esecuzione del nostro, da altri programmi.
   Per questo motivo occorre dire al compilatore che non deve essere mai
   utilizzata l'ottimizzazione per cui quanto opportuno essa viene mantenuta in
-  un registro, poiché in questo modo si perderebbero le eventuali modifiche
+  un registro, poiché in questo modo si perderebbero le eventuali modifiche
   fatte dagli altri programmi (che avvengono solo in una copia posta in
   memoria).}
 
diff --git a/prochand.tex b/prochand.tex
index 62cabee..07af836 100644
--- a/prochand.tex
+++ b/prochand.tex
@@ -14,11 +14,11 @@
 
 Come accennato nell'introduzione in un sistema Unix tutte le operazioni
 vengono svolte tramite opportuni processi.  In sostanza questi ultimi vengono
-a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema.
+a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema.
 
 Nel precedente capitolo abbiamo esaminato il funzionamento di un processo come
-unità a se stante, in questo esamineremo il funzionamento dei processi
-all'interno del sistema. Saranno cioè affrontati i dettagli della creazione e
+unità a se stante, in questo esamineremo il funzionamento dei processi
+all'interno del sistema. Saranno cioè affrontati i dettagli della creazione e
 della terminazione dei processi, della gestione dei loro attributi e
 privilegi, e di tutte le funzioni a questo connesse. Infine nella sezione
 finale introdurremo alcune problematiche generiche della programmazione in
@@ -39,37 +39,37 @@ gestione.
 \label{sec:proc_hierarchy}
 
 A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la
-generazione di nuovi processi è un'operazione privilegiata) una delle
-caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che
-qualunque processo può a sua volta generarne altri, detti processi figli
-(\textit{child process}). Ogni processo è identificato presso il sistema da un
-numero univoco, il cosiddetto \textit{process identifier} o, più brevemente,
+generazione di nuovi processi è un'operazione privilegiata) una delle
+caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che
+qualunque processo può a sua volta generarne altri, detti processi figli
+(\textit{child process}). Ogni processo è identificato presso il sistema da un
+numero univoco, il cosiddetto \textit{process identifier} o, più brevemente,
 \acr{pid}, assegnato in forma progressiva (vedi sez.~\ref{sec:proc_pid})
 quando il processo viene creato.
 
-Una seconda caratteristica di un sistema Unix è che la generazione di un
-processo è un'operazione separata rispetto al lancio di un programma. In
-genere la sequenza è sempre quella di creare un nuovo processo, il quale
-eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
+Una seconda caratteristica di un sistema Unix è che la generazione di un
+processo è un'operazione separata rispetto al lancio di un programma. In
+genere la sequenza è sempre quella di creare un nuovo processo, il quale
+eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
 quello che fa la shell quando mette in esecuzione il programma che gli
 indichiamo nella linea di comando.
 
-Una terza caratteristica è che ogni processo è sempre stato generato da un
+Una terza caratteristica è che ogni processo è sempre stato generato da un
 altro, che viene chiamato processo padre (\textit{parent process}). Questo
 vale per tutti i processi, con una sola eccezione: dato che ci deve essere un
-punto di partenza esiste un processo speciale (che normalmente è
+punto di partenza esiste un processo speciale (che normalmente è
 \cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase
 di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il
-\acr{pid} uguale a 1 e non è figlio di nessun altro processo.
+\acr{pid} uguale a 1 e non è figlio di nessun altro processo.
 
-Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
+Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
 partire tutti gli altri processi necessari al funzionamento del sistema,
-inoltre \cmd{init} è essenziale per svolgere una serie di compiti
+inoltre \cmd{init} è essenziale per svolgere una serie di compiti
 amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di
-essi in sez.~\ref{sec:proc_termination}) e non può mai essere terminato. La
+essi in sez.~\ref{sec:proc_termination}) e non può mai essere terminato. La
 struttura del sistema comunque consente di lanciare al posto di \cmd{init}
 qualunque altro programma, e in casi di emergenza (ad esempio se il file di
-\cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
+\cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
 posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio.
 
 \begin{figure}[!htb]
@@ -108,22 +108,22 @@ init-+-keventd
      |-snort
      `-wwwoffled
 \end{verbatim} %$
-  \caption{L'albero dei processi, così come riportato dal comando
+  \caption{L'albero dei processi, così come riportato dal comando
     \cmd{pstree}.}
   \label{fig:proc_tree}
 \end{figure}
 
 Dato che tutti i processi attivi nel sistema sono comunque generati da
-\cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
+\cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
   vero, in Linux ci sono alcuni processi speciali che pur comparendo come
-  figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
+  figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
   direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, ecc.).} si
 possono classificare i processi con la relazione padre/figlio in
 un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
 organizzati in un albero di directory (si veda
-sez.~\ref{sec:file_organization}); in fig.~\ref{fig:proc_tree} si è mostrato il
+sez.~\ref{sec:file_organization}); in fig.~\ref{fig:proc_tree} si è mostrato il
 risultato del comando \cmd{pstree} che permette di visualizzare questa
-struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
+struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
 processi.
 
 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
@@ -133,7 +133,7 @@ tabella dei processi che contiene tutte le informazioni rilevanti per quel
 processo. Tutte le strutture usate a questo scopo sono dichiarate nell'header
 file \file{linux/sched.h}, ed uno schema semplificato, che riporta la
 struttura delle principali informazioni contenute nella \struct{task\_struct}
-(che in seguito incontreremo a più riprese), è mostrato in
+(che in seguito incontreremo a più riprese), è mostrato in
 fig.~\ref{fig:proc_task_struct}.
 
 \begin{figure}[htb]
@@ -144,36 +144,36 @@ fig.~\ref{fig:proc_task_struct}.
   \label{fig:proc_task_struct}
 \end{figure}
 
-% TODO la task_struct è cambiata per qualche dettaglio vedi anche
+% TODO la task_struct è cambiata per qualche dettaglio vedi anche
 % http://www.ibm.com/developerworks/linux/library/l-linux-process-management/
 % TODO completare la parte su quando viene chiamato lo scheduler.
 
-Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
+Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
 \textit{scheduler} che decide quale processo mettere in esecuzione; esso viene
-eseguito ad ogni system call ed ad ogni interrupt,\footnote{più in una serie
-  di altre occasioni.} ma può essere anche attivato esplicitamente. Il timer
+eseguito ad ogni system call ed ad ogni interrupt,\footnote{più in una serie
+  di altre occasioni.} ma può essere anche attivato esplicitamente. Il timer
 di sistema provvede comunque a che esso sia invocato periodicamente; generando
 un interrupt periodico secondo la frequenza specificata dalla costante
 \const{HZ},\footnote{fino al kernel 2.4 il valore di \const{HZ} era 100 su
-  tutte le architetture tranne l'alpha, per cui era 1000, nel 2.6 è stato
-  portato a 1000 su tutte; dal 2.6.13 lo si può impostare in fase di
+  tutte le architetture tranne l'alpha, per cui era 1000, nel 2.6 è stato
+  portato a 1000 su tutte; dal 2.6.13 lo si può impostare in fase di
   compilazione del kernel, con un default di 250 e valori possibili di 100,
-  250, 1000 e dal 2.6.20 anche 300 (che è divisibile per le frequenze di
+  250, 1000 e dal 2.6.20 anche 300 (che è divisibile per le frequenze di
   refresh della televisione); occorre fare attenzione a non confondere questo
   valore con quello dei \itindex{clock~tick} \textit{clock tick} (vedi
   sez.~\ref{sec:sys_unix_time}).} definita in \file{asm/param.h}, ed il cui
-valore è espresso in Hertz.\footnote{a partire dal kernel 2.6.21 è stato
+valore è espresso in Hertz.\footnote{a partire dal kernel 2.6.21 è stato
   introdotto (a cura di Ingo Molnar) un meccanismo completamente diverso,
-  detto \textit{tickless}, in cui non c'è più una interruzione periodica con
+  detto \textit{tickless}, in cui non c'è più una interruzione periodica con
   frequenza prefissata, ma ad ogni chiamata del timer viene programmata
   l'interruzione successiva sulla base di una stima; in questo modo si evita
   di dover eseguire un migliaio di interruzioni al secondo anche su macchine
   che non stanno facendo nulla, con un forte risparmio nell'uso dell'energia
-  da parte del processore che può essere messo in stato di sospensione anche
+  da parte del processore che può essere messo in stato di sospensione anche
   per lunghi periodi di tempo.}
 
 Ogni volta che viene eseguito, lo \itindex{scheduler} \textit{scheduler}
-effettua il calcolo delle priorità dei vari processi attivi (torneremo su
+effettua il calcolo delle priorità dei vari processi attivi (torneremo su
 questo in sez.~\ref{sec:proc_priority}) e stabilisce quale di essi debba
 essere posto in esecuzione fino alla successiva invocazione.
 
@@ -183,7 +183,7 @@ essere posto in esecuzione fino alla successiva invocazione.
 
 Tradizionalmente in un sistema unix-like i processi vengono sempre creati da
 altri processi tramite la funzione \func{fork}; il nuovo processo (che viene
-chiamato \textsl{figlio}) creato dalla \func{fork} è una copia identica del
+chiamato \textsl{figlio}) creato dalla \func{fork} è una copia identica del
 processo processo originale (detto \textsl{padre}), ma ha un nuovo \acr{pid} e
 viene eseguito in maniera indipendente (le differenze fra padre e figlio sono
 affrontate in dettaglio in sez.~\ref{sec:proc_fork}).
@@ -195,25 +195,25 @@ sez.~\ref{sec:proc_wait}); queste funzioni restituiscono anche un'informazione
 abbastanza limitata sulle cause della terminazione del processo figlio.
 
 Quando un processo ha concluso il suo compito o ha incontrato un errore non
-risolvibile esso può essere terminato con la funzione \func{exit} (si veda
-quanto discusso in sez.~\ref{sec:proc_conclusion}). La vita del processo però
+risolvibile esso può essere terminato con la funzione \func{exit} (si veda
+quanto discusso in sez.~\ref{sec:proc_conclusion}). La vita del processo però
 termina completamente solo quando la notifica della sua conclusione viene
 ricevuta dal processo padre, a quel punto tutte le risorse allocate nel
 sistema ad esso associate vengono rilasciate.
 
-Avere due processi che eseguono esattamente lo stesso codice non è molto
+Avere due processi che eseguono esattamente lo stesso codice non è molto
 utile, normalmente si genera un secondo processo per affidargli l'esecuzione
-di un compito specifico (ad esempio gestire una connessione dopo che questa è
+di un compito specifico (ad esempio gestire una connessione dopo che questa è
 stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
 quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
-coi processi che è la \func{exec}.
+coi processi che è la \func{exec}.
 
 Il programma che un processo sta eseguendo si chiama immagine del processo (o
 \textit{process image}), le funzioni della famiglia \func{exec} permettono di
 caricare un altro programma da disco sostituendo quest'ultimo all'immagine
-corrente; questo fa sì che l'immagine precedente venga completamente
+corrente; questo fa sì che l'immagine precedente venga completamente
 cancellata. Questo significa che quando il nuovo programma termina, anche il
-processo termina, e non si può tornare alla precedente immagine.
+processo termina, e non si può tornare alla precedente immagine.
 
 Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
 particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
@@ -237,25 +237,25 @@ programmi.
 
 Come accennato nell'introduzione, ogni processo viene identificato dal sistema
 da un numero identificativo univoco, il \textit{process ID} o \acr{pid};
-quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
-intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
+quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
+intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
 \ctyp{int}).
 
 Il \acr{pid} viene assegnato in forma progressiva\footnote{in genere viene
   assegnato il numero successivo a quello usato per l'ultimo processo creato,
-  a meno che questo numero non sia già utilizzato per un altro \acr{pid},
+  a meno che questo numero non sia già utilizzato per un altro \acr{pid},
   \acr{pgid} o \acr{sid} (vedi sez.~\ref{sec:sess_proc_group}).} ogni volta
 che un nuovo processo viene creato, fino ad un limite che, essendo il
 \acr{pid} un numero positivo memorizzato in un intero a 16 bit, arriva ad un
-massimo di 32768.  Oltre questo valore l'assegnazione riparte dal numero più
+massimo di 32768.  Oltre questo valore l'assegnazione riparte dal numero più
 basso disponibile a partire da un minimo di 300,\footnote{questi valori, fino
   al kernel 2.4.x, sono definiti dalla macro \const{PID\_MAX} in
   \file{threads.h} e direttamente in \file{fork.c}, con il kernel 2.5.x e la
   nuova interfaccia per i \itindex{thread} \textit{thread} creata da Ingo
-  Molnar anche il meccanismo di allocazione dei \acr{pid} è stato modificato;
-  il valore massimo è impostabile attraverso il file
+  Molnar anche il meccanismo di allocazione dei \acr{pid} è stato modificato;
+  il valore massimo è impostabile attraverso il file
   \procfile{/proc/sys/kernel/pid\_max} e di default vale 32768.} che serve a
-riservare i \acr{pid} più bassi ai processi eseguiti direttamente dal kernel.
+riservare i \acr{pid} più bassi ai processi eseguiti direttamente dal kernel.
 Per questo motivo, come visto in sez.~\ref{sec:proc_hierarchy}, il processo di
 avvio (\cmd{init}) ha sempre il \acr{pid} uguale a uno.
 
@@ -282,13 +282,13 @@ fig.~\ref{fig:proc_fork_code}, nel programma \file{ForkTest.c}.
 
 Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un
 candidato per generare ulteriori indicatori associati al processo di cui
-diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
+diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
 funzione \func{tempnam} (si veda sez.~\ref{sec:file_temp_file}) usa il
 \acr{pid} per generare un \itindex{pathname} \textit{pathname} univoco, che
-non potrà essere replicato da un altro processo che usi la stessa funzione.
+non potrà essere replicato da un altro processo che usi la stessa funzione.
 
 Tutti i processi figli dello stesso processo padre sono detti
-\textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
+\textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
   sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
 cap.~\ref{cha:session}, dove esamineremo gli altri identificativi associati ad
@@ -298,28 +298,28 @@ sessione.
 Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in
 sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione), ad ogni
 processo vengono associati degli altri identificatori che vengono usati per il
-controllo di accesso.  Questi servono per determinare se un processo può
+controllo di accesso.  Questi servono per determinare se un processo può
 eseguire o meno le operazioni richieste, a seconda dei privilegi e
-dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
+dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
 affrontato in dettaglio in sez.~\ref{sec:proc_perms}.
 
 
 \subsection{La funzione \func{fork} e le funzioni di creazione dei processi}
 \label{sec:proc_fork}
 
-La funzione \funcd{fork} è la funzione fondamentale della gestione dei
-processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
-processo era attraverso l'uso di questa funzione,\footnote{in realtà oggi la
-  system call usata più comunemente da Linux per creare nuovi processi è
-  \func{clone} (vedi \ref{sec:process_clone}) , anche perché a partire dalle
-  \acr{glibc} 2.3.3 non viene più usata la system call originale, ma la stessa
+La funzione \funcd{fork} è la funzione fondamentale della gestione dei
+processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
+processo era attraverso l'uso di questa funzione,\footnote{in realtà oggi la
+  system call usata più comunemente da Linux per creare nuovi processi è
+  \func{clone} (vedi \ref{sec:process_clone}) , anche perché a partire dalle
+  \acr{glibc} 2.3.3 non viene più usata la system call originale, ma la stessa
   \func{fork} viene implementata tramite \func{clone}, cosa che consente una
   migliore interazione coi \textit{thread}.} essa quindi riveste un ruolo
 centrale tutte le volte che si devono scrivere programmi che usano il
 multitasking.\footnote{oggi questa rilevanza, con la diffusione dell'uso dei
-  \textit{thread} che tratteremo al cap.~\ref{cha:threads}, è in parte minore,
+  \textit{thread} che tratteremo al cap.~\ref{cha:threads}, è in parte minore,
   ma \func{fork} resta comunque la funzione principale per la creazione di
-  processi.} Il prototipo della funzione è:
+  processi.} Il prototipo della funzione è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{unistd.h} 
@@ -328,49 +328,49 @@ multitasking.\footnote{oggi questa rilevanza, con la diffusione dell'uso dei
   
   \bodydesc{In caso di successo restituisce il \acr{pid} del figlio al padre e
     zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di
-    errore; \var{errno} può assumere i valori:
+    errore; \var{errno} può assumere i valori:
   \begin{errlist}
   \item[\errcode{EAGAIN}] non ci sono risorse sufficienti per creare un altro
     processo (per allocare la tabella delle pagine e le strutture del task) o
-    si è esaurito il numero di processi disponibili.
-  \item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le
+    si è esaurito il numero di processi disponibili.
+  \item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le
     strutture necessarie al kernel per creare il nuovo processo.
   \end{errlist}}
 \end{functions}
 
 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
 il processo figlio continuano ad essere eseguiti normalmente a partire
-dall'istruzione successiva alla \func{fork}; il processo figlio è però una
+dall'istruzione successiva alla \func{fork}; il processo figlio è però una
 copia del padre, e riceve una copia dei \index{segmento!testo} segmenti di
 testo, \itindex{stack} \textit{stack} e \index{segmento!dati} dati (vedi
 sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
-padre. Si tenga presente però che la memoria è copiata, non condivisa,
+padre. Si tenga presente però che la memoria è copiata, non condivisa,
 pertanto padre e figlio vedono variabili diverse.
 
 Per quanto riguarda la gestione della memoria, in generale il
-\index{segmento!testo} segmento di testo, che è identico per i due processi, è
+\index{segmento!testo} segmento di testo, che è identico per i due processi, è
 condiviso e tenuto in read-only per il padre e per i figli. Per gli altri
 segmenti Linux utilizza la tecnica del \itindex{copy~on~write} \textit{copy on
   write}; questa tecnica comporta che una pagina di memoria viene
 effettivamente copiata per il nuovo processo solo quando ci viene effettuata
 sopra una scrittura (e si ha quindi una reale differenza fra padre e figlio).
-In questo modo si rende molto più efficiente il meccanismo della creazione di
-un nuovo processo, non essendo più necessaria la copia di tutto lo spazio
+In questo modo si rende molto più efficiente il meccanismo della creazione di
+un nuovo processo, non essendo più necessaria la copia di tutto lo spazio
 degli indirizzi virtuali del padre, ma solo delle pagine di memoria che sono
 state modificate, e solo al momento della modifica stessa.
 
-La differenza che si ha nei due processi è che nel processo padre il valore di
-ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
-nel figlio è zero; in questo modo il programma può identificare se viene
+La differenza che si ha nei due processi è che nel processo padre il valore di
+ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
+nel figlio è zero; in questo modo il programma può identificare se viene
 eseguito dal padre o dal figlio.  Si noti come la funzione \func{fork} ritorni
 \textbf{due} volte: una nel padre e una nel figlio. 
 
-La scelta di questi valori di ritorno non è casuale, un processo infatti può
-avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
+La scelta di questi valori di ritorno non è casuale, un processo infatti può
+avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
 permette di identificare quello appena creato; al contrario un figlio ha
-sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
+sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
 \func{getppid}, vedi sez.~\ref{sec:proc_pid}) per cui si usa il valore nullo,
-che non è il \acr{pid} di nessun processo.
+che non è il \acr{pid} di nessun processo.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -382,47 +382,47 @@ che non 
   \label{fig:proc_fork_code}
 \end{figure}
 
-Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
-sono già troppi processi nel sistema (il che di solito è sintomo che
-qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
+Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
+sono già troppi processi nel sistema (il che di solito è sintomo che
+qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
 sul numero totale di processi permessi all'utente (vedi
 sez.~\ref{sec:sys_resource_limit}, ed in particolare
 tab.~\ref{tab:sys_rlimit_values}).
 
-L'uso di \func{fork} avviene secondo due modalità principali; la prima è
+L'uso di \func{fork} avviene secondo due modalità principali; la prima è
 quella in cui all'interno di un programma si creano processi figli cui viene
 affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
-ne esegue un'altra. È il caso tipico dei programmi server (il modello
-\textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}) in cui il
+ne esegue un'altra. È il caso tipico dei programmi server (il modello
+\textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}) in cui il
 padre riceve ed accetta le richieste da parte dei programmi client, per
-ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire
+ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire
 il servizio.
 
-La seconda modalità è quella in cui il processo vuole eseguire un altro
-programma; questo è ad esempio il caso della shell. In questo caso il processo
-crea un figlio la cui unica operazione è quella di fare una \func{exec} (di
+La seconda modalità è quella in cui il processo vuole eseguire un altro
+programma; questo è ad esempio il caso della shell. In questo caso il processo
+crea un figlio la cui unica operazione è quella di fare una \func{exec} (di
 cui parleremo in sez.~\ref{sec:proc_exec}) subito dopo la \func{fork}.
 
 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
-seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
-operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
-scelto di mantenere questa separazione, dato che, come per la prima modalità
-d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
+seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
+operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
+scelto di mantenere questa separazione, dato che, come per la prima modalità
+d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
 aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della
-seconda modalità d'uso, avere le due funzioni separate permette al figlio di
+seconda modalità d'uso, avere le due funzioni separate permette al figlio di
 cambiare gli attributi del processo (maschera dei segnali, redirezione
-dell'output, identificatori) prima della \func{exec}, rendendo così
-relativamente facile intervenire sulle le modalità di esecuzione del nuovo
+dell'output, identificatori) prima della \func{exec}, rendendo così
+relativamente facile intervenire sulle le modalità di esecuzione del nuovo
 programma.
 
-In fig.~\ref{fig:proc_fork_code} è riportato il corpo del codice del programma
+In fig.~\ref{fig:proc_fork_code} è riportato il corpo del codice del programma
 di esempio \cmd{forktest}, che permette di illustrare molte caratteristiche
 dell'uso della funzione \func{fork}. Il programma crea un numero di figli
 specificato da linea di comando, e prende anche alcune opzioni per indicare
 degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
 \func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
 descrizione delle opzioni); il codice completo, compresa la parte che gestisce
-le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
+le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
 distribuito insieme agli altri sorgenti degli esempi su
 \href{http://gapil.truelite.it/gapil_source.tgz}
 {\textsf{http://gapil.truelite.it/gapil\_source.tgz}}.
@@ -435,12 +435,12 @@ suo numero di successione, eventualmente attendere il numero di secondi
 specificato e scrivere un messaggio prima di uscire. Il processo padre invece
 (\texttt{\small 36--38}) stampa un messaggio di creazione, eventualmente
 attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
-alla conclusione del ciclo, prima di uscire, può essere specificato un altro
+alla conclusione del ciclo, prima di uscire, può essere specificato un altro
 periodo di attesa.
 
-Se eseguiamo il comando\footnote{che è preceduto dall'istruzione \code{export
+Se eseguiamo il comando\footnote{che è preceduto dall'istruzione \code{export
     LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche.}
-senza specificare attese (come si può notare in (\texttt{\small 17--19}) i
+senza specificare attese (come si può notare in (\texttt{\small 17--19}) i
 valori predefiniti specificano di non attendere), otterremo come output sul
 terminale:
 \begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
@@ -461,35 +461,35 @@ Go to next child
 \end{Verbatim} 
 %$
 
-Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
-si può dire quale processo fra il padre ed il figlio venga eseguito per primo
-dopo la chiamata a \func{fork}; dall'esempio si può notare infatti come nei
+Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
+si può dire quale processo fra il padre ed il figlio venga eseguito per primo
+dopo la chiamata a \func{fork}; dall'esempio si può notare infatti come nei
 primi due cicli sia stato eseguito per primo il padre (con la stampa del
 \acr{pid} del nuovo processo) per poi passare all'esecuzione del figlio
 (completata con i due avvisi di esecuzione ed uscita), e tornare
 all'esecuzione del padre (con la stampa del passaggio al ciclo successivo),
-mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
+mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
 e poi il padre.
 
-In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
+In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
 \itindex{scheduler} scheduling usato dal kernel, dalla particolare situazione
 in cui si trova la macchina al momento della chiamata, risultando del tutto
-impredicibile.  Eseguendo più volte il programma di prova e producendo un
+impredicibile.  Eseguendo più volte il programma di prova e producendo un
 numero diverso di figli, si sono ottenute situazioni completamente diverse,
-compreso il caso in cui il processo padre ha eseguito più di una \func{fork}
+compreso il caso in cui il processo padre ha eseguito più di una \func{fork}
 prima che uno dei figli venisse messo in esecuzione.
 
-Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
-istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
-essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
-occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
+Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
+istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
+essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
+occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
 rischio di incorrere nelle cosiddette \itindex{race~condition} \textit{race
   condition} (vedi sez.~\ref{sec:proc_race_cond}).
 
-In realtà a partire dal kernel 2.5.2-pre10 il nuovo \itindex{scheduler}
+In realtà a partire dal kernel 2.5.2-pre10 il nuovo \itindex{scheduler}
 \textit{scheduler} di Ingo Molnar esegue sempre per primo il
 figlio;\footnote{i risultati precedenti sono stati ottenuti usando un kernel
-  della serie 2.4.}  questa è una ottimizzazione che serve a evitare che il
+  della serie 2.4.}  questa è una ottimizzazione che serve a evitare che il
 padre, effettuando per primo una operazione di scrittura in memoria, attivi il
 meccanismo del \itindex{copy~on~write} \textit{copy on write}. Questa
 operazione infatti potrebbe risultare del tutto inutile qualora il figlio
@@ -501,9 +501,9 @@ indirizzi, rendendo superflua la copia della memoria modificata dal padre.
 % prima il padre per questioni di caching nella CPU
 
 Eseguendo sempre per primo il figlio la \func{exec} verrebbe effettuata subito
-avendo così la certezza che il \itindex{copy~on~write} \textit{copy on write}
+avendo così la certezza che il \itindex{copy~on~write} \textit{copy on write}
 viene utilizzato solo quando necessario. Quanto detto in precedenza vale
-allora soltanto per i kernel fino al 2.4; per mantenere la portabilità è però
+allora soltanto per i kernel fino al 2.4; per mantenere la portabilità è però
 opportuno non fare affidamento su questo comportamento, che non si riscontra
 in altri Unix e nelle versioni del kernel precedenti a quella indicata.
 
@@ -514,10 +514,10 @@ a loro (ogni processo vede solo la propria copia della memoria), e non hanno
 alcun effetto sul valore che le stesse variabili hanno nel processo padre (ed
 in eventuali altri processi figli che eseguano lo stesso codice).
 
-Un secondo aspetto molto importante nella creazione dei processi figli è
+Un secondo aspetto molto importante nella creazione dei processi figli è
 quello dell'interazione dei vari processi con i file; per illustrarlo meglio
 proviamo a redirigere su un file l'output del nostro programma di test, quello
-che otterremo è:
+che otterremo è:
 \begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
 [piccardi@selidor sources]$ ./forktest 3 > output
 [piccardi@selidor sources]$ cat output
@@ -544,9 +544,9 @@ Go to next child
 Spawned 3 child, pid 1970 
 Go to next child 
 \end{Verbatim}
-che come si vede è completamente diverso da quanto ottenevamo sul terminale.
+che come si vede è completamente diverso da quanto ottenevamo sul terminale.
 
-Il comportamento delle varie funzioni di interfaccia con i file è analizzato
+Il comportamento delle varie funzioni di interfaccia con i file è analizzato
 in gran dettaglio in cap.~\ref{cha:file_unix_interface} e in
 cap.~\ref{cha:files_std_interface}. Qui basta accennare che si sono usate le
 funzioni standard della libreria del C che prevedono l'output bufferizzato; e
@@ -558,68 +558,68 @@ buffer viene scaricato ad ogni carattere di a capo).
 Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il
 buffer veniva scaricato, e le singole righe erano stampate a video subito dopo
 l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura
-non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
-ogni figlio riceve una copia della memoria del padre, esso riceverà anche
-quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
-padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
+non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
+ogni figlio riceve una copia della memoria del padre, esso riceverà anche
+quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
+padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
 figlio, troveremo nel file anche tutto quello che il processo padre aveva
 scritto prima della sua creazione. E alla fine del file (dato che in questo
 caso il padre esce per ultimo) troveremo anche l'output completo del padre.
 
 L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
-valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
+valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
 solo processi diversi possono scrivere in contemporanea sullo stesso file
-(l'argomento della condivisione dei file è trattato in dettaglio in
+(l'argomento della condivisione dei file è trattato in dettaglio in
 sez.~\ref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per
-le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
+le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
 i processi figli.
 
-Quello che succede è che quando lo standard output del padre viene rediretto
-come si è fatto nell'esempio, lo stesso avviene anche per tutti i figli; la
+Quello che succede è che quando lo standard output del padre viene rediretto
+come si è fatto nell'esempio, lo stesso avviene anche per tutti i figli; la
 funzione \func{fork} infatti ha la caratteristica di duplicare nei processi
 figli tutti i file descriptor aperti nel processo padre (allo stesso modo in
 cui lo fa la funzione \func{dup}, trattata in sez.~\ref{sec:file_dup}), il che
 comporta che padre e figli condividono le stesse voci della
 \itindex{file~table} \textit{file table} (per la spiegazione di questi termini
-si veda sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente
+si veda sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente
 nel file.
 
-In questo modo se un processo scrive sul file aggiornerà la posizione corrente
+In questo modo se un processo scrive sul file aggiornerà la posizione corrente
 sulla \itindex{file~table} \textit{file table}, e tutti gli altri processi,
 che vedono la stessa \itindex{file~table} \textit{file table}, vedranno il
 nuovo valore. In questo modo si evita, in casi come quello appena mostrato in
 cui diversi processi scrivono sullo stesso file, che l'output successivo di un
-processo vada a sovrapporsi a quello dei precedenti: l'output potrà risultare
+processo vada a sovrapporsi a quello dei precedenti: l'output potrà risultare
 mescolato, ma non ci saranno parti perdute per via di una sovrascrittura.
 
-Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
+Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
 crea un figlio e attende la sua conclusione per proseguire, ed entrambi
-scrivono sullo stesso file; un caso tipico è la shell quando lancia un
+scrivono sullo stesso file; un caso tipico è la shell quando lancia un
 programma, il cui output va sullo standard output.  In questo modo, anche se
-l'output viene rediretto, il padre potrà sempre continuare a scrivere in coda
-a quanto scritto dal figlio in maniera automatica; se così non fosse ottenere
+l'output viene rediretto, il padre potrà sempre continuare a scrivere in coda
+a quanto scritto dal figlio in maniera automatica; se così non fosse ottenere
 questo comportamento sarebbe estremamente complesso necessitando di una
 qualche forma di comunicazione fra i due processi per far riprendere al padre
 la scrittura al punto giusto.
 
-In generale comunque non è buona norma far scrivere più processi sullo stesso
+In generale comunque non è buona norma far scrivere più processi sullo stesso
 file senza una qualche forma di sincronizzazione in quanto, come visto anche
 con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
-una sequenza impredicibile. Per questo le modalità con cui in genere si usano
+una sequenza impredicibile. Per questo le modalità con cui in genere si usano
 i file dopo una \func{fork} sono sostanzialmente due:
 \begin{enumerate*}
 \item Il processo padre aspetta la conclusione del figlio. In questo caso non
-  è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
+  è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
   della posizione corrente dopo eventuali operazioni di lettura e scrittura
-  effettuate dal figlio è automatica.
+  effettuate dal figlio è automatica.
 \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
   ciascuno dei due processi deve chiudere i file che non gli servono una volta
-  che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
+  che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
 \end{enumerate*}
 
 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
-proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
-comune dopo l'esecuzione di una \func{fork} è la seguente:
+proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
+comune dopo l'esecuzione di una \func{fork} è la seguente:
 \begin{itemize*}
 \item i file aperti e gli eventuali flag di \itindex{close-on-exec}
   \textit{close-on-exec} impostati (vedi sez.~\ref{sec:proc_exec} e
@@ -640,13 +640,13 @@ comune dopo l'esecuzione di una \func{fork} 
 \item i segmenti di memoria condivisa agganciati al processo (vedi
   sez.~\ref{sec:ipc_sysv_shm});
 \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
-\item il valori di \textit{nice}, le priorità real-time e le affinità di
+\item il valori di \textit{nice}, le priorità real-time e le affinità di
   processore (vedi sez.~\ref{sec:proc_sched_stand},
   sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
 \item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
 \end{itemize*}
 Le differenze fra padre e figlio dopo la \func{fork} invece sono:\footnote{a
-  parte le ultime quattro, relative a funzionalità specifiche di Linux, le
+  parte le ultime quattro, relative a funzionalità specifiche di Linux, le
   altre sono esplicitamente menzionate dallo standard POSIX.1-2001.}
 \begin{itemize*}
 \item il valore di ritorno di \func{fork};
@@ -671,41 +671,41 @@ Le differenze fra padre e figlio dopo la \func{fork} invece sono:\footnote{a
   sez.~\ref{sec:file_memory_map}) che non vengono ereditate dal figlio;
 \item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:prctl_xxx}) che
   notifica al figlio la terminazione del padre viene cancellata;
-\item il segnale di terminazione del figlio è sempre \const{SIGCHLD} anche
+\item il segnale di terminazione del figlio è sempre \const{SIGCHLD} anche
   qualora nel padre fosse stato modificato (vedi sez.~\ref{sec:process_clone}). 
 \end{itemize*}
 
-Una seconda funzione storica usata per la creazione di un nuovo processo è
-\func{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
-semantica e gli stessi errori; la sola differenza è che non viene creata la
-tabella delle pagine né la struttura dei task per il nuovo processo. Il
-processo padre è posto in attesa fintanto che il figlio non ha eseguito una
-\func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
+Una seconda funzione storica usata per la creazione di un nuovo processo è
+\func{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
+semantica e gli stessi errori; la sola differenza è che non viene creata la
+tabella delle pagine né la struttura dei task per il nuovo processo. Il
+processo padre è posto in attesa fintanto che il figlio non ha eseguito una
+\func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
 memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve
 ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}.
 
-Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
+Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
 \func{fork} comportava anche la copia completa del segmento dati del processo
 padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
 \func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
 venne introdotta in BSD per migliorare le prestazioni.
 
 Dato che Linux supporta il \itindex{copy~on~write} \textit{copy on write} la
-perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
+perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
 funzione, che resta un caso speciale della system call \func{clone} (che
-tratteremo in dettaglio in sez.~\ref{sec:process_clone}) è deprecato; per
+tratteremo in dettaglio in sez.~\ref{sec:process_clone}) è deprecato; per
 questo eviteremo di trattarla ulteriormente.
 
 
 \subsection{La conclusione di un processo}
 \label{sec:proc_termination}
 
-In sez.~\ref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
+In sez.~\ref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
 chiudere un programma, ma dall'interno del programma stesso; avendo a che fare
 con un sistema multitasking resta da affrontare l'argomento dal punto di vista
 di come il sistema gestisce la conclusione dei processi.
 
-Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
+Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
 programma viene terminato in maniera normale: la chiamata di \func{exit} (che
 esegue le funzioni registrate per l'uscita e chiude gli stream), il ritorno
 dalla funzione \func{main} (equivalente alla chiamata di \func{exit}), e la
@@ -713,16 +713,16 @@ chiamata ad \func{\_exit} (che passa direttamente alle operazioni di
 terminazione del processo da parte del kernel).
 
 Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
-modalità di conclusione anomala; queste sono in sostanza due: il programma può
+modalità di conclusione anomala; queste sono in sostanza due: il programma può
 chiamare la funzione \func{abort} per invocare una chiusura anomala, o essere
 terminato da un segnale (torneremo sui segnali in cap.~\ref{cha:signals}).  In
-realtà anche la prima modalità si riconduce alla seconda, dato che
+realtà anche la prima modalità si riconduce alla seconda, dato che
 \func{abort} si limita a generare il segnale \const{SIGABRT}.
 
-Qualunque sia la modalità di conclusione di un processo, il kernel esegue
+Qualunque sia la modalità di conclusione di un processo, il kernel esegue
 comunque una serie di operazioni: chiude tutti i file aperti, rilascia la
-memoria che stava usando, e così via; l'elenco completo delle operazioni
-eseguite alla chiusura di un processo è il seguente:
+memoria che stava usando, e così via; l'elenco completo delle operazioni
+eseguite alla chiusura di un processo è il seguente:
 \begin{itemize*}
 \item tutti i file descriptor sono chiusi;
 \item viene memorizzato lo stato di terminazione del processo;
@@ -730,8 +730,8 @@ eseguite alla chiusura di un processo 
   \cmd{init});
 \item viene inviato il segnale \const{SIGCHLD} al processo padre (vedi
   sez.~\ref{sec:sig_sigchld});
-\item se il processo è un leader di sessione ed il suo terminale di controllo
-  è quello della sessione viene mandato un segnale di \const{SIGHUP} a tutti i
+\item se il processo è un leader di sessione ed il suo terminale di controllo
+  è quello della sessione viene mandato un segnale di \const{SIGHUP} a tutti i
   processi del gruppo di \textit{foreground} e il terminale di controllo viene
   disconnesso (vedi sez.~\ref{sec:sess_ctrl_term});
 \item se la conclusione di un processo rende orfano un \textit{process
@@ -740,44 +740,44 @@ eseguite alla chiusura di un processo 
   (vedi ancora sez.~\ref{sec:sess_ctrl_term}).
 \end{itemize*}
 
-Oltre queste operazioni è però necessario poter disporre di un meccanismo
-ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
+Oltre queste operazioni è però necessario poter disporre di un meccanismo
+ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
 un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
 scelto consiste nel riportare lo stato di terminazione (il cosiddetto
 \textit{termination status}) al processo padre.
 
 Nel caso di conclusione normale, abbiamo visto in
 sez.~\ref{sec:proc_conclusion} che lo stato di uscita del processo viene
-caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
+caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
 valore passato alle funzioni \func{exit} o \func{\_exit} (o dal valore di
 ritorno per \func{main}).  Ma se il processo viene concluso in maniera anomala
-il programma non può specificare nessun \textit{exit status}, ed è il kernel
+il programma non può specificare nessun \textit{exit status}, ed è il kernel
 che deve generare autonomamente il \textit{termination status} per indicare le
 ragioni della conclusione anomala.
 
 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
 quello che contraddistingue lo stato di chiusura del processo e viene
 riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
-sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
+sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
 il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il
 secondo.
 
 La scelta di riportare al padre lo stato di terminazione dei figli, pur
 essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
-alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
-che sia così alla sua conclusione, dato che il padre potrebbe essere già
-terminato; si potrebbe avere cioè quello che si chiama un processo
+alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
+che sia così alla sua conclusione, dato che il padre potrebbe essere già
+terminato; si potrebbe avere cioè quello che si chiama un processo
 \textsl{orfano}. 
 
 Questa complicazione viene superata facendo in modo che il processo orfano
-venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
-termina, il kernel controlla se è il padre di altri processi in esecuzione: in
+venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
+termina, il kernel controlla se è il padre di altri processi in esecuzione: in
 caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
-con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
-avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
+con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
+avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
 cui riportare il suo stato di terminazione.  Come verifica di questo
 comportamento possiamo eseguire il nostro programma \cmd{forktest} imponendo a
-ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
+ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
 \begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
 [piccardi@selidor sources]$ ./forktest -c2 3
 Process 1972: forking 3 child
@@ -794,28 +794,28 @@ Go to next child
 Child 2, parent 1, exiting
 Child 1, parent 1, exiting
 \end{Verbatim}
-come si può notare in questo caso il processo padre si conclude prima dei
+come si può notare in questo caso il processo padre si conclude prima dei
 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
 secondi dopo viene stampato a video anche l'output dei tre figli che
-terminano, e come si può notare in questo caso, al contrario di quanto visto
+terminano, e come si può notare in questo caso, al contrario di quanto visto
 in precedenza, essi riportano 1 come \acr{ppid}.
 
-Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
-perché non è detto che il padre possa ricevere immediatamente lo stato di
-terminazione, quindi il kernel deve comunque conservare una certa quantità di
+Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
+perché non è detto che il padre possa ricevere immediatamente lo stato di
+terminazione, quindi il kernel deve comunque conservare una certa quantità di
 informazioni riguardo ai processi che sta terminando.
 
 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
 memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
 dal processo (vedi sez.~\ref{sec:sys_unix_time}) e lo stato di terminazione,
 mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I
-processi che sono terminati, ma il cui stato di terminazione non è stato
+processi che sono terminati, ma il cui stato di terminazione non è stato
 ancora ricevuto dal padre sono chiamati \index{zombie} \textit{zombie}, essi
 restano presenti nella tabella dei processi ed in genere possono essere
 identificati dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella
 colonna che ne indica lo stato (vedi tab.~\ref{tab:proc_proc_states}). Quando
-il padre effettuerà la lettura dello stato di uscita anche questa
-informazione, non più necessaria, verrà scartata e la terminazione potrà dirsi
+il padre effettuerà la lettura dello stato di uscita anche questa
+informazione, non più necessaria, verrà scartata e la terminazione potrà dirsi
 completamente conclusa.
 
 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
@@ -834,35 +834,35 @@ terminale (prima dello scadere dei 10 secondi) otterremo:
   572 pts/0    R      0:00 ps T
 \end{Verbatim} 
 %$
-e come si vede, dato che non si è fatto nulla per riceverne lo
+e come si vede, dato che non si è fatto nulla per riceverne lo
 stato di terminazione, i tre processi figli sono ancora presenti pur essendosi
 conclusi, con lo stato di \index{zombie} \textit{zombie} e l'indicazione che
 sono stati terminati.
 
-La possibilità di avere degli \index{zombie} \textit{zombie} deve essere
+La possibilità di avere degli \index{zombie} \textit{zombie} deve essere
 tenuta sempre presente quando si scrive un programma che deve essere mantenuto
 in esecuzione a lungo e creare molti figli. In questo caso si deve sempre
 avere cura di far leggere l'eventuale stato di uscita di tutti i figli (in
 genere questo si fa attraverso un apposito \textit{signal handler}, che chiama
 la funzione \func{wait}, vedi sez.~\ref{sec:sig_sigchld} e
-sez.~\ref{sec:proc_wait}).  Questa operazione è necessaria perché anche se gli
+sez.~\ref{sec:proc_wait}).  Questa operazione è necessaria perché anche se gli
 \index{zombie} \textit{zombie} non consumano risorse di memoria o processore,
 occupano comunque una voce nella tabella dei processi, che a lungo andare
 potrebbe esaurirsi.
 
 Si noti che quando un processo adottato da \cmd{init} termina, esso non
-diviene uno \index{zombie} \textit{zombie}; questo perché una delle funzioni
-di \cmd{init} è appunto quella di chiamare la funzione \func{wait} per i
-processi cui fa da padre, completandone la terminazione. Questo è quanto
+diviene uno \index{zombie} \textit{zombie}; questo perché una delle funzioni
+di \cmd{init} è appunto quella di chiamare la funzione \func{wait} per i
+processi cui fa da padre, completandone la terminazione. Questo è quanto
 avviene anche quando, come nel caso del precedente esempio con \cmd{forktest},
 il padre termina con dei figli in stato di \index{zombie} \textit{zombie}:
 alla sua terminazione infatti tutti i suoi figli (compresi gli \index{zombie}
-\textit{zombie}) verranno adottati da \cmd{init}, il quale provvederà a
+\textit{zombie}) verranno adottati da \cmd{init}, il quale provvederà a
 completarne la terminazione.
 
 Si tenga presente infine che siccome gli \index{zombie} \textit{zombie} sono
-processi già usciti, non c'è modo di eliminarli con il comando \cmd{kill};
-l'unica possibilità di cancellarli dalla tabella dei processi è quella di
+processi già usciti, non c'è modo di eliminarli con il comando \cmd{kill};
+l'unica possibilità di cancellarli dalla tabella dei processi è quella di
 terminare il processo che li ha generati, in modo che \cmd{init} possa
 adottarli e provvedere a concluderne la terminazione.
 
@@ -871,77 +871,77 @@ adottarli e provvedere a concluderne la terminazione.
   di uscita}
 \label{sec:proc_wait}
 
-Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
+Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
 consiste nella creazione di programmi di tipo server, in cui un processo
 principale attende le richieste che vengono poi soddisfatte da una serie di
-processi figli. Si è già sottolineato al paragrafo precedente come in questo
+processi figli. Si è già sottolineato al paragrafo precedente come in questo
 caso diventi necessario gestire esplicitamente la conclusione dei figli onde
 evitare di riempire di \index{zombie} \textit{zombie} la tabella dei processi;
 le funzioni deputate a questo compito sono principalmente due, \funcd{wait} e
-\func{waitpid}. La prima, il cui prototipo è:
+\func{waitpid}. La prima, il cui prototipo è:
 \begin{functions}
 \headdecl{sys/types.h}
 \headdecl{sys/wait.h}
 \funcdecl{pid\_t wait(int *status)} 
 
-Sospende il processo corrente finché un figlio non è uscito, o finché un
+Sospende il processo corrente finché un figlio non è uscito, o finché un
 segnale termina il processo o chiama una funzione di gestione. 
 
 \bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo
-  e -1 in caso di errore; \var{errno} può assumere i valori:
+  e -1 in caso di errore; \var{errno} può assumere i valori:
   \begin{errlist}
-  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
   \end{errlist}}
 \end{functions}
 \noindent
-è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un
-processo figlio termina. Se un figlio è già terminato la funzione ritorna
-immediatamente, se più di un figlio è terminato occorre chiamare la funzione
-più volte se si vuole recuperare lo stato di terminazione di tutti quanti.
+è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un
+processo figlio termina. Se un figlio è già terminato la funzione ritorna
+immediatamente, se più di un figlio è terminato occorre chiamare la funzione
+più volte se si vuole recuperare lo stato di terminazione di tutti quanti.
 
 Al ritorno della funzione lo stato di terminazione del figlio viene salvato
 nella variabile puntata da \param{status} e tutte le risorse del kernel
 relative al processo (vedi sez.~\ref{sec:proc_termination}) vengono rilasciate.
-Nel caso un processo abbia più figli il valore di ritorno (il \acr{pid} del
-figlio) permette di identificare qual è quello che è uscito.
+Nel caso un processo abbia più figli il valore di ritorno (il \acr{pid} del
+figlio) permette di identificare qual è quello che è uscito.
 
 Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna
-all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
+all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
 necessario attendere la conclusione di un processo specifico occorrerebbe
-predisporre un meccanismo che tenga conto dei processi già terminati, e
+predisporre un meccanismo che tenga conto dei processi già terminati, e
 provvedere a ripetere la chiamata alla funzione nel caso il processo cercato
 sia ancora attivo.
 
 Per questo motivo lo standard POSIX.1 ha introdotto la funzione
 \funcd{waitpid} che effettua lo stesso servizio, ma dispone di una serie di
-funzionalità più ampie, legate anche al controllo di sessione (si veda
-sez.~\ref{sec:sess_job_control}).  Dato che è possibile ottenere lo stesso
+funzionalità più ampie, legate anche al controllo di sessione (si veda
+sez.~\ref{sec:sess_job_control}).  Dato che è possibile ottenere lo stesso
 comportamento di \func{wait}\footnote{in effetti il codice
-  \code{wait(\&status)} è del tutto equivalente a \code{waitpid(WAIT\_ANY,
+  \code{wait(\&status)} è del tutto equivalente a \code{waitpid(WAIT\_ANY,
     \&status, 0)}.} si consiglia di utilizzare sempre questa funzione, il cui
-prototipo è:
+prototipo è:
 \begin{functions}
 \headdecl{sys/types.h}
 \headdecl{sys/wait.h}
 \funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)} 
 Attende la conclusione di un processo figlio.
 
-\bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
-  è stata specificata l'opzione \const{WNOHANG} e il processo non è uscito e
-  -1 per un errore, nel qual caso \var{errno} assumerà i valori:
+\bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
+  è stata specificata l'opzione \const{WNOHANG} e il processo non è uscito e
+  -1 per un errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
-  \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
-    la funzione è stata interrotta da un segnale.
+  \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
+    la funzione è stata interrotta da un segnale.
   \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
-    non è figlio del processo chiamante.
-  \item[\errcode{EINVAL}] si è specificato un valore non valido per
+    non è figlio del processo chiamante.
+  \item[\errcode{EINVAL}] si è specificato un valore non valido per
     l'argomento \param{options}.
   \end{errlist}}
 \end{functions}
 
-La prima differenza fra le due funzioni è che con \func{waitpid} si può
+La prima differenza fra le due funzioni è che con \func{waitpid} si può
 specificare in maniera flessibile quale processo attendere, sulla base del
-valore fornito dall'argomento \param{pid}, questo può assumere diversi valori,
+valore fornito dall'argomento \param{pid}, questo può assumere diversi valori,
 secondo lo specchietto riportato in tab.~\ref{tab:proc_waidpid_pid}, dove si
 sono riportate anche le costanti definite per indicare alcuni di essi.
 
@@ -955,16 +955,16 @@ sono riportate anche le costanti definite per indicare alcuni di essi.
     \hline
     $<-1$& --               & Attende per un figlio il cui
                               \itindex{process~group} \textit{process group}
-                              (vedi sez.~\ref{sec:sess_proc_group}) è uguale
+                              (vedi sez.~\ref{sec:sess_proc_group}) è uguale
                               al valore assoluto di \param{pid}. \\ 
     $-1$&\const{WAIT\_ANY}  & Attende per un figlio qualsiasi, usata in
                               questa maniera senza specificare nessuna opzione
-                              è equivalente a \func{wait}.\\ 
+                              è equivalente a \func{wait}.\\ 
     $ 0$&\const{WAIT\_MYPGRP}&Attende per un figlio il cui
                               \itindex{process~group} \textit{process group}
-                              (vedi sez.~\ref{sec:sess_proc_group}) è
+                              (vedi sez.~\ref{sec:sess_proc_group}) è
                               uguale a quello del processo chiamante. \\ 
-    $>0$& --                & Attende per un figlio il cui \acr{pid} è uguale
+    $>0$& --                & Attende per un figlio il cui \acr{pid} è uguale
                               al valore di \param{pid}.\\
     \hline
   \end{tabular}
@@ -973,13 +973,13 @@ sono riportate anche le costanti definite per indicare alcuni di essi.
   \label{tab:proc_waidpid_pid}
 \end{table}
 
-Il comportamento di \func{waitpid} può inoltre essere modificato passando alla
+Il comportamento di \func{waitpid} può inoltre essere modificato passando alla
 funzione delle opportune opzioni tramite l'argomento \param{options}; questo
 deve essere specificato come maschera binaria dei flag riportati nella prima
 parte in tab.~\ref{tab:proc_waitpid_options} che possono essere combinati fra
 loro con un OR aritmetico. Nella seconda parte della stessa tabella si sono
 riportati anche alcuni valori non standard specifici di Linux, che consentono
-un controllo più dettagliato per i processi creati con la system call generica
+un controllo più dettagliato per i processi creati con la system call generica
 \func{clone} (vedi sez.~\ref{sec:process_clone}) usati principalmente per la
 gestione della terminazione dei \itindex{thread} \textit{thread} (vedi
 sez.~\ref{sec:thread_xxx}).
@@ -992,9 +992,9 @@ sez.~\ref{sec:thread_xxx}).
     \textbf{Macro} & \textbf{Descrizione}\\
     \hline
     \hline
-    \const{WNOHANG}   & La funzione ritorna immediatamente anche se non è
+    \const{WNOHANG}   & La funzione ritorna immediatamente anche se non è
                         terminato nessun processo figlio. \\
-    \const{WUNTRACED} & Ritorna anche se un processo figlio è stato fermato. \\
+    \const{WUNTRACED} & Ritorna anche se un processo figlio è stato fermato. \\
     \const{WCONTINUED}& Ritorna anche quando un processo figlio che era stato
                         fermato ha ripreso l'esecuzione.\footnotemark \\
     \hline
@@ -1016,9 +1016,9 @@ sez.~\ref{sec:thread_xxx}).
 
 L'uso dell'opzione \const{WNOHANG} consente di prevenire il blocco della
 funzione qualora nessun figlio sia uscito (o non si siano verificate le altre
-condizioni per l'uscita della funzione); in tal caso la funzione ritornerà un
-valore nullo anziché positivo.\footnote{anche in questo caso un valore
-  positivo indicherà il \acr{pid} del processo di cui si è ricevuto lo stato
+condizioni per l'uscita della funzione); in tal caso la funzione ritornerà un
+valore nullo anziché positivo.\footnote{anche in questo caso un valore
+  positivo indicherà il \acr{pid} del processo di cui si è ricevuto lo stato
   ed un valore negativo un errore.}
 
 Le altre due opzioni \const{WUNTRACED} e \const{WCONTINUED} consentono
@@ -1028,27 +1028,27 @@ gestione del controllo di sessione (vedi sez.~\ref{sec:sess_job_control}).
 
 Nel caso di \const{WUNTRACED} la funzione ritorna, restituendone il \acr{pid},
 quando un processo figlio entra nello stato \textit{stopped}\footnote{in
-  realtà viene notificato soltanto il caso in cui il processo è stato fermato
+  realtà viene notificato soltanto il caso in cui il processo è stato fermato
   da un segnale di stop (vedi sez.~\ref{sec:sess_ctrl_term}), e non quello in
-  cui lo stato \textit{stopped} è dovuto all'uso di \func{ptrace} (vedi
+  cui lo stato \textit{stopped} è dovuto all'uso di \func{ptrace} (vedi
   sez.~\ref{sec:xxx_ptrace}).} (vedi tab.~\ref{tab:proc_proc_states}), mentre
 con \const{WCONTINUED} la funzione ritorna quando un processo in stato
 \textit{stopped} riprende l'esecuzione per la ricezione del segnale
-\const{SIGCONT} (l'uso di questi segnali per il controllo di sessione è
+\const{SIGCONT} (l'uso di questi segnali per il controllo di sessione è
 dettagliato in sez.~\ref{sec:sess_ctrl_term}). 
 
-La terminazione di un processo figlio (così come gli altri eventi osservabili
-con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione
-di un programma e può avvenire in un qualunque momento. Per questo motivo,
+La terminazione di un processo figlio (così come gli altri eventi osservabili
+con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione
+di un programma e può avvenire in un qualunque momento. Per questo motivo,
 come accennato nella sezione precedente, una delle azioni prese dal kernel
-alla conclusione di un processo è quella di mandare un segnale di
+alla conclusione di un processo è quella di mandare un segnale di
 \const{SIGCHLD} al padre. L'azione predefinita (si veda
-sez.~\ref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
+sez.~\ref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
 generazione costituisce il meccanismo di comunicazione asincrona con cui il
-kernel avverte il processo padre che uno dei suoi figli è terminato.
+kernel avverte il processo padre che uno dei suoi figli è terminato.
 
-Il comportamento delle funzioni è però cambiato nel passaggio dal kernel 2.4
-al kernel 2.6, quest'ultimo infatti si è adeguato alle prescrizioni dello
+Il comportamento delle funzioni è però cambiato nel passaggio dal kernel 2.4
+al kernel 2.6, quest'ultimo infatti si è adeguato alle prescrizioni dello
 standard POSIX.1-2001,\footnote{una revisione del 2001 dello standard POSIX.1
   che ha aggiunto dei requisiti e delle nuove funzioni, come \func{waitid}.}
 e come da esso richiesto se \const{SIGCHLD} viene ignorato, o se si imposta il
@@ -1056,7 +1056,7 @@ flag di \const{SA\_NOCLDSTOP} nella ricezione dello stesso (si veda
 sez.~\ref{sec:sig_sigaction}) i processi figli che terminano non diventano
 \textit{zombie} e sia \func{wait} che \func{waitpid} si bloccano fintanto che
 tutti i processi figli non sono terminati, dopo di che falliscono con un
-errore di \errcode{ENOCHLD}.\footnote{questo è anche il motivo per cui le
+errore di \errcode{ENOCHLD}.\footnote{questo è anche il motivo per cui le
   opzioni \const{WUNTRACED} e \const{WCONTINUED} sono utilizzabili soltanto
   qualora non si sia impostato il flag di \const{SA\_NOCLDSTOP} per il segnale
   \const{SIGCHLD}.}
@@ -1082,31 +1082,31 @@ attendono la terminazione di un processo figlio e ritornano il relativo
     \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
                              stato di uscita del processo (passato attraverso
                              \func{\_exit}, \func{exit} o come valore di
-                             ritorno di \func{main}); può essere valutata solo
+                             ritorno di \func{main}); può essere valutata solo
                              se \val{WIFEXITED} ha restituito un valore non
                              nullo.\\ 
-    \macro{WIFSIGNALED(s)} & Condizione vera se il processo figlio è terminato
+    \macro{WIFSIGNALED(s)} & Condizione vera se il processo figlio è terminato
                              in maniera anomala a causa di un segnale che non
-                             è stato catturato (vedi
+                             è stato catturato (vedi
                              sez.~\ref{sec:sig_notification}).\\ 
     \macro{WTERMSIG(s)}    & Restituisce il numero del segnale che ha causato
-                             la terminazione anomala del processo; può essere
+                             la terminazione anomala del processo; può essere
                              valutata solo se \val{WIFSIGNALED} ha restituito
                              un valore non nullo.\\ 
     \macro{WCOREDUMP(s)}   & Vera se il processo terminato ha generato un
                              file di \itindex{core~dump} \textit{core
-                               dump}; può essere valutata solo se
+                               dump}; può essere valutata solo se
                              \val{WIFSIGNALED} ha restituito un valore non
                              nullo.\footnotemark \\
     \macro{WIFSTOPPED(s)}  & Vera se il processo che ha causato il ritorno di
-                             \func{waitpid} è bloccato; l'uso è possibile solo
+                             \func{waitpid} è bloccato; l'uso è possibile solo
                              con \func{waitpid} avendo specificato l'opzione
                              \const{WUNTRACED}.\\
     \macro{WSTOPSIG(s)}    & Restituisce il numero del segnale che ha bloccato
-                             il processo; può essere valutata solo se
+                             il processo; può essere valutata solo se
                              \val{WIFSTOPPED} ha restituito un valore non
                              nullo. \\ 
-    \macro{WIFCONTINUED(s)}& Vera se il processo che ha causato il ritorno è
+    \macro{WIFCONTINUED(s)}& Vera se il processo che ha causato il ritorno è
                              stato riavviato da un
                              \const{SIGCONT}.\footnotemark  \\ 
     \hline
@@ -1116,31 +1116,31 @@ attendono la terminazione di un processo figlio e ritornano il relativo
   \label{tab:proc_status_macro}
 \end{table}
 
-\footnotetext[20]{questa macro non è definita dallo standard POSIX.1-2001, ma è
+\footnotetext[20]{questa macro non è definita dallo standard POSIX.1-2001, ma è
   presente come estensione sia in Linux che in altri Unix, deve essere
-  pertanto utilizzata con attenzione (ad esempio è il caso di usarla in un
+  pertanto utilizzata con attenzione (ad esempio è il caso di usarla in un
   blocco \texttt{\#ifdef WCOREDUMP ... \#endif}.}
 
-\footnotetext{è presente solo a partire dal kernel 2.6.10.}
+\footnotetext{è presente solo a partire dal kernel 2.6.10.}
 
 In generale in un programma non si vuole essere forzati ad attendere la
 conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto
 questo serve solo per leggerne lo stato di chiusura (ed evitare eventualmente
 la presenza di \index{zombie} \textit{zombie}). 
 
-Per questo la modalità più comune di chiamare queste funzioni è quella di
+Per questo la modalità più comune di chiamare queste funzioni è quella di
 utilizzarle all'interno di un \textit{signal handler} (vedremo un esempio di
 come gestire \const{SIGCHLD} con i segnali in sez.~\ref{sec:sig_example}). In
-questo caso infatti, dato che il segnale è generato dalla terminazione di un
-figlio, avremo la certezza che la chiamata a \func{waitpid} non si bloccherà.
+questo caso infatti, dato che il segnale è generato dalla terminazione di un
+figlio, avremo la certezza che la chiamata a \func{waitpid} non si bloccherà.
 
 Come accennato sia \func{wait} che \func{waitpid} restituiscono lo stato di
 terminazione del processo tramite il puntatore \param{status} (se non
-interessa memorizzare lo stato si può passare un puntatore nullo). Il valore
+interessa memorizzare lo stato si può passare un puntatore nullo). Il valore
 restituito da entrambe le funzioni dipende dall'implementazione, ma
 tradizionalmente alcuni bit (in genere 8) sono riservati per memorizzare lo
 stato di uscita, e altri per indicare il segnale che ha causato la
-terminazione (in caso di conclusione anomala), uno per indicare se è stato
+terminazione (in caso di conclusione anomala), uno per indicare se è stato
 generato un \itindex{core~dump} \textit{core dump}, ecc.\footnote{le
   definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
   questo file non deve mai essere usato direttamente, esso viene incluso
@@ -1154,16 +1154,16 @@ variabile di tipo \ctyp{int} puntata dall'argomento \param{status} restituito
 da \func{wait} o \func{waitpid}.
 
 Si tenga conto che nel caso di conclusione anomala il valore restituito da
-\val{WTERMSIG} può essere confrontato con le costanti che identificano i
+\val{WTERMSIG} può essere confrontato con le costanti che identificano i
 segnali definite in \file{signal.h} ed elencate in
 tab.~\ref{tab:sig_signal_list}, e stampato usando le apposite funzioni
 trattate in sez.~\ref{sec:sig_strsignal}.
 
-A partire dal kernel 2.6.9, sempre in conformità allo standard POSIX.1-2001, è
+A partire dal kernel 2.6.9, sempre in conformità allo standard POSIX.1-2001, è
 stata introdotta una nuova funzione di attesa che consente di avere un
-controllo molto più preciso sui possibili cambiamenti di stato dei processi
-figli e più dettagli sullo stato di uscita; la funzione è \funcd{waitid} ed il
-suo prototipo è:
+controllo molto più preciso sui possibili cambiamenti di stato dei processi
+figli e più dettagli sullo stato di uscita; la funzione è \funcd{waitid} ed il
+suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
 
@@ -1175,13 +1175,13 @@ suo prototipo 
   Attende la conclusione di un processo figlio.
 
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore,
-    nel qual caso \var{errno} assumerà i valori:
+    nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
-  \item[\errcode{EINTR}] se non è stata specificata l'opzione \const{WNOHANG} e
-    la funzione è stata interrotta da un segnale.
+  \item[\errcode{EINTR}] se non è stata specificata l'opzione \const{WNOHANG} e
+    la funzione è stata interrotta da un segnale.
   \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
-    non è figlio del processo chiamante.
-  \item[\errcode{EINVAL}] si è specificato un valore non valido per
+    non è figlio del processo chiamante.
+  \item[\errcode{EINVAL}] si è specificato un valore non valido per
     l'argomento \param{options}.
   \end{errlist}}
 \end{functions}
@@ -1220,14 +1220,14 @@ primo, quale processo o quale gruppo di processi selezionare.
 
 Come per \func{waitpid} anche il comportamento di \func{waitid} viene
 controllato dall'argomento \param{options}, da specificare come maschera
-binaria dei valori riportati in tab.~\ref{tab:proc_waitid_options}. Benché
+binaria dei valori riportati in tab.~\ref{tab:proc_waitid_options}. Benché
 alcuni di questi siano identici come significato ed effetto ai precedenti di
 tab.~\ref{tab:proc_waitpid_options}, ci sono delle differenze significative:
-in questo caso si dovrà specificare esplicitamente l'attesa della terminazione
+in questo caso si dovrà specificare esplicitamente l'attesa della terminazione
 di un processo impostando l'opzione \const{WEXITED}, mentre il precedente
-\const{WUNTRACED} è sostituito da \const{WSTOPPED}.  Infine è stata aggiunta
+\const{WUNTRACED} è sostituito da \const{WSTOPPED}.  Infine è stata aggiunta
 l'opzione \const{WNOWAIT} che consente una lettura dello stato mantenendo il
-processo in attesa di ricezione, così che una successiva chiamata possa di
+processo in attesa di ricezione, così che una successiva chiamata possa di
 nuovo riceverne lo stato.
 
 \begin{table}[!htb]
@@ -1238,13 +1238,13 @@ nuovo riceverne lo stato.
     \textbf{Macro} & \textbf{Descrizione}\\
     \hline
     \hline
-    \const{WEXITED}   & Ritorna quando un processo figlio è terminato.\\
-    \const{WNOHANG}   & Ritorna immediatamente anche se non c'è niente da
+    \const{WEXITED}   & Ritorna quando un processo figlio è terminato.\\
+    \const{WNOHANG}   & Ritorna immediatamente anche se non c'è niente da
                         notificare.\\ 
-    \const{WSTOPPED} &  Ritorna quando un processo figlio è stato fermato.\\
+    \const{WSTOPPED} &  Ritorna quando un processo figlio è stato fermato.\\
     \const{WCONTINUED}& Ritorna quando un processo figlio che era stato
                         fermato ha ripreso l'esecuzione.\\
-    \const{WNOWAIT}   & Lascia il processo ancora in attesa di ricezione, così
+    \const{WNOWAIT}   & Lascia il processo ancora in attesa di ricezione, così
                         che una successiva chiamata possa di nuovo riceverne
                         lo stato.\\
     \hline
@@ -1255,8 +1255,8 @@ nuovo riceverne lo stato.
 \end{table}
 
 La funzione \func{waitid} restituisce un valore nullo in caso di successo, e
-$-1$ in caso di errore; viene restituito un valore nullo anche se è stata
-specificata l'opzione \const{WNOHANG} e la funzione è ritornata immediatamente
+$-1$ in caso di errore; viene restituito un valore nullo anche se è stata
+specificata l'opzione \const{WNOHANG} e la funzione è ritornata immediatamente
 senza che nessun figlio sia terminato. Pertanto per verificare il motivo del
 ritorno della funzione occorre analizzare le informazioni che essa
 restituisce; queste, al contrario delle precedenti \func{wait} e
@@ -1278,7 +1278,7 @@ campi:
 \item[\var{si\_code}] con uno fra \const{CLD\_EXITED}, \const{CLD\_KILLED},
   \const{CLD\_STOPPED}, \const{CLD\_CONTINUED}, \const{CLD\_TRAPPED} e
   \const{CLD\_DUMPED} a indicare la ragione del ritorno della funzione, il cui
-  significato è, nell'ordine: uscita normale, terminazione da segnale,
+  significato è, nell'ordine: uscita normale, terminazione da segnale,
   processo fermato, processo riavviato, processo terminato in \textit{core
     dump}.
 \end{basedescript}
@@ -1286,7 +1286,7 @@ campi:
 Infine Linux, seguendo un'estensione di BSD, supporta altre due funzioni per
 la lettura dello stato di terminazione di un processo, analoghe alle
 precedenti ma che prevedono un ulteriore argomento attraverso il quale il
-kernel può restituire al padre informazioni sulle risorse (vedi
+kernel può restituire al padre informazioni sulle risorse (vedi
 sez.~\ref{sec:sys_res_limits}) usate dal processo terminato e dai vari figli.
 Le due funzioni sono \funcd{wait3} e \funcd{wait4}, che diventano accessibili
 definendo la macro \macro{\_USE\_BSD}; i loro prototipi sono:
@@ -1296,25 +1296,25 @@ definendo la macro \macro{\_USE\_BSD}; i loro prototipi sono:
   
   \funcdecl{pid\_t wait4(pid\_t pid, int *status, int options, struct rusage
     *rusage)}   
-  È identica a \func{waitpid} sia per comportamento che per i valori degli
+  È identica a \func{waitpid} sia per comportamento che per i valori degli
   argomenti, ma restituisce in \param{rusage} un sommario delle risorse usate
   dal processo.
 
   \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
-  Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
+  Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
   ormai deprecata in favore di \func{wait4}.
 \end{functions}
 \noindent 
-la struttura \struct{rusage} è definita in \file{sys/resource.h}, e viene
+la struttura \struct{rusage} è definita in \file{sys/resource.h}, e viene
 utilizzata anche dalla funzione \func{getrusage} (vedi
 sez.~\ref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
-processo; la sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct}.
+processo; la sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct}.
 
 \subsection{La funzione \func{exec} e le funzioni di esecuzione dei programmi}
 \label{sec:proc_exec}
 
-Abbiamo già detto che una delle modalità principali con cui si utilizzano i
-processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
+Abbiamo già detto che una delle modalità principali con cui si utilizzano i
+processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
 processo chiama una di queste funzioni esso viene completamente sostituito dal
 nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
@@ -1323,34 +1323,34 @@ creato un nuovo processo, la funzione semplicemente rimpiazza lo
 \index{segmento!dati} dati ed il \index{segmento!testo} testo del processo
 corrente con un nuovo programma letto da disco.
 
-Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
-famiglia di funzioni) che possono essere usate per questo compito, in realtà
+Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
+famiglia di funzioni) che possono essere usate per questo compito, in realtà
 (come mostrato in fig.~\ref{fig:proc_exec_relat}), sono tutte un front-end a
-\funcd{execve}. Il prototipo di quest'ultima è:
+\funcd{execve}. Il prototipo di quest'ultima è:
 \begin{prototype}{unistd.h}
 {int execve(const char *filename, char *const argv[], char *const envp[])}
   Esegue il programma contenuto nel file \param{filename}.
   
   \bodydesc{La funzione ritorna solo in caso di errore, restituendo -1; nel
-    qual caso \var{errno} può assumere i valori:
+    qual caso \var{errno} può assumere i valori:
   \begin{errlist}
-  \item[\errcode{EACCES}] il file non è eseguibile, oppure il filesystem è
-    montato in \cmd{noexec}, oppure non è un file regolare o un interprete.
+  \item[\errcode{EACCES}] il file non è eseguibile, oppure il filesystem è
+    montato in \cmd{noexec}, oppure non è un file regolare o un interprete.
   \item[\errcode{EPERM}] il file ha i bit \itindex{suid~bit} \acr{suid} o
-    \itindex{sgid~bit} \acr{sgid}, l'utente non è root, il processo viene
-    tracciato, o il filesystem è montato con l'opzione \cmd{nosuid}.
-  \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non
+    \itindex{sgid~bit} \acr{sgid}, l'utente non è root, il processo viene
+    tracciato, o il filesystem è montato con l'opzione \cmd{nosuid}.
+  \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non
     riconosciuto come tale, o compilato per un'altra architettura.
   \item[\errcode{ENOENT}] il file o una delle librerie dinamiche o l'interprete
     necessari per eseguirlo non esistono.
-  \item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più
+  \item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più
     processi. 
-  \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
-    \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
+  \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
+    \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
     interprete.
-  \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
+  \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
     riconoscibile.
-  \item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
+  \item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
   \end{errlist}
   ed inoltre anche \errval{EFAULT}, \errval{ENOMEM}, \errval{EIO},
   \errval{ENAMETOOLONG}, \errval{ELOOP}, \errval{ENOTDIR}, \errval{ENFILE},
@@ -1362,7 +1362,7 @@ La funzione \func{exec} esegue il file o lo script indicato da
 e come ambiente la lista di stringhe indicata da \param{envp}; entrambe le
 liste devono essere terminate da un puntatore nullo. I vettori degli
 argomenti e dell'ambiente possono essere acceduti dal nuovo programma
-quando la sua funzione \func{main} è dichiarata nella forma
+quando la sua funzione \func{main} è dichiarata nella forma
 \code{main(int argc, char *argv[], char *envp[])}.
 
 Le altre funzioni della famiglia servono per fornire all'utente una serie di
@@ -1382,18 +1382,18 @@ argomento. Gli argomenti successivi consentono di specificare gli argomenti a
 linea di comando e l'ambiente ricevuti dal nuovo processo.
 
 \bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo -1;
-  nel qual caso \var{errno} assumerà i valori visti in precedenza per
+  nel qual caso \var{errno} assumerà i valori visti in precedenza per
   \func{execve}.}
 \end{functions}
 
-Per capire meglio le differenze fra le funzioni della famiglia si può fare
+Per capire meglio le differenze fra le funzioni della famiglia si può fare
 riferimento allo specchietto riportato in tab.~\ref{tab:proc_exec_scheme}. La
-prima differenza riguarda le modalità di passaggio dei valori che poi andranno
-a costituire gli argomenti a linea di comando (cioè i valori di
+prima differenza riguarda le modalità di passaggio dei valori che poi andranno
+a costituire gli argomenti a linea di comando (cioè i valori di
 \param{argv} e \param{argc} visti dalla funzione \func{main} del programma
 chiamato).
 
-Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
+Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
 gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
 stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
@@ -1404,7 +1404,7 @@ lista di puntatori, nella forma:
 \includecodesnip{listati/char_list.c}
 che deve essere terminata da un puntatore nullo.  In entrambi i casi vale la
 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
-per indicare il nome del file che contiene il programma che verrà eseguito.
+per indicare il nome del file che contiene il programma che verrà eseguito.
 
 \begin{table}[!htb]
   \footnotesize
@@ -1433,15 +1433,15 @@ per indicare il nome del file che contiene il programma che verr
   \label{tab:proc_exec_scheme}
 \end{table}
 
-La seconda differenza fra le funzioni riguarda le modalità con cui si
+La seconda differenza fra le funzioni riguarda le modalità con cui si
 specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
 indicano le due funzioni che replicano il comportamento della shell nello
 specificare il comando da eseguire; quando l'argomento \param{file} non
 contiene una ``\texttt{/}'' esso viene considerato come un nome di programma,
 e viene eseguita automaticamente una ricerca fra i file presenti nella lista
 di directory specificate dalla variabile di ambiente \var{PATH}. Il file che
-viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
-relativo a permessi di accesso insufficienti (cioè l'esecuzione della
+viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
+relativo a permessi di accesso insufficienti (cioè l'esecuzione della
 sottostante \func{execve} ritorna un \errcode{EACCES}), la ricerca viene
 proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se
 non viene trovato nessun altro file viene finalmente restituito
@@ -1458,7 +1458,7 @@ indicato dall'argomento \param{path}, che viene interpretato come il
   \label{fig:proc_exec_relat}
 \end{figure}
 
-La terza differenza è come viene passata la lista delle variabili di ambiente.
+La terza differenza è come viene passata la lista delle variabili di ambiente.
 Con lo mnemonico \texttt{e} vengono indicate quelle funzioni che necessitano
 di un vettore di parametri \var{envp[]} analogo a quello usato per gli
 argomenti a riga di comando (terminato quindi da un \val{NULL}), le altre
@@ -1467,8 +1467,8 @@ sez.~\ref{sec:proc_environ}) del processo di partenza per costruire
 l'ambiente.
 
 Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
-\func{exec} mantiene la gran parte delle proprietà del processo chiamante; una
-lista delle più significative è la seguente:
+\func{exec} mantiene la gran parte delle proprietà del processo chiamante; una
+lista delle più significative è la seguente:
 \begin{itemize*}
 \item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
   (\acr{ppid});
@@ -1487,16 +1487,16 @@ lista delle pi
 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime};
   \var{tms\_cutime}, \var{tms\_ustime} (vedi sez.~\ref{sec:sys_cpu_times});
 % TODO ===========Importante=============
-% TODO questo sotto è incerto, verificare
+% TODO questo sotto è incerto, verificare
 % TODO ===========Importante=============
 \item la maschera dei segnali (si veda sez.~\ref{sec:sig_sigmask}).
 \end{itemize*}
 
-Una serie di proprietà del processo originale, che non avrebbe senso mantenere
+Una serie di proprietà del processo originale, che non avrebbe senso mantenere
 in un programma che esegue un codice completamente diverso in uno spazio di
 indirizzi totalmente indipendente e ricreato da zero, vengono perse con
 l'esecuzione di \func{exec}; lo standard POSIX.1-2001 prevede che le seguenti
-proprietà non vengano preservate:
+proprietà non vengano preservate:
 \begin{itemize*}
 \item l'insieme dei segnali pendenti (vedi sez.~\ref{sec:sig_gen_beha}), che
   viene cancellato;
@@ -1516,17 +1516,17 @@ propriet
 
 I segnali che sono stati impostati per essere ignorati nel processo chiamante
 mantengono la stessa impostazione pure nel nuovo programma, ma tutti gli altri
-segnali, ed in particolare quelli per i quali è stato installato un gestore
+segnali, ed in particolare quelli per i quali è stato installato un gestore
 vengono impostati alla loro azione predefinita (vedi
-sez.~\ref{sec:sig_gen_beha}). Un caso speciale è il segnale \const{SIGCHLD}
+sez.~\ref{sec:sig_gen_beha}). Un caso speciale è il segnale \const{SIGCHLD}
 che, quando impostato a \const{SIG\_IGN}, potrebbe anche essere reimpostato a
 \const{SIG\_DFL}, anche se questo con Linux non avviene.\footnote{lo standard
   POSIX.1-2001 prevede che questo comportamento sia deciso dalla singola
-  implementazione, quella di Linux è di non modificare l'impostazione
+  implementazione, quella di Linux è di non modificare l'impostazione
   precedente.}
 
 Oltre alle precedenti che sono completamente generali e disponibili anche su
-altri sistemi unix-like, esistono altre proprietà dei processi, attinenti
+altri sistemi unix-like, esistono altre proprietà dei processi, attinenti
 caratteristiche specifiche di Linux, che non vengono preservate
 nell'esecuzione della funzione \func{exec}, queste sono:
 \begin{itemize*}
@@ -1553,19 +1553,19 @@ nell'esecuzione della funzione \func{exec}, queste sono:
 La gestione dei file aperti nel passaggio al nuovo programma lanciato con
 \func{exec} dipende dal valore che ha il flag di \itindex{close-on-exec}
 \textit{close-on-exec} (vedi anche sez.~\ref{sec:file_fcntl}) per ciascun file
-descriptor. I file per cui è impostato vengono chiusi, tutti gli altri file
-restano aperti. Questo significa che il comportamento predefinito è che i file
+descriptor. I file per cui è impostato vengono chiusi, tutti gli altri file
+restano aperti. Questo significa che il comportamento predefinito è che i file
 restano aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
 \func{fcntl} che imposti il suddetto flag.  Per le directory, lo standard
 POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec}, in genere
-questo è fatto dalla funzione \func{opendir} (vedi
+questo è fatto dalla funzione \func{opendir} (vedi
 sez.~\ref{sec:file_dir_read}) che effettua da sola l'impostazione del flag di
 \itindex{close-on-exec} \textit{close-on-exec} sulle directory che apre, in
 maniera trasparente all'utente.
 
 Il comportamento della funzione in relazione agli identificatori relativi al
-controllo di accesso verrà trattato in dettaglio in sez.~\ref{sec:proc_perms},
-qui è sufficiente anticipare (si faccia riferimento a
+controllo di accesso verrà trattato in dettaglio in sez.~\ref{sec:proc_perms},
+qui è sufficiente anticipare (si faccia riferimento a
 sez.~\ref{sec:proc_access_id} per la definizione di questi identificatori)
 come l'\textsl{user-ID reale} ed il \textsl{group-ID reale} restano sempre gli
 stessi, mentre l'\textsl{user-ID salvato} ed il \textsl{group-ID salvato}
@@ -1577,33 +1577,33 @@ impostato, in questo caso l'\textsl{user-ID effettivo} ed il \textsl{group-ID
   effettivo} vengono impostati rispettivamente all'utente o al gruppo cui il
 file appartiene.
 
-Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
+Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
 condivise, viene lanciato il \textit{linker} dinamico \cmd{/lib/ld.so} prima
 del programma per caricare le librerie necessarie ed effettuare il link
-dell'eseguibile.\footnote{il formato è ormai in completo disuso, per cui è
+dell'eseguibile.\footnote{il formato è ormai in completo disuso, per cui è
   molto probabile che non il relativo supporto non sia disponibile.} Se il
-programma è in formato ELF per caricare le librerie dinamiche viene usato
+programma è in formato ELF per caricare le librerie dinamiche viene usato
 l'interprete indicato nel segmento \const{PT\_INTERP} previsto dal formato
-stesso, in genere questo è \sysfile{/lib/ld-linux.so.1} per programmi
+stesso, in genere questo è \sysfile{/lib/ld-linux.so.1} per programmi
 collegati con le \acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi
 collegati con le \acr{glibc}.
 
 Infine nel caso il file sia uno script esso deve iniziare con una linea nella
 forma \cmd{\#!/path/to/interpreter [argomenti]} dove l'interprete indicato
-deve essere un programma valido (binario, non un altro script) che verrà
+deve essere un programma valido (binario, non un altro script) che verrà
 chiamato come se si fosse eseguito il comando \cmd{interpreter [argomenti]
   filename}.\footnote{si tenga presente che con Linux quanto viene scritto
   come \texttt{argomenti} viene passato all'interprete come un unico argomento
   con una unica stringa di lunghezza massima di 127 caratteri e se questa
   dimensione viene ecceduta la stringa viene troncata; altri Unix hanno
   dimensioni massime diverse, e diversi comportamenti, ad esempio FreeBSD
-  esegue la scansione della riga e la divide nei vari argomenti e se è troppo
+  esegue la scansione della riga e la divide nei vari argomenti e se è troppo
   lunga restituisce un errore di \const{ENAMETOOLONG}, una comparazione dei
   vari comportamenti si trova su
   \href{http://www.in-ulm.de/~mascheck/various/shebang/}
   {\textsf{http://www.in-ulm.de/\tild mascheck/various/shebang/}}.}
 
-Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
+Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
 basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
 processo, con \func{exec} si lancia un nuovo programma, con \func{exit} e
 \func{wait} si effettua e verifica la conclusione dei processi. Tutte le
@@ -1626,23 +1626,23 @@ problematiche connesse ad una gestione accorta dei privilegi.
 \label{sec:proc_access_id}
 
 Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in
-  realtà già esistono estensioni di questo modello base, che lo rendono più
+  realtà già esistono estensioni di questo modello base, che lo rendono più
   flessibile e controllabile, come le \itindex{capabilities}
   \textit{capabilities} illustrate in sez.~\ref{sec:proc_capabilities}, le ACL
   per i file (vedi sez.~\ref{sec:file_ACL}) o il
   \itindex{Mandatory~Access~Control~(MAC)} \textit{Mandatory Access Control}
   di \index{SELinux} SELinux; inoltre basandosi sul lavoro effettuato con
-  SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
+  SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
   infrastruttura di sicurezza, i \itindex{Linux~Security~Modules}
   \textit{Linux Security Modules}, o LSM, in grado di fornire diversi agganci
   a livello del kernel per modularizzare tutti i possibili controlli di
-  accesso.} di sicurezza di un sistema unix-like è fondato sui concetti di
+  accesso.} di sicurezza di un sistema unix-like è fondato sui concetti di
 utente e gruppo, e sulla separazione fra l'amministratore (\textsl{root},
-detto spesso anche \textit{superuser}) che non è sottoposto a restrizioni, ed
+detto spesso anche \textit{superuser}) che non è sottoposto a restrizioni, ed
 il resto degli utenti, per i quali invece vengono effettuati i vari controlli
 di accesso.
 
-Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
+Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
 identificatori univoci, lo user-ID ed il group-ID; questi servono al kernel per
 identificare uno specifico utente o un gruppo di utenti, per poi poter
 controllare che essi siano autorizzati a compiere le operazioni richieste.  Ad
@@ -1651,17 +1651,17 @@ associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati
 appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal
 kernel nella gestione dei permessi di accesso.
 
-Dato che tutte le operazioni del sistema vengono compiute dai processi, è
+Dato che tutte le operazioni del sistema vengono compiute dai processi, è
 evidente che per poter implementare un controllo sulle operazioni occorre
-anche poter identificare chi è che ha lanciato un certo programma, e pertanto
-anche a ciascun processo dovrà essere associato un utente e un gruppo.
+anche poter identificare chi è che ha lanciato un certo programma, e pertanto
+anche a ciascun processo dovrà essere associato un utente e un gruppo.
 
 Un semplice controllo di una corrispondenza fra identificativi non garantisce
-però sufficiente flessibilità per tutti quei casi in cui è necessario poter
+però sufficiente flessibilità per tutti quei casi in cui è necessario poter
 disporre di privilegi diversi, o dover impersonare un altro utente per un
 limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix
 prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
-rispettivamente \textit{real} ed \textit{effective} (cioè \textsl{reali} ed
+rispettivamente \textit{real} ed \textit{effective} (cioè \textsl{reali} ed
 \textsl{effettivi}). Nel caso di Linux si aggiungono poi altri due gruppi, il
 \textit{saved} (\textsl{salvati}) ed il \textit{filesystem} (\textsl{di
   filesystem}), secondo la situazione illustrata in
@@ -1690,9 +1690,9 @@ tab.~\ref{tab:proc_uid_gid}.
                 & Indicano gli ulteriori gruppi cui l'utente appartiene.\\ 
     \hline
     --          & \textit{saved} & \textsl{user-ID salvato} 
-                & È una copia dell'\acr{euid} iniziale.\\ 
+                & È una copia dell'\acr{euid} iniziale.\\ 
     --          & '' & \textsl{group-ID salvato} 
-                & È una copia dell'\acr{egid} iniziale.\\ 
+                & È una copia dell'\acr{egid} iniziale.\\ 
     \hline
     \acr{fsuid} & \textit{filesystem} &\textsl{user-ID di filesystem} 
                 & Indica l'utente effettivo per l'accesso al filesystem. \\ 
@@ -1709,9 +1709,9 @@ Al primo gruppo appartengono l'\textsl{user-ID reale} ed il \textsl{group-ID
   reale}: questi vengono impostati al login ai valori corrispondenti
 all'utente con cui si accede al sistema (e relativo gruppo principale).
 Servono per l'identificazione dell'utente e normalmente non vengono mai
-cambiati. In realtà vedremo (in sez.~\ref{sec:proc_setuid}) che è possibile
+cambiati. In realtà vedremo (in sez.~\ref{sec:proc_setuid}) che è possibile
 modificarli, ma solo ad un processo che abbia i privilegi di amministratore;
-questa possibilità è usata proprio dal programma \cmd{login} che, una volta
+questa possibilità è usata proprio dal programma \cmd{login} che, una volta
 completata la procedura di autenticazione, lancia una shell per la quale
 imposta questi identificatori ai valori corrispondenti all'utente che entra
 nel sistema.
@@ -1725,12 +1725,12 @@ sez.~\ref{sec:file_perm_overview}).
 
 Questi identificatori normalmente sono identici ai corrispondenti del gruppo
 \textit{real} tranne nel caso in cui, come accennato in
-sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i
+sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i
 bit \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid} impostati
-(il significato di questi bit è affrontato in dettaglio in
+(il significato di questi bit è affrontato in dettaglio in
 sez.~\ref{sec:file_special_perm}). In questo caso essi saranno impostati
 all'utente e al gruppo proprietari del file. Questo consente, per programmi in
-cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
+cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
 di un altro (o dell'amministratore).
 
 Come nel caso del \acr{pid} e del \acr{ppid}, anche tutti questi
@@ -1755,7 +1755,7 @@ prototipi sono:
   \bodydesc{Queste funzioni non riportano condizioni di errore.}
 \end{functions}
 
-In generale l'uso di privilegi superiori deve essere limitato il più
+In generale l'uso di privilegi superiori deve essere limitato il più
 possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
 un meccanismo che consenta ad un programma di rilasciare gli eventuali
 maggiori privilegi necessari, una volta che si siano effettuate le operazioni
@@ -1763,12 +1763,12 @@ per i quali erano richiesti, e a poterli eventualmente recuperare in caso
 servano di nuovo.
 
 Questo in Linux viene fatto usando altri due gruppi di identificatori, il
-\textit{saved} ed il \textit{filesystem}. Il primo gruppo è lo stesso usato in
-SVr4, e previsto dallo standard POSIX quando è definita la costante
-\macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la portabilità
-  del programma su altri Unix è buona norma controllare sempre la
-  disponibilità di queste funzioni controllando se questa costante è
-  definita.} il secondo gruppo è specifico di Linux e viene usato per
+\textit{saved} ed il \textit{filesystem}. Il primo gruppo è lo stesso usato in
+SVr4, e previsto dallo standard POSIX quando è definita la costante
+\macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la portabilità
+  del programma su altri Unix è buona norma controllare sempre la
+  disponibilità di queste funzioni controllando se questa costante è
+  definita.} il secondo gruppo è specifico di Linux e viene usato per
 migliorare la sicurezza con NFS.
 
 L'\textsl{user-ID salvato} ed il \textsl{group-ID salvato} sono copie
@@ -1781,20 +1781,20 @@ consentono di tenere traccia di quale fossero utente e gruppo effettivi
 all'inizio dell'esecuzione di un nuovo programma.
 
 L'\textsl{user-ID di filesystem} e il \textsl{group-ID di filesystem} sono
-un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
+un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
 (torneremo sull'argomento in sez.~\ref{sec:proc_setuid}). Essi sono una
 replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
 quali si sostituiscono per tutte le operazioni di verifica dei permessi
 relativi ai file (trattate in sez.~\ref{sec:file_perm_overview}).  Ogni
 cambiamento effettuato sugli identificatori effettivi viene automaticamente
-riportato su di essi, per cui in condizioni normali si può tranquillamente
+riportato su di essi, per cui in condizioni normali si può tranquillamente
 ignorarne l'esistenza, in quanto saranno del tutto equivalenti ai precedenti.
 
 
 \subsection{Le funzioni di gestione degli identificatori dei processi}
 \label{sec:proc_setuid}
 
-Le due funzioni più comuni che vengono usate per cambiare identità (cioè
+Le due funzioni più comuni che vengono usate per cambiare identità (cioè
 utente e gruppo di appartenenza) ad un processo sono rispettivamente
 \funcd{setuid} e \funcd{setgid}; come accennato in
 sez.~\ref{sec:proc_access_id} in Linux esse seguono la semantica POSIX che
@@ -1811,16 +1811,16 @@ corrente.
 corrente.
 
 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
-  di fallimento: l'unico errore possibile è \errval{EPERM}.}
+  di fallimento: l'unico errore possibile è \errval{EPERM}.}
 \end{functions}
 
-Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
+Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
 la prima; la seconda si comporta esattamente allo stesso modo facendo
 riferimento al \textsl{group-ID} invece che all'\textsl{user-ID}.  Gli
 eventuali \textsl{group-ID supplementari} non vengono modificati.
 
-L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
-l'\textsl{user-ID effettivo} è zero (cioè è quello dell'amministratore di
+L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
+l'\textsl{user-ID effettivo} è zero (cioè è quello dell'amministratore di
 sistema) allora tutti gli identificatori (\textit{real}, \textit{effective} e
 \textit{saved}) vengono impostati al valore specificato da \param{uid},
 altrimenti viene impostato solo l'\textsl{user-ID effettivo}, e soltanto se il
@@ -1828,7 +1828,7 @@ valore specificato corrisponde o all'\textsl{user-ID reale} o
 all'\textsl{user-ID salvato}. Negli altri casi viene segnalato un errore (con
 \errcode{EPERM}).
 
-Come accennato l'uso principale di queste funzioni è quello di poter
+Come accennato l'uso principale di queste funzioni è quello di poter
 consentire ad un programma con i bit \itindex{suid~bit} \acr{suid} o
 \itindex{sgid~bit} \acr{sgid} impostati (vedi sez.~\ref{sec:file_special_perm})
 di riportare l'\textsl{user-ID effettivo} a quello dell'utente che ha lanciato
@@ -1837,7 +1837,7 @@ ed eventualmente tornare indietro.
 
 Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
 viene gestito l'accesso al file \sysfile{/var/log/utmp}.  In questo file viene
-registrato chi sta usando il sistema al momento corrente; chiaramente non può
+registrato chi sta usando il sistema al momento corrente; chiaramente non può
 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
 falsificare la registrazione. Per questo motivo questo file (e l'analogo
 \sysfile{/var/log/wtmp} su cui vengono registrati login e logout) appartengono
@@ -1847,19 +1847,19 @@ crea terminali multipli su una console) appartengono a questo gruppo ed hanno
 il bit \acr{sgid} impostato.
 
 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
-situazione degli identificatori è la seguente:
+situazione degli identificatori è la seguente:
 \begin{eqnarray*}
   \label{eq:1}
   \textsl{group-ID reale}      &=& \textrm{\acr{gid} (del chiamante)} \\
   \textsl{group-ID effettivo}  &=& \textrm{\acr{utmp}} \\
   \textsl{group-ID salvato}    &=& \textrm{\acr{utmp}}
 \end{eqnarray*}
-in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il
-programma può accedere a \sysfile{/var/log/utmp} in scrittura ed aggiornarlo.
-A questo punto il programma può eseguire una \code{setgid(getgid())} per
+in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il
+programma può accedere a \sysfile{/var/log/utmp} in scrittura ed aggiornarlo.
+A questo punto il programma può eseguire una \code{setgid(getgid())} per
 impostare il \textsl{group-ID effettivo} a quello dell'utente (e dato che il
-\textsl{group-ID reale} corrisponde la funzione avrà successo), in questo modo
-non sarà possibile lanciare dal terminale programmi che modificano detto file,
+\textsl{group-ID reale} corrisponde la funzione avrà successo), in questo modo
+non sarà possibile lanciare dal terminale programmi che modificano detto file,
 in tal caso infatti la situazione degli identificatori sarebbe:
 \begin{eqnarray*}
   \label{eq:2}
@@ -1869,11 +1869,11 @@ in tal caso infatti la situazione degli identificatori sarebbe:
 \end{eqnarray*}
 e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
 \textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo
-aggiornare lo stato di \sysfile{/var/log/utmp} il programma eseguirà una
-\code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
+aggiornare lo stato di \sysfile{/var/log/utmp} il programma eseguirà una
+\code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
 \acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
 in questo caso il valore richiesto corrisponde al \textsl{group-ID salvato} la
-funzione avrà successo e riporterà la situazione a:
+funzione avrà successo e riporterà la situazione a:
 \begin{eqnarray*}
   \label{eq:3}
   \textsl{group-ID reale}      &=& \textrm{\acr{gid} (invariato)}  \\
@@ -1882,11 +1882,11 @@ funzione avr
 \end{eqnarray*}
 consentendo l'accesso a \sysfile{/var/log/utmp}.
 
-Occorre però tenere conto che tutto questo non è possibile con un processo con
+Occorre però tenere conto che tutto questo non è possibile con un processo con
 i privilegi di amministratore, in tal caso infatti l'esecuzione di una
 \func{setuid} comporta il cambiamento di tutti gli identificatori associati al
 processo, rendendo impossibile riguadagnare i privilegi di amministratore.
-Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che
+Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che
 crea una nuova shell per l'utente; ma quando si vuole cambiare soltanto
 l'\textsl{user-ID effettivo} del processo per cedere i privilegi occorre
 ricorrere ad altre funzioni.
@@ -1908,35 +1908,35 @@ specificati da \param{ruid} e \param{euid}.
 specificati da \param{rgid} e \param{egid}.
 
 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
-  di fallimento: l'unico errore possibile è \errval{EPERM}.}
+  di fallimento: l'unico errore possibile è \errval{EPERM}.}
 \end{functions}
 
-La due funzioni sono analoghe ed il loro comportamento è identico; quanto
+La due funzioni sono analoghe ed il loro comportamento è identico; quanto
 detto per la prima riguardo l'user-ID, si applica immediatamente alla seconda
 per il group-ID. I processi non privilegiati possono impostare solo i valori
 del loro user-ID effettivo o reale; valori diversi comportano il fallimento
-della chiamata; l'amministratore invece può specificare un valore qualunque.
-Specificando un argomento di valore -1 l'identificatore corrispondente verrà
+della chiamata; l'amministratore invece può specificare un valore qualunque.
+Specificando un argomento di valore -1 l'identificatore corrispondente verrà
 lasciato inalterato.
 
 Con queste funzioni si possono scambiare fra loro gli user-ID reale e
-effettivo, e pertanto è possibile implementare un comportamento simile a
+effettivo, e pertanto è possibile implementare un comportamento simile a
 quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
 scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un secondo
 scambio.
 
-In questo caso però occorre porre molta attenzione quando si creano nuovi
+In questo caso però occorre porre molta attenzione quando si creano nuovi
 processi nella fase intermedia in cui si sono scambiati gli identificatori, in
-questo caso infatti essi avranno un user-ID reale privilegiato, che dovrà
+questo caso infatti essi avranno un user-ID reale privilegiato, che dovrà
 essere esplicitamente eliminato prima di porre in esecuzione un nuovo
-programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
+programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
 prima della \func{exec} per uniformare l'user-ID reale a quello effettivo) in
 caso contrario il nuovo programma potrebbe a sua volta effettuare uno scambio
 e riottenere privilegi non previsti.
 
 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
 si pone per l'user-ID salvato: questa funzione deriva da un'implementazione che
-non ne prevede la presenza, e quindi non è possibile usarla per correggere la
+non ne prevede la presenza, e quindi non è possibile usarla per correggere la
 situazione come nel caso precedente. Per questo motivo in Linux tutte le volte
 che si imposta un qualunque valore diverso da quello dall'user-ID reale
 corrente, l'user-ID salvato viene automaticamente uniformato al valore
@@ -1957,12 +1957,12 @@ corrente a \param{uid}.
 corrente a \param{gid}.
 
 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
-  di fallimento: l'unico errore è \errval{EPERM}.}
+  di fallimento: l'unico errore è \errval{EPERM}.}
 \end{functions}
 
 Come per le precedenti le due funzioni sono identiche, per cui tratteremo solo
 la prima. Gli utenti normali possono impostare l'user-ID effettivo solo al
-valore dell'user-ID reale o dell'user-ID salvato, l'amministratore può
+valore dell'user-ID reale o dell'user-ID salvato, l'amministratore può
 specificare qualunque valore. Queste funzioni sono usate per permettere
 all'amministratore di impostare solo l'user-ID effettivo, dato che l'uso
 normale di \func{setuid} comporta l'impostazione di tutti gli identificatori.
@@ -1988,14 +1988,14 @@ corrente ai valori specificati rispettivamente da \param{rgid}, \param{egid} e
 \param{sgid}.
 
 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
-  di fallimento: l'unico errore è \errval{EPERM}.}
+  di fallimento: l'unico errore è \errval{EPERM}.}
 \end{functions}
 
 Le due funzioni sono identiche, quanto detto per la prima riguardo gli user-ID
 si applica alla seconda per i group-ID. I processi non privilegiati possono
 cambiare uno qualunque degli user-ID solo ad un valore corrispondente o
 all'user-ID reale, o a quello effettivo o a quello salvato, l'amministratore
-può specificare i valori che vuole; un valore di -1 per un qualunque argomento
+può specificare i valori che vuole; un valore di -1 per un qualunque argomento
 lascia inalterato l'identificatore corrispondente.
 
 Per queste funzioni esistono anche due controparti che permettono di leggere
@@ -2013,13 +2013,13 @@ group-ID reale, il group-ID effettivo e il group-ID salvato del processo
 corrente.
 
 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
-  fallimento: l'unico errore possibile è \errval{EFAULT} se gli indirizzi delle
+  fallimento: l'unico errore possibile è \errval{EFAULT} se gli indirizzi delle
   variabili di ritorno non sono validi.}
 \end{functions}
 
 Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
 nessun privilegio. I valori sono restituiti negli argomenti, che vanno
-specificati come puntatori (è un altro esempio di
+specificati come puntatori (è un altro esempio di
 \itindex{value~result~argument} \textit{value result argument}). Si noti che
 queste funzioni sono le uniche in grado di leggere gli identificatori del
 gruppo \textit{saved}.
@@ -2027,24 +2027,24 @@ gruppo \textit{saved}.
 
 Infine le funzioni \func{setfsuid} e \func{setfsgid} servono per impostare gli
 identificatori del gruppo \textit{filesystem} che sono usati da Linux per il
-controllo dell'accesso ai file.  Come già accennato in
+controllo dell'accesso ai file.  Come già accennato in
 sez.~\ref{sec:proc_access_id} Linux definisce questo ulteriore gruppo di
 identificatori, che in circostanze normali sono assolutamente equivalenti a
 quelli del gruppo \textit{effective}, dato che ogni cambiamento di questi
 ultimi viene immediatamente riportato su di essi.
 
-C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
-identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
+C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
+identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
 ovviare ad un problema di sicurezza che si presenta quando si deve
 implementare un server NFS. 
 
 Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai
-file per assumere l'identità del singolo utente remoto, ma se questo viene
+file per assumere l'identità del singolo utente remoto, ma se questo viene
 fatto cambiando l'user-ID effettivo o l'user-ID reale il server si espone alla
 ricezione di eventuali segnali ostili da parte dell'utente di cui ha
-temporaneamente assunto l'identità.  Cambiando solo l'user-ID di filesystem si
+temporaneamente assunto l'identità.  Cambiando solo l'user-ID di filesystem si
 ottengono i privilegi necessari per accedere ai file, mantenendo quelli
-originari per quanto riguarda tutti gli altri controlli di accesso, così che
+originari per quanto riguarda tutti gli altri controlli di accesso, così che
 l'utente non possa inviare segnali al server NFS.
 
 Le due funzioni usate per cambiare questi identificatori sono \funcd{setfsuid}
@@ -2060,7 +2060,7 @@ processo corrente a \param{fsuid}.
 processo corrente a \param{fsgid}.
 
 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
-  di fallimento: l'unico errore possibile è \errval{EPERM}.}
+  di fallimento: l'unico errore possibile è \errval{EPERM}.}
 \end{functions}
 \noindent queste funzioni hanno successo solo se il processo chiamante ha i
 privilegi di amministratore o, per gli altri utenti, se il valore specificato
@@ -2072,16 +2072,16 @@ coincide con uno dei di quelli del gruppo \textit{real}, \textit{effective} o
 \label{sec:proc_setgroups}
 
 Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
-gruppi supplementari cui un utente può appartenere. Ogni processo può avere
+gruppi supplementari cui un utente può appartenere. Ogni processo può avere
 almeno \const{NGROUPS\_MAX} gruppi supplementari\footnote{il numero massimo di
-  gruppi secondari può essere ottenuto con \func{sysconf} (vedi
+  gruppi secondari può essere ottenuto con \func{sysconf} (vedi
   sez.~\ref{sec:sys_sysconf}), leggendo il parametro
   \texttt{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
 ereditati dal processo padre e possono essere cambiati con queste funzioni.
 
 La funzione che permette di leggere i gruppi supplementari associati ad un
-processo è \funcd{getgroups}; questa funzione è definita nello standard
-POSIX.1, ed il suo prototipo è:
+processo è \funcd{getgroups}; questa funzione è definita nello standard
+POSIX.1, ed il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{unistd.h}
@@ -2091,23 +2091,23 @@ POSIX.1, ed il suo prototipo 
   Legge gli identificatori dei gruppi supplementari.
   
   \bodydesc{La funzione restituisce il numero di gruppi letti in caso di
-    successo e -1 in caso di fallimento, nel qual caso \var{errno} assumerà
+    successo e -1 in caso di fallimento, nel qual caso \var{errno} assumerà
     i valori: 
     \begin{errlist}
     \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
-    \item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma
+    \item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma
       minore del numero di gruppi supplementari del processo.
     \end{errlist}}
 \end{functions}
 
 La funzione legge gli identificatori dei gruppi supplementari del processo sul
-vettore \param{list} di dimensione \param{size}. Non è specificato se la
+vettore \param{list} di dimensione \param{size}. Non è specificato se la
 funzione inserisca o meno nella lista il group-ID effettivo del processo. Se si
 specifica un valore di \param{size} uguale a 0 \param{list} non viene
 modificato, ma si ottiene il numero di gruppi supplementari.
 
-Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per
-ottenere tutti i gruppi a cui appartiene un certo utente; il suo prototipo è:
+Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per
+ottenere tutti i gruppi a cui appartiene un certo utente; il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{grp.h}
@@ -2122,13 +2122,13 @@ ottenere tutti i gruppi a cui appartiene un certo utente; il suo prototipo 
 La funzione legge i gruppi supplementari dell'utente specificato da
 \param{user}, eseguendo una scansione del database dei gruppi (si veda
 sez.~\ref{sec:sys_user_group}). Ritorna poi in \param{groups} la lista di
-quelli a cui l'utente appartiene. Si noti che \param{ngroups} è passato come
-puntatore perché, qualora il valore specificato sia troppo piccolo, la
+quelli a cui l'utente appartiene. Si noti che \param{ngroups} è passato come
+puntatore perché, qualora il valore specificato sia troppo piccolo, la
 funzione ritorna -1, passando indietro il numero dei gruppi trovati.
 
 Per impostare i gruppi supplementari di un processo ci sono due funzioni, che
 possono essere usate solo se si hanno i privilegi di amministratore. La prima
-delle due è \funcd{setgroups}, ed il suo prototipo è:
+delle due è \funcd{setgroups}, ed il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{grp.h}
@@ -2138,23 +2138,23 @@ delle due 
   Imposta i gruppi supplementari del processo.
 
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    fallimento, nel qual caso \var{errno} assumerà i valori:
+    fallimento, nel qual caso \var{errno} assumerà i valori:
     \begin{errlist}
     \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
     \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
-    \item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore
+    \item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore
     massimo consentito.
     \end{errlist}}
 \end{functions}
 
 La funzione imposta i gruppi supplementari del processo corrente ai valori
 specificati nel vettore passato con l'argomento \param{list}, di dimensioni
-date dall'argomento \param{size}. Il numero massimo di gruppi supplementari è
-un parametro di sistema, che può essere ricavato con le modalità spiegate in
+date dall'argomento \param{size}. Il numero massimo di gruppi supplementari è
+un parametro di sistema, che può essere ricavato con le modalità spiegate in
 sez.~\ref{sec:sys_characteristics}.
 
 Se invece si vogliono impostare i gruppi supplementari del processo a quelli di
-un utente specifico, si può usare \funcd{initgroups} il cui prototipo è:
+un utente specifico, si può usare \funcd{initgroups} il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{grp.h}
@@ -2164,31 +2164,31 @@ un utente specifico, si pu
   Inizializza la lista dei gruppi supplementari.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    fallimento, nel qual caso \var{errno} assumerà gli stessi valori di
-    \func{setgroups} più \errval{ENOMEM} quando non c'è memoria sufficiente
+    fallimento, nel qual caso \var{errno} assumerà gli stessi valori di
+    \func{setgroups} più \errval{ENOMEM} quando non c'è memoria sufficiente
     per allocare lo spazio per informazioni dei gruppi.}
 \end{functions}
 
 La funzione esegue la scansione del database dei gruppi (usualmente
-\conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user}
+\conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user}
 con cui costruisce una lista di gruppi supplementari, a cui aggiunge anche
 \param{group}, infine imposta questa lista per il processo corrente usando
 \func{setgroups}.  Si tenga presente che sia \func{setgroups} che
 \func{initgroups} non sono definite nello standard POSIX.1 e che pertanto non
-è possibile utilizzarle quando si definisce \macro{\_POSIX\_SOURCE} o si
-compila con il flag \cmd{-ansi}, è pertanto meglio evitarle se si vuole
+è possibile utilizzarle quando si definisce \macro{\_POSIX\_SOURCE} o si
+compila con il flag \cmd{-ansi}, è pertanto meglio evitarle se si vuole
 scrivere codice portabile.
 
  
-\section{La gestione della priorità dei processi}
+\section{La gestione della priorità dei processi}
 \label{sec:proc_priority}
 
-In questa sezione tratteremo più approfonditamente i meccanismi con il quale
+In questa sezione tratteremo più approfonditamente i meccanismi con il quale
 lo \itindex{scheduler} \textit{scheduler} assegna la CPU ai vari processi
 attivi.  In particolare prenderemo in esame i vari meccanismi con cui viene
 gestita l'assegnazione del tempo di CPU, ed illustreremo le varie funzioni di
-gestione. Tratteremo infine anche le altre priorità dei processi (come quelle
-per l'accesso a disco) divenute disponibili con i kernel più recenti.
+gestione. Tratteremo infine anche le altre priorità dei processi (come quelle
+per l'accesso a disco) divenute disponibili con i kernel più recenti.
 
 
 \subsection{I meccanismi di \textit{scheduling}}
@@ -2197,45 +2197,45 @@ per l'accesso a disco) divenute disponibili con i kernel pi
 \itindbeg{scheduler}
 
 La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
-il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
+il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
 ed oggetto di numerose ricerche; in generale essa dipende in maniera
 essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
 cui non esiste un meccanismo che sia valido per tutti gli usi.
 
-La caratteristica specifica di un sistema multitasking come Linux è quella del
+La caratteristica specifica di un sistema multitasking come Linux è quella del
 cosiddetto \itindex{preemptive~multitasking} \textit{preemptive
   multitasking}: questo significa che al contrario di altri sistemi (che usano
 invece il cosiddetto \itindex{cooperative~multitasking} \textit{cooperative
   multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
 quando la CPU deve essere passata ad un altro processo. Come accennato in
 sez.~\ref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
-apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
+apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
 distribuire al meglio il tempo di CPU fra i vari processi.
 
-La cosa è resa ancora più complicata dal fatto che con le architetture
-multi-processore si deve anche scegliere quale sia la CPU più opportuna da
-utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
+La cosa è resa ancora più complicata dal fatto che con le architetture
+multi-processore si deve anche scegliere quale sia la CPU più opportuna da
+utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
   rendere poco efficiente trasferire l'esecuzione di un processo da una CPU ad
-  un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
+  un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
   banale.}  Tutto questo comunque appartiene alle sottigliezze
 dell'implementazione del kernel; dal punto di vista dei programmi che girano
-in user space, anche quando si hanno più processori (e dei processi che sono
+in user space, anche quando si hanno più processori (e dei processi che sono
 eseguiti davvero in contemporanea), le politiche di scheduling riguardano
 semplicemente l'allocazione della risorsa \textsl{tempo di esecuzione}, la cui
-assegnazione sarà governata dai meccanismi di scelta delle priorità che
+assegnazione sarà governata dai meccanismi di scelta delle priorità che
 restano gli stessi indipendentemente dal numero di processori.
 
 Si tenga conto poi che i processi non devono solo eseguire del codice: ad
 esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
 venire bloccati da un comando dal terminale, o sospesi per un certo periodo di
-tempo.  In tutti questi casi la CPU diventa disponibile ed è compito dello
+tempo.  In tutti questi casi la CPU diventa disponibile ed è compito dello
 kernel provvedere a mettere in esecuzione un altro processo.
 
-Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
-processo, in Linux un processo può trovarsi in uno degli stati riportati in
+Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
+processo, in Linux un processo può trovarsi in uno degli stati riportati in
 tab.~\ref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
 \textbf{Runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
-sia la sua priorità, un processo non potrà mai essere messo in esecuzione
+sia la sua priorità, un processo non potrà mai essere messo in esecuzione
 fintanto che esso si trova in uno qualunque degli altri stati.
 
 \begin{table}[htb]
@@ -2246,77 +2246,77 @@ fintanto che esso si trova in uno qualunque degli altri stati.
     \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
     \hline
     \hline
-    \textbf{Runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
-                                    essere eseguito (cioè è in attesa che gli
+    \textbf{Runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
+                                    essere eseguito (cioè è in attesa che gli
                                     venga assegnata la CPU).\\
-    \textbf{Sleep}   & \texttt{S} & Il processo  è in attesa di un
-                                    risposta dal sistema, ma può essere 
+    \textbf{Sleep}   & \texttt{S} & Il processo  è in attesa di un
+                                    risposta dal sistema, ma può essere 
                                     interrotto da un segnale.\\
-    \textbf{Uninterrutible Sleep}& \texttt{D} & Il  processo è in
+    \textbf{Uninterrutible Sleep}& \texttt{D} & Il  processo è in
                                     attesa di un risposta dal sistema (in 
-                                    genere per I/O), e non può essere
+                                    genere per I/O), e non può essere
                                     interrotto in nessuna circostanza.\\
-    \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
-                                    \const{SIGSTOP}, o è tracciato.\\
-    \textbf{Zombie}\index{zombie} & \texttt{Z} & Il processo è terminato ma il
-                                    suo stato di terminazione non è ancora
+    \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
+                                    \const{SIGSTOP}, o è tracciato.\\
+    \textbf{Zombie}\index{zombie} & \texttt{Z} & Il processo è terminato ma il
+                                    suo stato di terminazione non è ancora
                                     stato letto dal padre.\\
     \textbf{Killable}& \texttt{D} & Un nuovo stato introdotto con il kernel
                                     2.6.25, sostanzialmente identico
                                     all'\textbf{Uninterrutible Sleep} con la
-                                    sola differenza che il processo può
+                                    sola differenza che il processo può
                                     terminato con \const{SIGKILL} (usato per
-                                    lo più per NFS).\\ 
+                                    lo più per NFS).\\ 
     \hline
   \end{tabular}
   \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
-    \texttt{STAT} si è riportata la corrispondente lettera usata dal comando 
+    \texttt{STAT} si è riportata la corrispondente lettera usata dal comando 
     \cmd{ps} nell'omonimo campo.}
   \label{tab:proc_proc_states}
 \end{table}
 
-Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
+Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
 risorse che sono necessarie per l'esecuzione di un programma, e a seconda
-dello scopo del programma non è detto neanche che sia la più importante (molti
-programmi dipendono in maniera molto più critica dall'I/O). Per questo motivo
-non è affatto detto che dare ad un programma la massima priorità di esecuzione
+dello scopo del programma non è detto neanche che sia la più importante (molti
+programmi dipendono in maniera molto più critica dall'I/O). Per questo motivo
+non è affatto detto che dare ad un programma la massima priorità di esecuzione
 abbia risultati significativi in termini di prestazioni.
 
 Il meccanismo tradizionale di scheduling di Unix (che tratteremo in
-sez.~\ref{sec:proc_sched_stand}) è sempre stato basato su delle
-\textsl{priorità dinamiche}, in modo da assicurare che tutti i processi, anche
+sez.~\ref{sec:proc_sched_stand}) è sempre stato basato su delle
+\textsl{priorità dinamiche}, in modo da assicurare che tutti i processi, anche
 i meno importanti, possano ricevere un po' di tempo di CPU. In sostanza quando
-un processo ottiene la CPU la sua priorità viene diminuita. In questo modo
-alla fine, anche un processo con priorità iniziale molto bassa, finisce per
-avere una priorità sufficiente per essere eseguito.
+un processo ottiene la CPU la sua priorità viene diminuita. In questo modo
+alla fine, anche un processo con priorità iniziale molto bassa, finisce per
+avere una priorità sufficiente per essere eseguito.
 
-Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
-  assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
-alla normale priorità dinamica), per tenere conto dei sistemi
+Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
+  assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
+alla normale priorità dinamica), per tenere conto dei sistemi
 real-time,\footnote{per sistema real-time si intende un sistema in grado di
   eseguire operazioni in un tempo ben determinato; in genere si tende a
-  distinguere fra l'\textit{hard real-time} in cui è necessario che i tempi di
+  distinguere fra l'\textit{hard real-time} in cui è necessario che i tempi di
   esecuzione di un programma siano determinabili con certezza assoluta (come
   nel caso di meccanismi di controllo di macchine, dove uno sforamento dei
   tempi avrebbe conseguenze disastrose), e \textit{soft-real-time} in cui un
-  occasionale sforamento è ritenuto accettabile.} in cui è vitale che i
+  occasionale sforamento è ritenuto accettabile.} in cui è vitale che i
 processi che devono essere eseguiti in un determinato momento non debbano
-aspettare la conclusione di altri che non hanno questa necessità.
+aspettare la conclusione di altri che non hanno questa necessità.
 
-Il concetto di priorità assoluta dice che quando due processi si contendono
-l'esecuzione, vince sempre quello con la priorità assoluta più alta.
+Il concetto di priorità assoluta dice che quando due processi si contendono
+l'esecuzione, vince sempre quello con la priorità assoluta più alta.
 Ovviamente questo avviene solo per i processi che sono pronti per essere
-eseguiti (cioè nello stato \textit{runnable}).  La priorità assoluta viene in
-genere indicata con un numero intero, ed un valore più alto comporta una
-priorità maggiore. Su questa politica di scheduling torneremo in
+eseguiti (cioè nello stato \textit{runnable}).  La priorità assoluta viene in
+genere indicata con un numero intero, ed un valore più alto comporta una
+priorità maggiore. Su questa politica di scheduling torneremo in
 sez.~\ref{sec:proc_real_time}.
 
-In generale quello che succede in tutti gli Unix moderni è che ai processi
-normali viene sempre data una priorità assoluta pari a zero, e la decisione di
-assegnazione della CPU è fatta solo con il meccanismo tradizionale della
-priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
-assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
-priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
+In generale quello che succede in tutti gli Unix moderni è che ai processi
+normali viene sempre data una priorità assoluta pari a zero, e la decisione di
+assegnazione della CPU è fatta solo con il meccanismo tradizionale della
+priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
+assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
+priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
 bisogno della CPU.
 
 
@@ -2325,71 +2325,71 @@ bisogno della CPU.
 
 A meno che non si abbiano esigenze specifiche,\footnote{per alcune delle quali
   sono state introdotte delle varianti specifiche.} l'unico meccanismo di
-scheduling con il quale si avrà a che fare è quello tradizionale, che prevede
-solo priorità dinamiche. È di questo che, di norma, ci si dovrà preoccupare
+scheduling con il quale si avrà a che fare è quello tradizionale, che prevede
+solo priorità dinamiche. È di questo che, di norma, ci si dovrà preoccupare
 nella programmazione.  Come accennato in Linux i processi ordinari hanno tutti
-una priorità assoluta nulla; quello che determina quale, fra tutti i processi
-in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta
-\textsl{priorità dinamica},\footnote{quella che viene mostrata nella colonna
-  \texttt{PR} del comando \texttt{top}.} che è chiamata così proprio perché
+una priorità assoluta nulla; quello che determina quale, fra tutti i processi
+in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta
+\textsl{priorità dinamica},\footnote{quella che viene mostrata nella colonna
+  \texttt{PR} del comando \texttt{top}.} che è chiamata così proprio perché
 varia nel corso dell'esecuzione di un processo.
 
-Il meccanismo usato da Linux è in realtà piuttosto complesso,\footnote{e
+Il meccanismo usato da Linux è in realtà piuttosto complesso,\footnote{e
   dipende strettamente dalla versione di kernel; in particolare a partire
-  dalla serie 2.6.x lo scheduler è stato riscritto completamente, con molte
+  dalla serie 2.6.x lo scheduler è stato riscritto completamente, con molte
   modifiche susseguitesi per migliorarne le prestazioni, per un certo periodo
-  ed è stata anche introdotta la possibilità di usare diversi algoritmi,
-  selezionabili sia in fase di compilazione, che, nelle versioni più recenti,
-  all'avvio (addirittura è stato ideato un sistema modulare che permette di
-  cambiare lo scheduler a sistema attivo).} ma a grandi linee si può dire che
-ad ogni processo è assegnata una \textit{time-slice}, cioè un intervallo di
+  ed è stata anche introdotta la possibilità di usare diversi algoritmi,
+  selezionabili sia in fase di compilazione, che, nelle versioni più recenti,
+  all'avvio (addirittura è stato ideato un sistema modulare che permette di
+  cambiare lo scheduler a sistema attivo).} ma a grandi linee si può dire che
+ad ogni processo è assegnata una \textit{time-slice}, cioè un intervallo di
 tempo (letteralmente una fetta) per il quale, a meno di eventi esterni, esso
-viene eseguito senza essere interrotto.  Inoltre la priorità dinamica viene
+viene eseguito senza essere interrotto.  Inoltre la priorità dinamica viene
 calcolata dallo scheduler a partire da un valore iniziale che viene
-\textsl{diminuito} tutte le volte che un processo è in stato \textbf{Runnable}
-ma non viene posto in esecuzione.\footnote{in realtà il calcolo della priorità
+\textsl{diminuito} tutte le volte che un processo è in stato \textbf{Runnable}
+ma non viene posto in esecuzione.\footnote{in realtà il calcolo della priorità
   dinamica e la conseguente scelta di quale processo mettere in esecuzione
-  avviene con un algoritmo molto più complicato, che tiene conto anche della
-  \textsl{interattività} del processo, utilizzando diversi fattori, questa è
+  avviene con un algoritmo molto più complicato, che tiene conto anche della
+  \textsl{interattività} del processo, utilizzando diversi fattori, questa è
   una brutale semplificazione per rendere l'idea del funzionamento, per una
-  trattazione più dettagliata, anche se non aggiornatissima, dei meccanismi di
+  trattazione più dettagliata, anche se non aggiornatissima, dei meccanismi di
   funzionamento dello scheduler si legga il quarto capitolo di
   \cite{LinKernDev}.} Lo scheduler infatti mette sempre in esecuzione, fra
 tutti i processi in stato \textbf{Runnable}, quello che ha il valore di
-priorità dinamica più basso.\footnote{con le priorità dinamiche il significato
-  del valore numerico ad esse associato è infatti invertito, un valore più
-  basso significa una priorità maggiore.} Il fatto che questo valore venga
+priorità dinamica più basso.\footnote{con le priorità dinamiche il significato
+  del valore numerico ad esse associato è infatti invertito, un valore più
+  basso significa una priorità maggiore.} Il fatto che questo valore venga
 diminuito quando un processo non viene posto in esecuzione pur essendo pronto,
-significa che la priorità dei processi che non ottengono l'uso del processore
-viene progressivamente incrementata, così che anche questi alla fine hanno la
-possibilità di essere eseguiti.
+significa che la priorità dei processi che non ottengono l'uso del processore
+viene progressivamente incrementata, così che anche questi alla fine hanno la
+possibilità di essere eseguiti.
 
 Sia la dimensione della \textit{time-slice} che il valore di partenza della
-priorità dinamica sono determinate dalla cosiddetta \textit{nice} (o
-\textit{niceness}) del processo.\footnote{questa è una delle tante proprietà
+priorità dinamica sono determinate dalla cosiddetta \textit{nice} (o
+\textit{niceness}) del processo.\footnote{questa è una delle tante proprietà
   che ciascun processo si porta dietro, essa viene ereditata dai processi
   figli e mantenuta attraverso una \func{exec}; fino alla serie 2.4 essa era
   mantenuta nell'omonimo campo \texttt{nice} della \texttt{task\_struct}, con
   la riscrittura dello scheduler eseguita nel 2.6 viene mantenuta nel campo
-  \texttt{static\_prio} come per le priorità statiche.} L'origine del nome di
+  \texttt{static\_prio} come per le priorità statiche.} L'origine del nome di
 questo parametro sta nel fatto che generalmente questo viene usato per
-\textsl{diminuire} la priorità di un processo, come misura di cortesia nei
+\textsl{diminuire} la priorità di un processo, come misura di cortesia nei
 confronti degli altri.  I processi infatti vengono creati dal sistema con un
-valore di \var{nice} nullo e nessuno è privilegiato rispetto agli altri;
-specificando un valore positivo si avrà una \textit{time-slice} più breve ed
-un valore di priorità dinamica iniziale più alto, mentre un valore negativo
-darà una \textit{time-slice} più lunga ed un valore di priorità dinamica
-iniziale più basso.
+valore di \var{nice} nullo e nessuno è privilegiato rispetto agli altri;
+specificando un valore positivo si avrà una \textit{time-slice} più breve ed
+un valore di priorità dinamica iniziale più alto, mentre un valore negativo
+darà una \textit{time-slice} più lunga ed un valore di priorità dinamica
+iniziale più basso.
 
 Esistono diverse funzioni che consentono di modificare la \textit{niceness} di
-un processo; la più semplice è funzione \funcd{nice}, che opera sul processo
-corrente, il suo prototipo è:
+un processo; la più semplice è funzione \funcd{nice}, che opera sul processo
+corrente, il suo prototipo è:
 \begin{prototype}{unistd.h}
 {int nice(int inc)}
   Aumenta il valore di \var{nice} per il processo corrente.
   
   \bodydesc{La funzione ritorna zero o il nuovo valore di \var{nice} in caso
-    di successo e -1 in caso di errore, nel qual caso \var{errno} può assumere
+    di successo e -1 in caso di errore, nel qual caso \var{errno} può assumere
     i valori:
   \begin{errlist}
   \item[\errcode{EPERM}] non si ha il permesso di specificare un valore
@@ -2398,26 +2398,26 @@ corrente, il suo prototipo 
 \end{prototype}
 
 L'argomento \param{inc} indica l'incremento da effettuare rispetto al valore
-di \var{nice} corrente: quest'ultimo può assumere valori compresi fra
+di \var{nice} corrente: quest'ultimo può assumere valori compresi fra
 \const{PRIO\_MIN} e \const{PRIO\_MAX}; nel caso di Linux sono fra $-20$ e
-$19$,\footnote{in realtà l'intervallo varia a seconda delle versioni di
-  kernel, ed è questo a partire dal kernel 1.3.43, anche se oggi si può avere
-  anche l'intervallo fra $-20$ e $20$.} ma per \param{inc} si può specificare
-un valore qualunque, positivo o negativo, ed il sistema provvederà a troncare
+$19$,\footnote{in realtà l'intervallo varia a seconda delle versioni di
+  kernel, ed è questo a partire dal kernel 1.3.43, anche se oggi si può avere
+  anche l'intervallo fra $-20$ e $20$.} ma per \param{inc} si può specificare
+un valore qualunque, positivo o negativo, ed il sistema provvederà a troncare
 il risultato nell'intervallo consentito. Valori positivi comportano maggiore
-\textit{cortesia} e cioè una diminuzione della priorità, valori negativi
-comportano invece un aumento della priorità. Con i kernel precedenti il
+\textit{cortesia} e cioè una diminuzione della priorità, valori negativi
+comportano invece un aumento della priorità. Con i kernel precedenti il
 2.6.12 solo l'amministratore\footnote{o un processo con la
   \itindex{capabilities} \textit{capability} \const{CAP\_SYS\_NICE}, vedi
-  sez.~\ref{sec:proc_capabilities}.} può specificare valori negativi
-di \param{inc} che permettono di aumentare la priorità di un processo, a
-partire da questa versione è consentito anche agli utenti normali alzare
-(entro certi limiti, che vedremo più avanti) la priorità dei propri processi.
+  sez.~\ref{sec:proc_capabilities}.} può specificare valori negativi
+di \param{inc} che permettono di aumentare la priorità di un processo, a
+partire da questa versione è consentito anche agli utenti normali alzare
+(entro certi limiti, che vedremo più avanti) la priorità dei propri processi.
 
 Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore
 di \var{nice} del processo; tuttavia la system call di Linux non segue questa
 convenzione e restituisce sempre 0 in caso di successo e $-1$ in caso di
-errore; questo perché $-1$ è un valore di \var{nice} legittimo e questo
+errore; questo perché $-1$ è un valore di \var{nice} legittimo e questo
 comporta una confusione con una eventuale condizione di errore. La system call
 originaria inoltre non consente, se non dotati di adeguati privilegi, di
 diminuire un valore di \var{nice} precedentemente innalzato.
@@ -2425,36 +2425,36 @@ diminuire un valore di \var{nice} precedentemente innalzato.
 Fino alle \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il
 risultato dalla system call, violando lo standard, per cui per ottenere il
 nuovo valore occorreva una successiva chiamata alla funzione
-\func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
-reimplementata e non viene più chiamata la omonima system call, con questa
+\func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
+reimplementata e non viene più chiamata la omonima system call, con questa
 versione viene restituito come valore di ritorno il valore di \var{nice}, come
 richiesto dallo standard.\footnote{questo viene fatto chiamando al suo interno
   \func{setpriority}, che tratteremo a breve.}  In questo caso l'unico modo
-per rilevare in maniera affidabile una condizione di errore è quello di
+per rilevare in maniera affidabile una condizione di errore è quello di
 azzerare \var{errno} prima della chiamata della funzione e verificarne il
 valore quando \func{nice} restituisce $-1$.
 
 Per leggere il valore di \textit{nice} di un processo occorre usare la
-funzione \funcd{getpriority}, derivata da BSD; il suo prototipo è:
+funzione \funcd{getpriority}, derivata da BSD; il suo prototipo è:
 \begin{prototype}{sys/resource.h}
 {int getpriority(int which, int who)}
   
 Restituisce il valore di \var{nice} per l'insieme dei processi specificati.
 
-  \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} può assumere i valori:
+  \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
+    errore, nel qual caso \var{errno} può assumere i valori:
   \begin{errlist}
-  \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
+  \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
   \param{which} e \param{who}.
-  \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
+  \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
   \end{errlist}}
 \end{prototype}
-\noindent nelle vecchie versioni può essere necessario includere anche
-\file{<sys/time.h>}, questo non è più necessario con versioni recenti delle
-librerie, ma è comunque utile per portabilità.
+\noindent nelle vecchie versioni può essere necessario includere anche
+\file{<sys/time.h>}, questo non è più necessario con versioni recenti delle
+librerie, ma è comunque utile per portabilità.
 
 La funzione permette, a seconda del valore di \param{which}, di leggere la
-priorità di un processo, di un gruppo di processi (vedi
+priorità di un processo, di un gruppo di processi (vedi
 sez.~\ref{sec:sess_proc_group}) o di un utente, specificando un corrispondente
 valore per \param{who} secondo la legenda di tab.~\ref{tab:proc_getpriority};
 un valore nullo di quest'ultimo indica il processo, il gruppo di processi o
@@ -2480,32 +2480,32 @@ l'utente correnti.
   \label{tab:proc_getpriority}
 \end{table}
 
-La funzione restituisce la priorità più alta (cioè il valore più basso) fra
-quelle dei processi specificati; di nuovo, dato che $-1$ è un valore
-possibile, per poter rilevare una condizione di errore è necessario cancellare
+La funzione restituisce la priorità più alta (cioè il valore più basso) fra
+quelle dei processi specificati; di nuovo, dato che $-1$ è un valore
+possibile, per poter rilevare una condizione di errore è necessario cancellare
 sempre \var{errno} prima della chiamata alla funzione per verificare che essa
 resti uguale a zero.
 
-Analoga a \func{getpriority} è la funzione \funcd{setpriority} che permette di
-impostare la priorità di uno o più processi; il suo prototipo è:
+Analoga a \func{getpriority} è la funzione \funcd{setpriority} che permette di
+impostare la priorità di uno o più processi; il suo prototipo è:
 \begin{prototype}{sys/resource.h}
 {int setpriority(int which, int who, int prio)}  
-  Imposta la priorità per l'insieme dei processi specificati.
+  Imposta la priorità per l'insieme dei processi specificati.
 
   \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
-    nel qual caso \var{errno} può assumere i valori:
+    nel qual caso \var{errno} può assumere i valori:
   \begin{errlist}
-  \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
+  \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
   \param{which} e \param{who}.
-  \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
-  \item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere
+  \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
+  \item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere
     sufficienti privilegi.
   \item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
-    cercato di modificare la priorità di un processo di un altro utente.
+    cercato di modificare la priorità di un processo di un altro utente.
   \end{errlist}}
 \end{prototype}
 
-La funzione imposta la priorità al valore specificato da \param{prio} per
+La funzione imposta la priorità al valore specificato da \param{prio} per
 tutti i processi indicati dagli argomenti \param{which} e \param{who}. In
 questo caso come valore di \param{prio} deve essere specificato il valore di
 \textit{nice} da assegnare, e non un incremento (positivo o negativo) come nel
@@ -2515,24 +2515,24 @@ anche in questo caso per rilevare un errore occorre sempre porre a zero
 \var{errno} prima della chiamata della funzione, essendo $-1$ un valore di
 \textit{nice} valido. 
 
-Si tenga presente che solo l'amministratore\footnote{o più precisamente un
+Si tenga presente che solo l'amministratore\footnote{o più precisamente un
   processo con la \itindex{capabilities} \textit{capability}
   \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} ha la
-possibilità di modificare arbitrariamente le priorità di qualunque
-processo. Un utente normale infatti può modificare solo la priorità dei suoi
+possibilità di modificare arbitrariamente le priorità di qualunque
+processo. Un utente normale infatti può modificare solo la priorità dei suoi
 processi ed in genere soltanto diminuirla.  Fino alla versione di kernel
 2.6.12 Linux ha seguito le specifiche dello standard SUSv3, e come per tutti i
 sistemi derivati da SysV veniva richiesto che l'user-ID reale o quello
 effettivo del processo chiamante corrispondessero all'user-ID reale (e solo a
-quello) del processo di cui si intendeva cambiare la priorità. A partire dalla
-versione 2.6.12 è stata adottata la semantica in uso presso i sistemi derivati
-da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere anche con
+quello) del processo di cui si intendeva cambiare la priorità. A partire dalla
+versione 2.6.12 è stata adottata la semantica in uso presso i sistemi derivati
+da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere anche con
 l'user-ID effettivo.
 
-Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
-ordinari poter aumentare la priorità dei propri processi specificando un
-valore di \param{prio} negativo. Questa operazione non è possibile però in
-maniera indiscriminata, ed in particolare può essere effettuata solo
+Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
+ordinari poter aumentare la priorità dei propri processi specificando un
+valore di \param{prio} negativo. Questa operazione non è possibile però in
+maniera indiscriminata, ed in particolare può essere effettuata solo
 nell'intervallo consentito dal valore del limite \const{RLIMIT\_NICE}
 (torneremo su questo in sez.~\ref{sec:sys_resource_limit}).
 
@@ -2541,81 +2541,81 @@ nell'intervallo consentito dal valore del limite \const{RLIMIT\_NICE}
 \label{sec:proc_real_time}
 
 Come spiegato in sez.~\ref{sec:proc_sched} lo standard POSIX.1b ha introdotto
-le priorità assolute per permettere la gestione di processi real-time. In
-realtà nel caso di Linux non si tratta di un vero hard real-time, in quanto in
+le priorità assolute per permettere la gestione di processi real-time. In
+realtà nel caso di Linux non si tratta di un vero hard real-time, in quanto in
 presenza di eventuali interrupt il kernel interrompe l'esecuzione di un
-processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
-  siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile
+processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
+  siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile
   ottenere un sistema effettivamente hard real-time. In tal caso infatti gli
   interrupt vengono intercettati dall'interfaccia real-time (o nel caso di
   Adeos gestiti dalle code del nano-kernel), in modo da poterli controllare
-  direttamente qualora ci sia la necessità di avere un processo con priorità
-  più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
+  direttamente qualora ci sia la necessità di avere un processo con priorità
+  più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
 \itindex{page~fault} \textit{page fault} si possono avere ritardi non
-previsti.  Se l'ultimo problema può essere aggirato attraverso l'uso delle
+previsti.  Se l'ultimo problema può essere aggirato attraverso l'uso delle
 funzioni di controllo della memoria virtuale (vedi
-sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può comportare
+sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può comportare
 ritardi non prevedibili riguardo ai tempi di esecuzione di qualunque processo.
 
 Nonostante questo, ed in particolare con una serie di miglioramenti che sono
 stati introdotti nello sviluppo del kernel,\footnote{in particolare a partire
   dalla versione 2.6.18 sono stati inserite nel kernel una serie di modifiche
-  che consentono di avvicinarsi sempre di più ad un vero e proprio sistema
+  che consentono di avvicinarsi sempre di più ad un vero e proprio sistema
   \textit{real-time} estendendo il concetto di \textit{preemption} alle
-  operazioni dello stesso kernel; esistono vari livelli a cui questo può
+  operazioni dello stesso kernel; esistono vari livelli a cui questo può
   essere fatto, ottenibili attivando in fase di compilazione una fra le
   opzioni \texttt{CONFIG\_PREEMPT\_NONE}, \texttt{CONFIG\_PREEMPT\_VOLUNTARY}
-  e \texttt{CONFIG\_PREEMPT\_DESKTOP}.} si può arrivare ad una ottima
-approssimazione di sistema real-time usando le priorità assolute; occorre
-farlo però con molta attenzione: se si dà ad un processo una priorità assoluta
-e questo finisce in un loop infinito, nessun altro processo potrà essere
-eseguito, ed esso sarà mantenuto in esecuzione permanentemente assorbendo
-tutta la CPU e senza nessuna possibilità di riottenere l'accesso al
-sistema. Per questo motivo è sempre opportuno, quando si lavora con processi
-che usano priorità assolute, tenere attiva una shell cui si sia assegnata la
-massima priorità assoluta, in modo da poter essere comunque in grado di
+  e \texttt{CONFIG\_PREEMPT\_DESKTOP}.} si può arrivare ad una ottima
+approssimazione di sistema real-time usando le priorità assolute; occorre
+farlo però con molta attenzione: se si dà ad un processo una priorità assoluta
+e questo finisce in un loop infinito, nessun altro processo potrà essere
+eseguito, ed esso sarà mantenuto in esecuzione permanentemente assorbendo
+tutta la CPU e senza nessuna possibilità di riottenere l'accesso al
+sistema. Per questo motivo è sempre opportuno, quando si lavora con processi
+che usano priorità assolute, tenere attiva una shell cui si sia assegnata la
+massima priorità assoluta, in modo da poter essere comunque in grado di
 rientrare nel sistema.
 
-Quando c'è un processo con priorità assoluta lo scheduler lo metterà in
-esecuzione prima di ogni processo normale. In caso di più processi sarà
-eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
-processi con la stessa priorità assoluta questi vengono tenuti in una coda e
+Quando c'è un processo con priorità assoluta lo scheduler lo metterà in
+esecuzione prima di ogni processo normale. In caso di più processi sarà
+eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
+processi con la stessa priorità assoluta questi vengono tenuti in una coda e
 tocca al kernel decidere quale deve essere eseguito.  Il meccanismo con cui
-vengono gestiti questi processi dipende dalla politica di scheduling che si è
+vengono gestiti questi processi dipende dalla politica di scheduling che si è
 scelta; lo standard ne prevede due:
 \begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
 \item[\textsf{FIFO}] \textit{First In First Out}. Il processo viene eseguito
   fintanto che non cede volontariamente la CPU (con \func{sched\_yield}), si
-  blocca, finisce o viene interrotto da un processo a priorità più alta. Se il
-  processo viene interrotto da uno a priorità più alta esso resterà in cima
-  alla lista e sarà il primo ad essere eseguito quando i processi a priorità
-  più alta diverranno inattivi. Se invece lo si blocca volontariamente sarà
-  posto in coda alla lista (ed altri processi con la stessa priorità potranno
+  blocca, finisce o viene interrotto da un processo a priorità più alta. Se il
+  processo viene interrotto da uno a priorità più alta esso resterà in cima
+  alla lista e sarà il primo ad essere eseguito quando i processi a priorità
+  più alta diverranno inattivi. Se invece lo si blocca volontariamente sarà
+  posto in coda alla lista (ed altri processi con la stessa priorità potranno
   essere eseguiti).
-\item[\textsf{RR}] \textit{Round Robin}. Il comportamento è del tutto analogo
+\item[\textsf{RR}] \textit{Round Robin}. Il comportamento è del tutto analogo
   a quello precedente, con la sola differenza che ciascun processo viene
   eseguito al massimo per un certo periodo di tempo (la cosiddetta
   \textit{time-slice}) dopo di che viene automaticamente posto in fondo alla
-  coda dei processi con la stessa priorità. In questo modo si ha comunque una
+  coda dei processi con la stessa priorità. In questo modo si ha comunque una
   esecuzione a turno di tutti i processi, da cui il nome della politica. Solo
-  i processi con la stessa priorità ed in stato \textbf{Runnable} entrano nel
+  i processi con la stessa priorità ed in stato \textbf{Runnable} entrano nel
   \textsl{girotondo}.
 \end{basedescript}
 
 Lo standard POSIX.1-2001 prevede una funzione che consenta sia di modificare
 le politiche di scheduling, passando da real-time a ordinarie o viceversa, che
-di specificare, in caso di politiche real-time, la eventuale priorità statica;
-la funzione è \funcd{sched\_setscheduler} ed il suo prototipo è:
+di specificare, in caso di politiche real-time, la eventuale priorità statica;
+la funzione è \funcd{sched\_setscheduler} ed il suo prototipo è:
 \begin{prototype}{sched.h}
 {int sched\_setscheduler(pid\_t pid, int policy, const struct sched\_param *p)}
-  Imposta priorità e politica di scheduling.
+  Imposta priorità e politica di scheduling.
   
   \bodydesc{La funzione ritorna 0 in caso di successo e $-$1 in caso di
-    errore, nel qual caso \var{errno} può assumere i valori:
+    errore, nel qual caso \var{errno} può assumere i valori:
     \begin{errlist}
     \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
     \item[\errcode{EINVAL}] il valore di \param{policy} non esiste o il
-      relativo valore di \param{p} non è valido.
+      relativo valore di \param{p} non è valido.
     \item[\errcode{EPERM}] il processo non ha i privilegi per attivare la
       politica richiesta.
   \end{errlist}}
@@ -2623,7 +2623,7 @@ la funzione 
 
 La funzione esegue l'impostazione per il processo specificato dall'argomento
 \param{pid}; un valore nullo di questo argomento esegue l'impostazione per il
-processo corrente.  La politica di scheduling è specificata
+processo corrente.  La politica di scheduling è specificata
 dall'argomento \param{policy} i cui possibili valori sono riportati in
 tab.~\ref{tab:proc_sched_policy}; la parte alta della tabella indica le
 politiche real-time, quella bassa le politiche ordinarie. Un valore negativo
@@ -2644,7 +2644,7 @@ per \param{policy} mantiene la politica di scheduling corrente.
     \const{SCHED\_OTHER}& Scheduling ordinario.\\
     \const{SCHED\_BATCH}& Scheduling ordinario con l'assunzione ulteriore di
                           lavoro \textit{CPU intensive}.\footnotemark\\
-    \const{SCHED\_IDLE} & Scheduling di priorità estremamente
+    \const{SCHED\_IDLE} & Scheduling di priorità estremamente
                           bassa.\footnotemark\\
     \hline
   \end{tabular}
@@ -2656,15 +2656,15 @@ per \param{policy} mantiene la politica di scheduling corrente.
 \footnotetext[44]{introdotto con il kernel 2.6.16.}
 \footnotetext{introdotto con il kernel 2.6.23.}
 
-Con le versioni più recenti del kernel sono state introdotte anche delle
+Con le versioni più recenti del kernel sono state introdotte anche delle
 varianti sulla politica di scheduling tradizionale per alcuni carichi di
 lavoro specifici, queste due nuove politiche sono specifiche di Linux e non
 devono essere usate se si vogliono scrivere programmi portabili.
 
-La politica \const{SCHED\_BATCH} è una variante della politica ordinaria con
+La politica \const{SCHED\_BATCH} è una variante della politica ordinaria con
 la sola differenza che i processi ad essa soggetti non ottengono, nel calcolo
-delle priorità dinamiche fatto dallo scheduler, il cosiddetto bonus di
-interattività che mira a favorire i processi che si svegliano dallo stato di
+delle priorità dinamiche fatto dallo scheduler, il cosiddetto bonus di
+interattività che mira a favorire i processi che si svegliano dallo stato di
 \textbf{Sleep}.\footnote{cosa che accade con grande frequenza per i processi
   interattivi, dato che essi sono per la maggior parte del tempo in attesa di
   dati in ingresso da parte dell'utente.} La si usa pertanto, come indica il
@@ -2673,19 +2673,19 @@ questo modo sono leggermente sfavoriti rispetto ai processi interattivi che
 devono rispondere a dei dati in ingresso, pur non perdendo il loro valore di
 \textit{nice}.
 
-La politica \const{SCHED\_IDLE} invece è una politica dedicata ai processi che
-si desidera siano eseguiti con la più bassa priorità possibile, ancora più
+La politica \const{SCHED\_IDLE} invece è una politica dedicata ai processi che
+si desidera siano eseguiti con la più bassa priorità possibile, ancora più
 bassa di un processo con il minimo valore di \textit{nice}. In sostanza la si
-può utilizzare per processi che devono essere eseguiti se non c'è niente altro
+può utilizzare per processi che devono essere eseguiti se non c'è niente altro
 da fare. Va comunque sottolineato che anche un processo \const{SCHED\_IDLE}
-avrà comunque una sua possibilità di utilizzo della CPU, sia pure in
+avrà comunque una sua possibilità di utilizzo della CPU, sia pure in
 percentuale molto bassa.
 
-Qualora si sia richiesta una politica real-time il valore della priorità
+Qualora si sia richiesta una politica real-time il valore della priorità
 statica viene impostato attraverso la struttura \struct{sched\_param},
 riportata in fig.~\ref{fig:sig_sched_param}, il cui solo campo attualmente
-definito è \var{sched\_priority}. Il campo deve contenere il valore della
-priorità statica da assegnare al processo; lo standard prevede che questo
+definito è \var{sched\_priority}. Il campo deve contenere il valore della
+priorità statica da assegnare al processo; lo standard prevede che questo
 debba essere assegnato all'interno di un intervallo fra un massimo ed un
 minimo che nel caso di Linux sono rispettivamente 1 e 99.  
 
@@ -2700,13 +2700,13 @@ minimo che nel caso di Linux sono rispettivamente 1 e 99.
 \end{figure}
 
 I processi con politica di scheduling ordinaria devono sempre specificare un
-valore nullo di \var{sched\_priority} altrimenti si avrà un errore
+valore nullo di \var{sched\_priority} altrimenti si avrà un errore
 \errcode{EINVAL}, questo valore infatti non ha niente a che vedere con la
-priorità dinamica determinata dal valore di \textit{nice}, che deve essere
+priorità dinamica determinata dal valore di \textit{nice}, che deve essere
 impostato con le funzioni viste in precedenza.
 
 Lo standard POSIX.1b prevede comunque che i due valori della massima e minima
-priorità statica possano essere ottenuti, per ciascuna delle politiche di
+priorità statica possano essere ottenuti, per ciascuna delle politiche di
 scheduling \textit{real-time}, tramite le due funzioni
 \funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
 prototipi sono:
@@ -2714,58 +2714,58 @@ prototipi sono:
   \headdecl{sched.h}
   
   \funcdecl{int sched\_get\_priority\_max(int policy)} Legge il valore
-  massimo della priorità statica per la politica di scheduling \param{policy}.
+  massimo della priorità statica per la politica di scheduling \param{policy}.
 
   
   \funcdecl{int sched\_get\_priority\_min(int policy)} Legge il valore minimo
-  della priorità statica per la politica di scheduling \param{policy}.
+  della priorità statica per la politica di scheduling \param{policy}.
   
-  \bodydesc{La funzioni ritornano il valore della priorità in caso di successo
-    e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
+  \bodydesc{La funzioni ritornano il valore della priorità in caso di successo
+    e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
     \begin{errlist}
-    \item[\errcode{EINVAL}] il valore di \param{policy} non è valido.
+    \item[\errcode{EINVAL}] il valore di \param{policy} non è valido.
   \end{errlist}}
 \end{functions}
 
 Si tenga presente che quando si imposta una politica di scheduling real-time
-per un processo o se ne cambia la priorità statica questo viene messo in cima
-alla lista dei processi con la stessa priorità; questo comporta che verrà
-eseguito subito, interrompendo eventuali altri processi con la stessa priorità
+per un processo o se ne cambia la priorità statica questo viene messo in cima
+alla lista dei processi con la stessa priorità; questo comporta che verrà
+eseguito subito, interrompendo eventuali altri processi con la stessa priorità
 in quel momento in esecuzione.
 
-Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
+Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
 esegue sempre il primo della lista, mentre un nuovo processo che torna in
 stato \textbf{Runnable} viene sempre inserito in coda alla lista. Se la
-politica scelta è \const{SCHED\_FIFO} quando il processo viene eseguito viene
+politica scelta è \const{SCHED\_FIFO} quando il processo viene eseguito viene
 automaticamente rimesso in coda alla lista, e la sua esecuzione continua
 fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
 volontariamente la CPU (in tal caso, tornando nello stato \textbf{Runnable}
-sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
-nel caso che esso sia stato interrotto da un processo a priorità più alta.
+sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
+nel caso che esso sia stato interrotto da un processo a priorità più alta.
 
-Solo un processo con i privilegi di amministratore\footnote{più precisamente
-  con la \itindex{capabilities} capacità \const{CAP\_SYS\_NICE}, vedi
-  sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità
+Solo un processo con i privilegi di amministratore\footnote{più precisamente
+  con la \itindex{capabilities} capacità \const{CAP\_SYS\_NICE}, vedi
+  sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità
 assolute diverse da zero o politiche \const{SCHED\_FIFO} e
-\const{SCHED\_RR}. Un utente normale può modificare solo le priorità di
-processi che gli appartengono; è cioè richiesto che l'user-ID effettivo del
+\const{SCHED\_RR}. Un utente normale può modificare solo le priorità di
+processi che gli appartengono; è cioè richiesto che l'user-ID effettivo del
 processo chiamante corrisponda all'user-ID reale o effettivo del processo
 indicato con \param{pid}.
 
 Fino al kernel 2.6.12 gli utenti normali non potevano impostare politiche
-real-time o modificare la eventuale priorità statica di un loro processo. A
-partire da questa versione è divenuto possibile anche per gli utenti normali
-usare politiche real-time fintanto che la priorità assoluta che si vuole
-impostare è inferiore al limite \const{RLIMIT\_RTPRIO} (vedi
+real-time o modificare la eventuale priorità statica di un loro processo. A
+partire da questa versione è divenuto possibile anche per gli utenti normali
+usare politiche real-time fintanto che la priorità assoluta che si vuole
+impostare è inferiore al limite \const{RLIMIT\_RTPRIO} (vedi
 sez.~\ref{sec:sys_resource_limit}) ad essi assegnato. Unica eccezione a questa
-possibilità sono i processi \const{SCHED\_IDLE}, che non possono cambiare
+possibilità sono i processi \const{SCHED\_IDLE}, che non possono cambiare
 politica di scheduling indipendentemente dal valore di
-\const{RLIMIT\_RTPRIO}. Inoltre, in caso di processo già sottoposto ad una
-politica real-time, un utente può sempre, indipendentemente dal valore di
-\const{RLIMIT\_RTPRIO}, diminuirne la priorità o portarlo ad una politica
+\const{RLIMIT\_RTPRIO}. Inoltre, in caso di processo già sottoposto ad una
+politica real-time, un utente può sempre, indipendentemente dal valore di
+\const{RLIMIT\_RTPRIO}, diminuirne la priorità o portarlo ad una politica
 ordinaria.
 
-Se si intende operare solo sulla priorità statica di un processo si possono
+Se si intende operare solo sulla priorità statica di un processo si possono
 usare le due funzioni \funcd{sched\_setparam} e \funcd{sched\_getparam} che
 consentono rispettivamente di impostarne e leggerne il valore, i loro
 prototipi sono:
@@ -2773,13 +2773,13 @@ prototipi sono:
   \headdecl{sched.h}
 
   \funcdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *param)}
-  Imposta la priorità statica del processo \param{pid}.
+  Imposta la priorità statica del processo \param{pid}.
 
   \funcdecl{int sched\_getparam(pid\_t pid, struct sched\_param *param)}
-  Legge la priorità statica del processo \param{pid}.
+  Legge la priorità statica del processo \param{pid}.
 
   \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e $-1$ in
-    caso di errore, nel qual caso \var{errno} può assumere i valori:
+    caso di errore, nel qual caso \var{errno} può assumere i valori:
     \begin{errlist}
     \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
     \item[\errcode{EINVAL}] il valore di \param{param} non ha senso per la
@@ -2790,24 +2790,24 @@ prototipi sono:
 \end{functions}
 
 L'uso di \func{sched\_setparam}, compresi i controlli di accesso che vi si
-applicano, è del tutto equivalente a quello di \func{sched\_setscheduler} con
+applicano, è del tutto equivalente a quello di \func{sched\_setscheduler} con
 argomento \param{policy} uguale a -1. Come per \func{sched\_setscheduler}
 specificando 0 come valore dell'argomento \param{pid} si opera sul processo
-corrente. Benché la funzione sia utilizzabile anche con processi sottoposti a
+corrente. Benché la funzione sia utilizzabile anche con processi sottoposti a
 politica ordinaria essa ha senso soltanto per quelli real-time, dato che per i
-primi la priorità statica può essere soltanto nulla.  La disponibilità di
-entrambe le funzioni può essere verificata controllando la macro
-\macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'header
+primi la priorità statica può essere soltanto nulla.  La disponibilità di
+entrambe le funzioni può essere verificata controllando la macro
+\macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'header
 \file{sched.h}.
 
-Se invece si vuole sapere quale è politica di scheduling di un processo si può
-usare la funzione \funcd{sched\_getscheduler}, il cui prototipo è:
+Se invece si vuole sapere quale è politica di scheduling di un processo si può
+usare la funzione \funcd{sched\_getscheduler}, il cui prototipo è:
 \begin{prototype}{sched.h}
 {int sched\_getscheduler(pid\_t pid)}
   Legge la politica di scheduling per il processo \param{pid}.
   
   \bodydesc{La funzione ritorna la politica di scheduling in caso di successo
-    e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
+    e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
     \begin{errlist}
     \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
     \item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire
@@ -2817,35 +2817,35 @@ usare la funzione \funcd{sched\_getscheduler}, il cui prototipo 
 
 La funzione restituisce il valore, secondo quanto elencato in
 tab.~\ref{tab:proc_sched_policy}, della politica di scheduling per il processo
-specificato; se l'argomento \param{pid} è nullo viene restituito il valore
+specificato; se l'argomento \param{pid} è nullo viene restituito il valore
 relativo al processo chiamante.
 
 L'ultima funzione che permette di leggere le informazioni relative ai processi
-real-time è \funcd{sched\_rr\_get\_interval}, che permette di ottenere la
+real-time è \funcd{sched\_rr\_get\_interval}, che permette di ottenere la
 lunghezza della \textit{time-slice} usata dalla politica \textit{round robin};
-il suo prototipo è:
+il suo prototipo è:
 \begin{prototype}{sched.h}
   {int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)} Legge in
   \param{tp} la durata della \textit{time-slice} per il processo \param{pid}.
   
   \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
-    nel qual caso \var{errno} può assumere i valori:
+    nel qual caso \var{errno} può assumere i valori:
     \begin{errlist}
     \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
-    \item[\errcode{ENOSYS}] la system call non è stata implementata.
+    \item[\errcode{ENOSYS}] la system call non è stata implementata.
   \end{errlist}}
 \end{prototype}
 
 La funzione restituisce il valore dell'intervallo di tempo usato per la
 politica \textit{round robin} in una struttura \struct{timespec}, (la cui
-definizione si può trovare in fig.~\ref{fig:sys_timeval_struct}). In realtà
-dato che in Linux questo intervallo di tempo è prefissato e non modificabile,
+definizione si può trovare in fig.~\ref{fig:sys_timeval_struct}). In realtà
+dato che in Linux questo intervallo di tempo è prefissato e non modificabile,
 questa funzione ritorna sempre un valore di 150 millisecondi, e non importa
 specificare il PID di un processo reale.
 
-Come accennato ogni processo può rilasciare volontariamente la CPU in modo da
+Come accennato ogni processo può rilasciare volontariamente la CPU in modo da
 consentire agli altri processi di essere eseguiti; la funzione che consente di
-fare tutto ciò è \funcd{sched\_yield}, il cui prototipo è:
+fare tutto ciò è \funcd{sched\_yield}, il cui prototipo è:
 \begin{prototype}{sched.h}
   {int sched\_yield(void)} 
   
@@ -2856,22 +2856,22 @@ fare tutto ci
 \end{prototype}
 
 Questa funzione ha un utilizzo effettivo soltanto quando si usa lo scheduling
-real-time, e serve a far sì che il processo corrente rilasci la CPU, in modo
-da essere rimesso in coda alla lista dei processi con la stessa priorità per
-permettere ad un altro di essere eseguito; se però il processo è l'unico ad
-essere presente sulla coda l'esecuzione non sarà interrotta. In genere usano
+real-time, e serve a far sì che il processo corrente rilasci la CPU, in modo
+da essere rimesso in coda alla lista dei processi con la stessa priorità per
+permettere ad un altro di essere eseguito; se però il processo è l'unico ad
+essere presente sulla coda l'esecuzione non sarà interrotta. In genere usano
 questa funzione i processi con politica \const{SCHED\_FIFO}, per permettere
-l'esecuzione degli altri processi con pari priorità quando la sezione più
-urgente è finita.
+l'esecuzione degli altri processi con pari priorità quando la sezione più
+urgente è finita.
 
-La funzione può essere utilizzata anche con processi che usano lo scheduling
-ordinario, ma in questo caso il comportamento non è ben definito, e dipende
+La funzione può essere utilizzata anche con processi che usano lo scheduling
+ordinario, ma in questo caso il comportamento non è ben definito, e dipende
 dall'implementazione. Fino al kernel 2.6.23 questo comportava che i processi
-venissero messi in fondo alla coda di quelli attivi, con la possibilità di
+venissero messi in fondo alla coda di quelli attivi, con la possibilità di
 essere rimessi in esecuzione entro breve tempo, con l'introduzione del
-\textit{Completely Fair Scheduler} questo comportamento è cambiato ed un
+\textit{Completely Fair Scheduler} questo comportamento è cambiato ed un
 processo che chiama la funzione viene inserito nella lista dei processi
-inattivo, con un tempo molto maggiore.\footnote{è comunque possibile
+inattivo, con un tempo molto maggiore.\footnote{è comunque possibile
   ripristinare un comportamento analogo al precedente scrivendo il valore 1
   nel file \texttt{/proc/sys/kernel/sched\_compat\_yield}.}
 
@@ -2882,10 +2882,10 @@ inattivo, con un tempo molto maggiore.\footnote{
 \label{sec:proc_sched_multiprocess}
 
 Infine con il supporto dei sistemi multiprocessore sono state introdotte delle
-funzioni che permettono di controllare in maniera più dettagliata la scelta di
+funzioni che permettono di controllare in maniera più dettagliata la scelta di
 quale processore utilizzare per eseguire un certo programma. Uno dei problemi
-che si pongono nei sistemi multiprocessore è infatti quello del cosiddetto
-\index{effetto~ping-pong} \textsl{effetto ping-pong}. Può accadere cioè che lo
+che si pongono nei sistemi multiprocessore è infatti quello del cosiddetto
+\index{effetto~ping-pong} \textsl{effetto ping-pong}. Può accadere cioè che lo
 scheduler, quando riavvia un processo precedentemente interrotto scegliendo il
 primo processore disponibile, lo faccia eseguire da un processore diverso
 rispetto a quello su cui era stato eseguito in precedenza. Se il processo
@@ -2893,19 +2893,19 @@ passa da un processore all'altro in questo modo (cosa che avveniva abbastanza
 di frequente con i kernel della seria 2.4.x) si ha l'\textsl{effetto
   ping-pong}.
 
-Questo tipo di comportamento può generare dei seri problemi di prestazioni;
+Questo tipo di comportamento può generare dei seri problemi di prestazioni;
 infatti tutti i processori moderni utilizzano una memoria interna (la
-\textit{cache}) contenente i dati più usati, che permette di evitare di
-eseguire un accesso (molto più lento) alla memoria principale sulla scheda
-madre.  Chiaramente un processo sarà favorito se i suoi dati sono nella cache
-del processore, ma è ovvio che questo può essere vero solo per un processore
-alla volta, perché in presenza di più copie degli stessi dati su più
+\textit{cache}) contenente i dati più usati, che permette di evitare di
+eseguire un accesso (molto più lento) alla memoria principale sulla scheda
+madre.  Chiaramente un processo sarà favorito se i suoi dati sono nella cache
+del processore, ma è ovvio che questo può essere vero solo per un processore
+alla volta, perché in presenza di più copie degli stessi dati su più
 processori, non si potrebbe determinare quale di questi ha la versione dei
 dati aggiornata rispetto alla memoria principale.
 
 Questo comporta che quando un processore inserisce un dato nella sua cache,
 tutti gli altri processori che hanno lo stesso dato devono invalidarlo, e
-questa operazione è molto costosa in termini di prestazioni. Il problema
+questa operazione è molto costosa in termini di prestazioni. Il problema
 diventa serio quando si verifica l'\textsl{effetto ping-pong}, in tal caso
 infatti un processo \textsl{rimbalza} continuamente da un processore all'altro
 e si ha una continua invalidazione della cache, che non diventa mai
@@ -2913,34 +2913,34 @@ disponibile.
 
 \itindbeg{CPU~affinity}
 
-Per ovviare a questo tipo di problemi è nato il concetto di \textsl{affinità
-  di processore} (o \textit{CPU affinity}); la possibilità cioè di far sì che
+Per ovviare a questo tipo di problemi è nato il concetto di \textsl{affinità
+  di processore} (o \textit{CPU affinity}); la possibilità cioè di far sì che
 un processo possa essere assegnato per l'esecuzione sempre allo stesso
 processore. Lo scheduler dei kernel della serie 2.4.x aveva una scarsa
 \textit{CPU affinity}, e \index{effetto~ping-pong} l'effetto ping-pong era
-comune; con il nuovo scheduler dei kernel della 2.6.x questo problema è stato
-risolto ed esso cerca di mantenere il più possibile ciascun processo sullo
+comune; con il nuovo scheduler dei kernel della 2.6.x questo problema è stato
+risolto ed esso cerca di mantenere il più possibile ciascun processo sullo
 stesso processore.
 
-In certi casi però resta l'esigenza di poter essere sicuri che un processo sia
+In certi casi però resta l'esigenza di poter essere sicuri che un processo sia
 sempre eseguito dallo stesso processore,\footnote{quella che viene detta
   \textit{hard CPU affinity}, in contrasto con quella fornita dallo scheduler,
   detta \textit{soft CPU affinity}, che di norma indica solo una preferenza,
   non un requisito assoluto.} e per poter risolvere questo tipo di
 problematiche nei nuovi kernel\footnote{le due system call per la gestione
   della \textit{CPU affinity} sono state introdotte nel kernel 2.5.8, e le
-  funzioni di libreria nelle \textsl{glibc} 2.3.} è stata introdotta
+  funzioni di libreria nelle \textsl{glibc} 2.3.} è stata introdotta
 l'opportuna infrastruttura ed una nuova system call che permette di impostare
 su quali processori far eseguire un determinato processo attraverso una
-\textsl{maschera di affinità}. La corrispondente funzione di libreria è
-\funcd{sched\_setaffinity} ed il suo prototipo è:
+\textsl{maschera di affinità}. La corrispondente funzione di libreria è
+\funcd{sched\_setaffinity} ed il suo prototipo è:
 \begin{prototype}{sched.h}
   {int sched\_setaffinity (pid\_t pid, unsigned int cpusetsize, const
     cpu\_set\_t *cpuset)} 
-  Imposta la maschera di affinità del processo \param{pid}.
+  Imposta la maschera di affinità del processo \param{pid}.
   
   \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
-    nel qual caso \var{errno} può assumere i valori:
+    nel qual caso \var{errno} può assumere i valori:
     \begin{errlist}
     \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
     \item[\errcode{EINVAL}] il valore di \param{cpuset} contiene riferimenti a
@@ -2959,10 +2959,10 @@ corrispondono al fatto che la implementazione effettiva usa una semplice
 maschera binaria. Quando le funzioni vennero incluse nelle \acr{glibc}
 assunsero invece il prototipo appena mostrato. A complicare la cosa si
 aggiunge il fatto che nella versione 2.3.3 delle \acr{glibc} l'argomento
-\param{cpusetsize} è stato eliminato, per poi essere ripristinato nella
-versione 2.3.4.\footnote{pertanto se la vostra pagina di manuale non è
+\param{cpusetsize} è stato eliminato, per poi essere ripristinato nella
+versione 2.3.4.\footnote{pertanto se la vostra pagina di manuale non è
   aggiornata, o usate quella particolare versione delle \acr{glibc}, potrete
-  trovare indicazioni diverse, il prototipo illustrato è quello riportato
+  trovare indicazioni diverse, il prototipo illustrato è quello riportato
   nella versione corrente (maggio 2008) delle pagine di manuale e
   corrispondente alla definizione presente in \file{sched.h}.}
 
@@ -2971,50 +2971,50 @@ La funzione imposta, con l'uso del valore contenuto all'indirizzo
 processo identificato tramite il valore passato in \param{pid}. Come in
 precedenza il valore nullo di \param{pid} indica il processo corrente.  Per
 poter utilizzare questa funzione sono richiesti i privilegi di amministratore
-(è necessaria la capacità \const{CAP\_SYS\_NICE}) altrimenti essa fallirà con
-un errore di \errcode{EPERM}. Una volta impostata una maschera di affinità,
+(è necessaria la capacità \const{CAP\_SYS\_NICE}) altrimenti essa fallirà con
+un errore di \errcode{EPERM}. Una volta impostata una maschera di affinità,
 questa viene ereditata attraverso una \func{fork}, in questo modo diventa
 possibile legare automaticamente un gruppo di processi ad un singolo
 processore.
 
 Nell'uso comune, almeno con i kernel della serie 2.6.x, l'uso di questa
-funzione non è necessario, in quanto è lo scheduler stesso che provvede a
-mantenere al meglio l'affinità di processore. Esistono però esigenze
-particolari, ad esempio quando un processo (o un gruppo di processi) è
+funzione non è necessario, in quanto è lo scheduler stesso che provvede a
+mantenere al meglio l'affinità di processore. Esistono però esigenze
+particolari, ad esempio quando un processo (o un gruppo di processi) è
 utilizzato per un compito importante (ad esempio per applicazioni real-time o
-la cui risposta è critica) e si vuole la massima velocità, con questa
+la cui risposta è critica) e si vuole la massima velocità, con questa
 interfaccia diventa possibile selezionare gruppi di processori utilizzabili in
 maniera esclusiva.  Lo stesso dicasi quando l'accesso a certe risorse (memoria
-o periferiche) può avere un costo diverso a seconda del processore, come
+o periferiche) può avere un costo diverso a seconda del processore, come
 avviene nelle architetture NUMA (\textit{Non-Uniform Memory Access}).
 
 Infine se un gruppo di processi accede alle stesse risorse condivise (ad
-esempio una applicazione con più \itindex{thread} \textit{thread}) può avere
+esempio una applicazione con più \itindex{thread} \textit{thread}) può avere
 senso usare lo stesso processore in modo da sfruttare meglio l'uso della sua
 cache; questo ovviamente riduce i benefici di un sistema multiprocessore
 nell'esecuzione contemporanea dei \itindex{thread} \textit{thread}, ma in
 certi casi (quando i \itindex{thread} \textit{thread} sono inerentemente
 serializzati nell'accesso ad una risorsa) possono esserci sufficienti vantaggi
-nell'evitare la perdita della cache da rendere conveniente l'uso dell'affinità
+nell'evitare la perdita della cache da rendere conveniente l'uso dell'affinità
 di processore.
 
 Per facilitare l'uso dell'argomento \param{cpuset} le \acr{glibc} hanno
-introdotto un apposito dato di tipo, \ctyp{cpu\_set\_t},\footnote{questa è una
+introdotto un apposito dato di tipo, \ctyp{cpu\_set\_t},\footnote{questa è una
   estensione specifica delle \acr{glibc}, da attivare definendo la macro
   \macro{\_GNU\_SOURCE}, non esiste infatti una standardizzazione per
   questo tipo di interfaccia e POSIX al momento non prevede nulla al
-  riguardo.} che permette di identificare un insieme di processori. Il dato è
-una maschera binaria: in generale è un intero a 32 bit in cui ogni bit
+  riguardo.} che permette di identificare un insieme di processori. Il dato è
+una maschera binaria: in generale è un intero a 32 bit in cui ogni bit
 corrisponde ad un processore, ma dato che per architetture particolari il
-numero di bit di un intero può non essere sufficiente, è stata creata questa
-che è una interfaccia generica che permette di usare a basso livello un tipo
+numero di bit di un intero può non essere sufficiente, è stata creata questa
+che è una interfaccia generica che permette di usare a basso livello un tipo
 di dato qualunque rendendosi indipendenti dal numero di bit e dalla loro
 disposizione.
 
 Questa interfaccia, oltre alla definizione del tipo di dato apposito, prevede
 anche una serie di macro di preprocessore per la manipolazione dello stesso,
 che consentono di svuotare un insieme, aggiungere o togliere un processore da
-esso o verificare se vi è già presente:
+esso o verificare se vi è già presente:
 \begin{functions}
   \headdecl{sched.h}
   \funcdecl{void \macro{CPU\_ZERO}(cpu\_set\_t *set)}
@@ -3027,83 +3027,83 @@ esso o verificare se vi 
   Rimuove il processore \param{cpu} nell'insieme.
   
   \funcdecl{int \macro{CPU\_ISSET}(int cpu, cpu\_set\_t *set)}
-  Controlla se il processore \param{cpu} è nell'insieme.
+  Controlla se il processore \param{cpu} è nell'insieme.
 \end{functions}
 
 Oltre a queste macro, simili alle analoghe usate per gli insiemi di file
-descriptor (vedi sez.~\ref{sec:file_select}) è definita la costante
+descriptor (vedi sez.~\ref{sec:file_select}) è definita la costante
 \const{CPU\_SETSIZE} che indica il numero massimo di processori che possono
 far parte dell'insieme, e che costituisce un limite massimo al valore
 dell'argomento \param{cpu}.
 
-In generale la maschera di affinità è preimpostata in modo che un processo
-possa essere eseguito su qualunque processore, se può comunque leggere il
+In generale la maschera di affinità è preimpostata in modo che un processo
+possa essere eseguito su qualunque processore, se può comunque leggere il
 valore per un processo specifico usando la funzione
-\funcd{sched\_getaffinity}, il suo prototipo è:
+\funcd{sched\_getaffinity}, il suo prototipo è:
 \begin{prototype}{sched.h}
   {int sched\_getaffinity (pid\_t pid, unsigned int cpusetsize, 
     const cpu\_set\_t *cpuset)} 
-  Legge la maschera di affinità del processo \param{pid}.
+  Legge la maschera di affinità del processo \param{pid}.
   
   \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
-    nel qual caso \var{errno} può assumere i valori:
+    nel qual caso \var{errno} può assumere i valori:
     \begin{errlist}
     \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
-    \item[\errcode{EFAULT}] il valore di \param{cpuset} non è un indirizzo
+    \item[\errcode{EFAULT}] il valore di \param{cpuset} non è un indirizzo
       valido. 
   \end{errlist} }
 \end{prototype}
 
-La funzione restituirà all'indirizzo specificato da \param{cpuset} il valore
-della maschera di affinità del processo, così da poterla riutilizzare per una
+La funzione restituirà all'indirizzo specificato da \param{cpuset} il valore
+della maschera di affinità del processo, così da poterla riutilizzare per una
 successiva reimpostazione. In questo caso non sono necessari privilegi
 particolari.  
 
-È chiaro che queste funzioni per la gestione dell'affinità hanno significato
+È chiaro che queste funzioni per la gestione dell'affinità hanno significato
 soltanto su un sistema multiprocessore, esse possono comunque essere
-utilizzate anche in un sistema con un processore singolo, nel qual caso però
+utilizzate anche in un sistema con un processore singolo, nel qual caso però
 non avranno alcun risultato effettivo.
 
 \itindend{scheduler}
 \itindend{CPU~affinity}
 
 
-\subsection{Le priorità per le operazioni di I/O}
+\subsection{Le priorità per le operazioni di I/O}
 \label{sec:io_priority}
 
-A lungo l'unica priorità usata per i processi è stata quella relativa
-all'assegnazione dell'uso del processore. Ma il processore non è l'unica
+A lungo l'unica priorità usata per i processi è stata quella relativa
+all'assegnazione dell'uso del processore. Ma il processore non è l'unica
 risorsa che i processi devono contendersi, un'altra, altrettanto importante
-per le prestazioni, è quella dell'accesso a disco. Per questo motivo sono
+per le prestazioni, è quella dell'accesso a disco. Per questo motivo sono
 stati introdotti diversi \textit{I/O scheduler} in grado di distribuire in
 maniera opportuna questa risorsa ai vari processi. Fino al kernel 2.6.17 era
 possibile soltanto differenziare le politiche generali di gestione, scegliendo
 di usare un diverso \textit{I/O scheduler}; a partire da questa versione, con
-l'introduzione dello scheduler CFQ (\textit{Completely Fair Queuing}) è
+l'introduzione dello scheduler CFQ (\textit{Completely Fair Queuing}) è
 divenuto possibile, qualora si usi questo scheduler, impostare anche delle
-diverse priorità di accesso per i singoli processi.\footnote{al momento
-  (kernel 2.6.31), le priorità di I/O sono disponibili soltanto per questo
+diverse priorità di accesso per i singoli processi.\footnote{al momento
+  (kernel 2.6.31), le priorità di I/O sono disponibili soltanto per questo
   scheduler.}
 
-La scelta dello scheduler di I/O si può fare in maniera generica a livello di
+La scelta dello scheduler di I/O si può fare in maniera generica a livello di
 avvio del kernel assegnando il nome dello stesso al parametro
-\texttt{elevator}, mentre se ne può indicare uno per l'accesso al singolo
+\texttt{elevator}, mentre se ne può indicare uno per l'accesso al singolo
 disco scrivendo nel file \texttt{/sys/block/\textit{dev}/queue/scheduler}
-(dove \texttt{\textit{dev}} è il nome del dispositivo associato al disco); gli
+(dove \texttt{\textit{dev}} è il nome del dispositivo associato al disco); gli
 scheduler disponibili sono mostrati dal contenuto dello stesso file che
 riporta fra parentesi quadre quello attivo, il default in tutti i kernel
-recenti è proprio il \texttt{cfq},\footnote{nome con cui si indica appunto lo
-  scheduler \textit{Completely Fair Queuing}.} che supporta le priorità. Per i
+recenti è proprio il \texttt{cfq},\footnote{nome con cui si indica appunto lo
+  scheduler \textit{Completely Fair Queuing}.} che supporta le priorità. Per i
 dettagli sulle caratteristiche specifiche degli altri scheduler, la cui
 discussione attiene a problematiche di ambito sistemistico, si consulti la
 documentazione nella directory \texttt{Documentation/block/} dei sorgenti del
 kernel.
 
 Una volta che si sia impostato lo scheduler CFQ ci sono due specifiche system
-call, specifiche di Linux, che consentono di leggere ed impostare le priorità
+call, specifiche di Linux, che consentono di leggere ed impostare le priorità
 di I/O.\footnote{se usate in corrispondenza ad uno scheduler diverso il loro
-  utilizzo non avrà alcun effetto.} Dato che non esiste una interfaccia
-diretta nelle \acr{glibc} per queste due funzioni occorrerà invocarle tramite
+  utilizzo non avrà alcun effetto.} Dato che non esiste una interfaccia
+diretta nelle \acr{glibc} per queste due funzioni occorrerà invocarle tramite
 la funzione \func{syscall} (come illustrato in
 sez.~\ref{sec:intro_syscall}). Le due funzioni sono \funcd{ioprio\_get} ed
 \funcd{ioprio\_set}; i rispettivi prototipi sono:
@@ -3112,11 +3112,11 @@ sez.~\ref{sec:intro_syscall}). Le due funzioni sono \funcd{ioprio\_get} ed
   \funcdecl{int ioprio\_get(int which, int who)} 
   \funcdecl{int ioprio\_set(int which, int who, int ioprio)} 
 
-  Rileva o imposta la priorità di I/O di un processo.
+  Rileva o imposta la priorità di I/O di un processo.
   
   \bodydesc{Le funzioni ritornano rispettivamente un intero positivo
-    (indicante la priorità) o 0 in caso di successo e $-1$ in caso di errore,
-    nel qual caso \var{errno} può assumere i valori:
+    (indicante la priorità) o 0 in caso di successo e $-1$ in caso di errore,
+    nel qual caso \var{errno} può assumere i valori:
     \begin{errlist}
     \item[\errcode{ESRCH}] non esiste il processo indicato.
     \item[\errcode{EINVAL}] i valori di \param{which} e \param{who} non sono
@@ -3126,9 +3126,9 @@ sez.~\ref{sec:intro_syscall}). Le due funzioni sono \funcd{ioprio\_get} ed
   \end{errlist} }
 \end{functions}
 
-Le funzioni leggono o impostano la priorità di I/O sulla base dell'indicazione
+Le funzioni leggono o impostano la priorità di I/O sulla base dell'indicazione
 dei due argomenti \param{which} e \param{who} che hanno lo stesso significato
-già visto per gli omonimi argomenti di \func{getpriority} e
+già visto per gli omonimi argomenti di \func{getpriority} e
 \func{setpriority}. Anche in questo caso si deve specificare il valore
 di \param{which} tramite le opportune costanti riportate in
 tab.~\ref{tab:ioprio_args} che consentono di indicare un singolo processo, i
@@ -3156,21 +3156,21 @@ sez.~\ref{sec:sess_proc_group}) o tutti o processi di un utente.
 \end{table}
 
 In caso di successo \func{ioprio\_get} restituisce un intero positivo che
-esprime il valore della priorità di I/O, questo valore è una maschera binaria
+esprime il valore della priorità di I/O, questo valore è una maschera binaria
 composta da due parti, una che esprime la \textsl{classe} di scheduling di I/O
 del processo, l'altra che esprime, quando la classe di scheduling lo prevede,
-la priorità del processo all'interno della classe stessa. Questo stesso
-formato viene utilizzato per indicare il valore della priorità da impostare
+la priorità del processo all'interno della classe stessa. Questo stesso
+formato viene utilizzato per indicare il valore della priorità da impostare
 con l'argomento \param{ioprio} di \func{ioprio\_set}.
 
-Per la gestione dei valori che esprimono le priorità di I/O sono state
+Per la gestione dei valori che esprimono le priorità di I/O sono state
 definite delle opportune macro di preprocessore, riportate in
-tab.~\ref{tab:IOsched_class_macro}. I valori delle priorità si ottengono o si
+tab.~\ref{tab:IOsched_class_macro}. I valori delle priorità si ottengono o si
 impostano usando queste macro.  Le prime due si usano con il valore restituito
 da \func{ioprio\_get} e per ottenere rispettivamente la classe di
 scheduling\footnote{restituita dalla macro con i valori di
-  tab.~\ref{tab:IOsched_class}.} e l'eventuale valore della priorità. La terza
-macro viene invece usata per creare un valore di priorità da usare come
+  tab.~\ref{tab:IOsched_class}.} e l'eventuale valore della priorità. La terza
+macro viene invece usata per creare un valore di priorità da usare come
 argomento di \func{ioprio\_set} per eseguire una impostazione.
 
 \begin{table}[htb]
@@ -3182,15 +3182,15 @@ argomento di \func{ioprio\_set} per eseguire una impostazione.
     \hline
     \hline
     \macro{IOPRIO\_PRIO\_CLASS}\texttt{(\textit{value})}
-                                & dato il valore di una priorità come
+                                & dato il valore di una priorità come
                                   restituito da \func{ioprio\_get} estrae il
                                   valore della classe.\\
     \macro{IOPRIO\_PRIO\_DATA}\texttt{(\textit{value})}
-                                & dato il valore di una priorità come
+                                & dato il valore di una priorità come
                                   restituito da \func{ioprio\_get} estrae il
-                                  valore della priorità.\\
+                                  valore della priorità.\\
     \macro{IOPRIO\_PRIO\_VALUE}\texttt{(\textit{class},\textit{prio})}
-                                & dato un valore di priorità ed una classe
+                                & dato un valore di priorità ed una classe
                                   ottiene il valore numerico da passare a
                                   \func{ioprio\_set}.\\
     \hline
@@ -3200,19 +3200,19 @@ argomento di \func{ioprio\_set} per eseguire una impostazione.
 \end{table}
 
 Le classi di scheduling previste dallo scheduler CFQ sono tre, e ricalcano tre
-diverse modalità di distribuzione delle risorse analoghe a quelle già adottate
-anche nel funzionamento dello scheduler del processore. Ciascuna di esse è
+diverse modalità di distribuzione delle risorse analoghe a quelle già adottate
+anche nel funzionamento dello scheduler del processore. Ciascuna di esse è
 identificata tramite una opportuna costante, secondo quanto riportato in
 tab.~\ref{tab:IOsched_class}.
 
-La classe di priorità più bassa è \const{IOPRIO\_CLASS\_IDLE}; i processi in
+La classe di priorità più bassa è \const{IOPRIO\_CLASS\_IDLE}; i processi in
 questa classe riescono ad accedere a disco soltanto quando nessun altro
 processo richiede l'accesso. Occorre pertanto usarla con molta attenzione,
-perché un processo in questa classe può venire completamente bloccato quando
+perché un processo in questa classe può venire completamente bloccato quando
 ci sono altri processi in una qualunque delle altre due classi che stanno
 accedendo al disco. Quando si usa questa classe non ha senso indicare un
-valore di priorità, dato che in questo caso non esiste nessuna gerarchia e la
-priorità è identica, la minima possibile, per tutti i processi.
+valore di priorità, dato che in questo caso non esiste nessuna gerarchia e la
+priorità è identica, la minima possibile, per tutti i processi.
 
 \begin{table}[htb]
   \centering
@@ -3224,66 +3224,66 @@ priorit
     \hline
     \const{IOPRIO\_CLASS\_RT}  & Scheduling di I/O \textit{real time}.\\
     \const{IOPRIO\_CLASS\_BE}  & Scheduling di I/O ordinario.\\ 
-    \const{IOPRIO\_CLASS\_IDLE}& Scheduling di I/O di priorità minima.\\
+    \const{IOPRIO\_CLASS\_IDLE}& Scheduling di I/O di priorità minima.\\
     \hline
   \end{tabular}
   \caption{Costanti che identificano le classi di scheduling di I/O.}
   \label{tab:IOsched_class}
 \end{table}
 
-La seconda classe di priorità di I/O è \const{IOPRIO\_CLASS\_BE} (il nome sta
-per \textit{best-effort}) che è quella usata ordinariamente da tutti
-processi. In questo caso esistono priorità diverse che consentono di
+La seconda classe di priorità di I/O è \const{IOPRIO\_CLASS\_BE} (il nome sta
+per \textit{best-effort}) che è quella usata ordinariamente da tutti
+processi. In questo caso esistono priorità diverse che consentono di
 assegnazione di una maggiore banda passante nell'accesso a disco ad un
 processo rispetto agli altri, con meccanismo simile a quello dei valori di
-\textit{nice} in cui si evita che un processo a priorità più alta possa
-bloccare indefinitamente quelli a priorità più bassa. In questo caso però le
-diverse priorità sono soltanto otto, indicate da un valore numerico fra 0 e 7
-e come per \textit{nice} anche in questo caso un valore più basso indica una
-priorità maggiore. 
+\textit{nice} in cui si evita che un processo a priorità più alta possa
+bloccare indefinitamente quelli a priorità più bassa. In questo caso però le
+diverse priorità sono soltanto otto, indicate da un valore numerico fra 0 e 7
+e come per \textit{nice} anche in questo caso un valore più basso indica una
+priorità maggiore. 
 
 
-Infine la classe di priorità di I/O \textit{real-time}
-\const{IOPRIO\_CLASS\_RT} ricalca le omonime priorità di processore: un
+Infine la classe di priorità di I/O \textit{real-time}
+\const{IOPRIO\_CLASS\_RT} ricalca le omonime priorità di processore: un
 processo in questa classe ha sempre la precedenza nell'accesso a disco
 rispetto a tutti i processi delle altre classi e di un processo nella stessa
-classe ma con priorità inferiore, ed è pertanto in grado di bloccare
-completamente tutti gli altri. Anche in questo caso ci sono 8 priorità diverse
-con un valore numerico fra 0 e 7, con una priorità più elevata per valori più
+classe ma con priorità inferiore, ed è pertanto in grado di bloccare
+completamente tutti gli altri. Anche in questo caso ci sono 8 priorità diverse
+con un valore numerico fra 0 e 7, con una priorità più elevata per valori più
 bassi.
 
-In generale nel funzionamento ordinario la priorità di I/O di un processo
+In generale nel funzionamento ordinario la priorità di I/O di un processo
 viene impostata in maniera automatica nella classe \const{IOPRIO\_CLASS\_BE}
 con un valore ottenuto a partire dal corrispondente valore di \textit{nice}
 tramite la formula: $\mathtt{\mathit{prio}}=(\mathtt{\mathit{nice}}+20)/5$. Un
-utente ordinario può modificare con \func{ioprio\_set} soltanto le priorità
-dei processi che gli appartengono,\footnote{per la modifica delle priorità di
+utente ordinario può modificare con \func{ioprio\_set} soltanto le priorità
+dei processi che gli appartengono,\footnote{per la modifica delle priorità di
   altri processi occorrono privilegi amministrativi, ed in particolare la
-  capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).}
-cioè quelli il cui user-ID reale corrisponde all'user-ID reale o effettivo del
-chiamante. Data la possibilità di ottenere un blocco totale dello stesso, solo
-l'amministratore\footnote{o un processo con la capacità
-  \const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può
-impostare un processo ad una priorità di I/O nella classe
+  capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).}
+cioè quelli il cui user-ID reale corrisponde all'user-ID reale o effettivo del
+chiamante. Data la possibilità di ottenere un blocco totale dello stesso, solo
+l'amministratore\footnote{o un processo con la capacità
+  \const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può
+impostare un processo ad una priorità di I/O nella classe
 \const{IOPRIO\_CLASS\_RT} o \const{IOPRIO\_CLASS\_IDLE}.
 
 %TODO verificare http://lwn.net/Articles/355987/
 
-%TODO trattare le funzionalità per il NUMA
+%TODO trattare le funzionalità per il NUMA
 % vedi man numa e le pagine di manuale relative
 % vedere anche dove metterle...
 
 \section{Problematiche di programmazione multitasking}
 \label{sec:proc_multi_prog}
 
-Benché i processi siano strutturati in modo da apparire il più possibile come
+Benché i processi siano strutturati in modo da apparire il più possibile come
 indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking
 occorre tenere conto di una serie di problematiche che normalmente non
 esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
 programma alla volta.
 
-Pur essendo questo argomento di carattere generale, ci è parso opportuno
-introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
+Pur essendo questo argomento di carattere generale, ci è parso opportuno
+introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
 in capitoli successivi, in questa sezione conclusiva del capitolo in cui
 abbiamo affrontato la gestione dei processi.
 
@@ -3292,43 +3292,43 @@ abbiamo affrontato la gestione dei processi.
 \label{sec:proc_atom_oper}
 
 La nozione di \textsl{operazione atomica} deriva dal significato greco della
-parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
+parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
 quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
-che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
+che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
 di interruzione in una fase intermedia.
 
-In un ambiente multitasking il concetto è essenziale, dato che un processo può
+In un ambiente multitasking il concetto è essenziale, dato che un processo può
 essere interrotto in qualunque momento dal kernel che mette in esecuzione un
 altro processo o dalla ricezione di un segnale; occorre pertanto essere
 accorti nei confronti delle possibili \itindex{race~condition} \textit{race
   condition} (vedi sez.~\ref{sec:proc_race_cond}) derivanti da operazioni
 interrotte in una fase in cui non erano ancora state completate.
 
-Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
-occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
+Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
+occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
 fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
 cap.~\ref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
 sez.~\ref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
-funzioni di libreria per compiere le operazioni necessarie è garanzia
-sufficiente di atomicità in quanto le system call con cui esse sono realizzate
+funzioni di libreria per compiere le operazioni necessarie è garanzia
+sufficiente di atomicità in quanto le system call con cui esse sono realizzate
 non possono essere interrotte (o subire interferenze pericolose) da altri
 processi.
 
-Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
+Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
 stesso processo, e pure alcune system call, possono essere interrotti in
 qualunque momento, e le operazioni di un eventuale \textit{signal handler}
 sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
-il solo accesso o l'assegnazione di una variabile possono non essere più
+il solo accesso o l'assegnazione di una variabile possono non essere più
 operazioni atomiche (torneremo su questi aspetti in
 sez.~\ref{sec:sig_adv_control}).
 
 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
-il cui accesso è assicurato essere atomico.  In pratica comunque si può
-assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
+il cui accesso è assicurato essere atomico.  In pratica comunque si può
+assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
 \ctyp{int}, gli altri interi di dimensione inferiore ed i puntatori sono
-atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
-maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
-le strutture. In tutti questi casi è anche opportuno marcare come
+atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
+maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
+le strutture. In tutti questi casi è anche opportuno marcare come
 \direct{volatile} le variabili che possono essere interessate ad accesso
 condiviso, onde evitare problemi con le ottimizzazioni del codice.
 
@@ -3342,25 +3342,25 @@ condiviso, onde evitare problemi con le ottimizzazioni del codice.
 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
 diversi operano su una risorsa comune, ed in cui il risultato viene a
 dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
-tipico è quello di un'operazione che viene eseguita da un processo in più
-passi, e può essere compromessa dall'intervento di un altro processo che
+tipico è quello di un'operazione che viene eseguita da un processo in più
+passi, e può essere compromessa dall'intervento di un altro processo che
 accede alla stessa risorsa quando ancora non tutti i passi sono stati
 completati.
 
-Dato che in un sistema multitasking ogni processo può essere interrotto in
-qualunque momento per farne subentrare un altro in esecuzione, niente può
+Dato che in un sistema multitasking ogni processo può essere interrotto in
+qualunque momento per farne subentrare un altro in esecuzione, niente può
 assicurare un preciso ordine di esecuzione fra processi diversi o che una
 sezione di un programma possa essere eseguita senza interruzioni da parte di
 altri. Queste situazioni comportano pertanto errori estremamente subdoli e
 difficili da tracciare, in quanto nella maggior parte dei casi tutto
-funzionerà regolarmente, e solo occasionalmente si avranno degli errori. 
+funzionerà regolarmente, e solo occasionalmente si avranno degli errori. 
 
 Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
-che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
-gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
+che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
+gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
 \textit{race condition} si hanno quando diversi processi accedono allo stesso
 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
-condivisa. In questi casi, se non si dispone della possibilità di eseguire
+condivisa. In questi casi, se non si dispone della possibilità di eseguire
 atomicamente le operazioni necessarie, occorre che quelle parti di codice in
 cui si compiono le operazioni sulle risorse condivise (le cosiddette
 \index{sezione~critica} \textsl{sezioni critiche}) del programma, siano
@@ -3371,21 +3371,21 @@ problematiche di questo tipo in cap.~\ref{cha:IPC}).
 Un caso particolare di \textit{race condition} sono poi i cosiddetti
 \textit{deadlock}, particolarmente gravi in quanto comportano spesso il blocco
 completo di un servizio, e non il fallimento di una singola operazione. Per
-definizione un \textit{deadlock} è una situazione in cui due o più processi
-non sono più in grado di proseguire perché ciascuno aspetta il risultato di
+definizione un \textit{deadlock} è una situazione in cui due o più processi
+non sono più in grado di proseguire perché ciascuno aspetta il risultato di
 una operazione che dovrebbe essere eseguita dall'altro.
 
 
-L'esempio tipico di una situazione che può condurre ad un
-\textit{deadlock} è quello in cui un flag di
+L'esempio tipico di una situazione che può condurre ad un
+\textit{deadlock} è quello in cui un flag di
 ``\textsl{occupazione}'' viene rilasciato da un evento asincrono (come un
-segnale o un altro processo) fra il momento in cui lo si è controllato
+segnale o un altro processo) fra il momento in cui lo si è controllato
 (trovandolo occupato) e la successiva operazione di attesa per lo sblocco. In
-questo caso, dato che l'evento di sblocco del flag è avvenuto senza che ce ne
+questo caso, dato che l'evento di sblocco del flag è avvenuto senza che ce ne
 accorgessimo proprio fra il controllo e la messa in attesa, quest'ultima
-diventerà perpetua (da cui il nome di \textit{deadlock}).
+diventerà perpetua (da cui il nome di \textit{deadlock}).
 
-In tutti questi casi è di fondamentale importanza il concetto di atomicità
+In tutti questi casi è di fondamentale importanza il concetto di atomicità
 visto in sez.~\ref{sec:proc_atom_oper}; questi problemi infatti possono essere
 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
 eseguire in maniera atomica le operazioni necessarie.
@@ -3398,33 +3398,33 @@ eseguire in maniera atomica le operazioni necessarie.
 
 \index{funzioni!rientranti|(}
 
-Si dice \textsl{rientrante} una funzione che può essere interrotta in
+Si dice \textsl{rientrante} una funzione che può essere interrotta in
 qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
 un altro \itindex{thread} \textit{thread} di esecuzione senza che questo
-comporti nessun problema nell'esecuzione della stessa. La problematica è
+comporti nessun problema nell'esecuzione della stessa. La problematica è
 comune nella programmazione \itindex{thread} \textit{multi-thread}, ma si
 hanno gli stessi problemi quando si vogliono chiamare delle funzioni
 all'interno dei gestori dei segnali.
 
-Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
+Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
 queste infatti vengono allocate nello \itindex{stack} \textit{stack}, ed
 un'altra invocazione non fa altro che allocarne un'altra copia. Una funzione
-può non essere rientrante quando opera su memoria che non è nello
-\itindex{stack} \textit{stack}.  Ad esempio una funzione non è mai rientrante
+può non essere rientrante quando opera su memoria che non è nello
+\itindex{stack} \textit{stack}.  Ad esempio una funzione non è mai rientrante
 se usa una variabile globale o statica.
 
 Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
-cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
-ogni volta e ritornato indietro la funzione può essere rientrante, se invece
+cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
+ogni volta e ritornato indietro la funzione può essere rientrante, se invece
 esso viene individuato dalla funzione stessa due chiamate alla stessa funzione
 potranno interferire quando entrambe faranno riferimento allo stesso oggetto.
-Allo stesso modo una funzione può non essere rientrante se usa e modifica un
+Allo stesso modo una funzione può non essere rientrante se usa e modifica un
 oggetto che le viene fornito dal chiamante: due chiamate possono interferire
 se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
 parte del programmatore.
 
 In genere le funzioni di libreria non sono rientranti, molte di esse ad
-esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
+esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
 disposizione due macro di compilatore,\footnote{si ricordi quanto illustrato
   in sez.~\ref{sec:intro_gcc_glibc_std}.} \macro{\_REENTRANT} e
 \macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
diff --git a/ringraziamenti.tex b/ringraziamenti.tex
index f6dd40b..1bf951f 100644
--- a/ringraziamenti.tex
+++ b/ringraziamenti.tex
@@ -11,12 +11,12 @@
 \chapter{Ringraziamenti}
 \label{cha:ringraziamenti}
 
-Desidero ringraziare tutti coloro che a vario titolo e a più riprese mi hanno
-aiutato ed han contribuito a migliorare in molteplici aspetti la qualità di
+Desidero ringraziare tutti coloro che a vario titolo e a più riprese mi hanno
+aiutato ed han contribuito a migliorare in molteplici aspetti la qualità di
 GaPiL. In ordine rigorosamente alfabetico desidero citare:
 \begin{description}
 \item[\textbf{Alessio Frusciante}] per l'apprezzamento, le innumerevoli
-  correzioni ed i suggerimenti per rendere più chiara l'esposizione.
+  correzioni ed i suggerimenti per rendere più chiara l'esposizione.
 \item[\textbf{Daniele Masini}] per la rilettura puntuale, le innumerevoli
   correzioni, i consigli sull'esposizione ed i contributi relativi alle
   calling convention dei linguaggi e al confronto delle diverse tecniche di
@@ -34,7 +34,7 @@ Infine, vorrei ringraziare il Firenze Linux User Group (FLUG), di cui mi
 pregio di fare parte, che ha messo a disposizione il repository CVS su cui era
 presente la prima versione della Guida, ed il relativo spazio web, e Truelite
 Srl, l'azienda che ho fondato e di cui sono responsabile tecnico, che fornisce
-il nuovo repository SVN, tutto quanto è necessario alla pubblicazione della
+il nuovo repository SVN, tutto quanto è necessario alla pubblicazione della
 guida ed il sistema di tracciamento dei sorgenti su
 \href{http://gapil.truelite.it/sources}
 {\textsf{http://gapil.truelite.it/sources}}.
diff --git a/session.tex b/session.tex
index 9281d02..766b879 100644
--- a/session.tex
+++ b/session.tex
@@ -19,33 +19,33 @@ dell'interfaccia a linea di comando.
 
 Nella prima parte del capitolo esamineremo i concetti base del sistema delle
 sessioni di lavoro, vale a dire il metodo con cui il kernel permette ad un
-utente di gestire le capacità multitasking del sistema, permettendo di
-eseguire più programmi in contemporanea.  Nella seconda parte del capitolo
+utente di gestire le capacità multitasking del sistema, permettendo di
+eseguire più programmi in contemporanea.  Nella seconda parte del capitolo
 tratteremo poi il funzionamento dell'I/O su terminale, e delle varie
-peculiarità che esso viene ad assumere a causa del suo stretto legame con il
+peculiarità che esso viene ad assumere a causa del suo stretto legame con il
 suo uso come interfaccia di accesso al sistema da parte degli utenti.
 
 
 \section{Il \textit{job control}}
 \label{sec:sess_job_control}
 
-Viene comunemente chiamato \textit{job control} quell'insieme di funzionalità
-il cui scopo è quello di permettere ad un utente di poter sfruttare le
-capacità multitasking di un sistema Unix per eseguire in contemporanea più
+Viene comunemente chiamato \textit{job control} quell'insieme di funzionalità
+il cui scopo è quello di permettere ad un utente di poter sfruttare le
+capacità multitasking di un sistema Unix per eseguire in contemporanea più
 processi, pur potendo accedere, di solito, ad un solo terminale,\footnote{con
-  \textit{X Window} e con i terminali virtuali tutto questo non è più vero,
-  dato che si può accedere a molti terminali in contemporanea da una singola
-  postazione di lavoro, ma il sistema è nato prima dell'esistenza di tutto
-  ciò.} avendo cioè un solo punto in cui si può avere accesso all'input ed
+  \textit{X Window} e con i terminali virtuali tutto questo non è più vero,
+  dato che si può accedere a molti terminali in contemporanea da una singola
+  postazione di lavoro, ma il sistema è nato prima dell'esistenza di tutto
+  ciò.} avendo cioè un solo punto in cui si può avere accesso all'input ed
 all'output degli stessi.
 
 
 \subsection{Una panoramica introduttiva}
 \label{sec:sess_job_control_overview}
 
-Il \textit{job control} è una caratteristica opzionale, introdotta in BSD
+Il \textit{job control} è una caratteristica opzionale, introdotta in BSD
 negli anni '80, e successivamente standardizzata da POSIX.1; la sua
-disponibilità nel sistema è verificabile attraverso il controllo della macro
+disponibilità nel sistema è verificabile attraverso il controllo della macro
 \macro{\_POSIX\_JOB\_CONTROL}. In generale il \textit{job control} richiede il
 supporto sia da parte della shell (quasi tutte ormai lo hanno), che da parte
 del kernel; in particolare il kernel deve assicurare sia la presenza di un
@@ -53,40 +53,40 @@ driver per i terminali abilitato al \textit{job control} che quella dei
 relativi segnali illustrati in sez.~\ref{sec:sig_job_control}. 
 
 In un sistema che supporta il \textit{job control}, una volta completato il
-login, l'utente avrà a disposizione una shell dalla quale eseguire i comandi e
-potrà iniziare quella che viene chiamata una \textsl{sessione}, che riunisce
+login, l'utente avrà a disposizione una shell dalla quale eseguire i comandi e
+potrà iniziare quella che viene chiamata una \textsl{sessione}, che riunisce
 (vedi sez.~\ref{sec:sess_proc_group}) tutti i processi eseguiti all'interno
 dello stesso login (esamineremo tutto il processo in dettaglio in
 sez.~\ref{sec:sess_login}).
 
-Siccome la shell è collegata ad un solo terminale, che viene usualmente
+Siccome la shell è collegata ad un solo terminale, che viene usualmente
 chiamato \textsl{terminale di controllo}, (vedi sez.~\ref{sec:sess_ctrl_term})
 un solo comando alla volta (quello che viene detto in \textit{foreground} o in
-\textsl{primo piano}), potrà scrivere e leggere dal terminale. La shell però
-può eseguire, aggiungendo una \cmd{\&} alla fine del comando, più programmi in
+\textsl{primo piano}), potrà scrivere e leggere dal terminale. La shell però
+può eseguire, aggiungendo una \cmd{\&} alla fine del comando, più programmi in
 contemporanea, mandandoli in \textit{background} (o \textsl{sullo sfondo}),
 nel qual caso essi saranno eseguiti senza essere collegati al terminale.
 
 Si noti come si sia parlato di comandi e non di programmi o processi; fra le
-funzionalità della shell infatti c'è anche quella di consentire di concatenare
-più programmi in una sola riga di comando con le pipe, ed in tal caso verranno
-eseguiti più programmi, inoltre, anche quando si invoca un singolo programma,
-questo potrà sempre lanciare sotto-processi per eseguire dei compiti specifici.
-
-Per questo l'esecuzione di un comando può originare più di un processo; quindi
-nella gestione del job control non si può far riferimento ai singoli processi.
-Per questo il kernel prevede la possibilità di raggruppare più processi in un
+funzionalità della shell infatti c'è anche quella di consentire di concatenare
+più programmi in una sola riga di comando con le pipe, ed in tal caso verranno
+eseguiti più programmi, inoltre, anche quando si invoca un singolo programma,
+questo potrà sempre lanciare sotto-processi per eseguire dei compiti specifici.
+
+Per questo l'esecuzione di un comando può originare più di un processo; quindi
+nella gestione del job control non si può far riferimento ai singoli processi.
+Per questo il kernel prevede la possibilità di raggruppare più processi in un
 \itindex{process~group} \textit{process group} (detto anche
 \textsl{raggruppamento di processi}, vedi sez.~\ref{sec:sess_proc_group}) e la
-shell farà sì che tutti i processi che originano da una riga di comando
+shell farà sì che tutti i processi che originano da una riga di comando
 appartengano allo stesso raggruppamento, in modo che le varie funzioni di
 controllo, ed i segnali inviati dal terminale, possano fare riferimento ad
 esso.
 
-In generale allora all'interno di una sessione avremo un eventuale (può non
+In generale allora all'interno di una sessione avremo un eventuale (può non
 esserci) \itindex{process~group} \textit{process group} in
 \textit{foreground}, che riunisce i processi che possono accedere al
-terminale, e più \itindex{process~group} \textit{process group} in
+terminale, e più \itindex{process~group} \textit{process group} in
 \textit{background}, che non possono accedervi. Il job control prevede che
 quando un processo appartenente ad un raggruppamento in \textit{background}
 cerca di accedere al terminale, venga inviato un segnale a tutti i processi
@@ -95,7 +95,7 @@ del raggruppamento, in modo da bloccarli (vedi sez.~\ref{sec:sess_ctrl_term}).
 Un comportamento analogo si ha anche per i segnali generati dai comandi di
 tastiera inviati dal terminale che vengono inviati a tutti i processi del
 raggruppamento in \textit{foreground}. In particolare \cmd{C-z} interrompe
-l'esecuzione del comando, che può poi essere mandato in \textit{background}
+l'esecuzione del comando, che può poi essere mandato in \textit{background}
 con il comando \cmd{bg}.\footnote{si tenga presente che \cmd{bg} e \cmd{fg}
   sono parole chiave che indicano comandi interni alla shell, e nel caso non
   comportano l'esecuzione di un programma esterno.} Il comando \cmd{fg}
@@ -103,7 +103,7 @@ consente invece di mettere in \textit{foreground} un comando precedentemente
 lanciato in \textit{background}.
 
 Di norma la shell si cura anche di notificare all'utente (di solito prima
-della stampa a video del prompt) lo stato dei vari processi; essa infatti sarà
+della stampa a video del prompt) lo stato dei vari processi; essa infatti sarà
 in grado, grazie all'uso di \func{waitpid}, di rilevare sia i processi che
 sono terminati, sia i raggruppamenti che sono bloccati (in questo caso usando
 l'opzione \const{WUNTRACED}, secondo quanto illustrato in
@@ -127,10 +127,10 @@ con le sigle \acr{pgid} e \acr{sid}, e sono mantenuti in variabili di tipo
 \type{pid\_t}. I valori di questi identificatori possono essere visualizzati
 dal comando \cmd{ps} usando l'opzione \cmd{-j}.
 
-Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
-stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
-le funzioni \funcd{getpgid} e \funcd{getpgrp},\footnote{\func{getpgrp} è
-  definita nello standard POSIX.1, mentre \func{getpgid} è richiesta da SVr4.}
+Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
+stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
+le funzioni \funcd{getpgid} e \funcd{getpgrp},\footnote{\func{getpgrp} è
+  definita nello standard POSIX.1, mentre \func{getpgid} è richiesta da SVr4.}
 i cui prototipi sono:
 \begin{functions}
   \headdecl{unistd.h}
@@ -149,22 +149,22 @@ i cui prototipi sono:
 
 La funzione \func{getpgid} permette di specificare il \acr{pid} del processo
 di cui si vuole sapere il \acr{pgid}; un valore nullo per \param{pid}
-restituisce il \acr{pgid} del processo corrente; \func{getpgrp} è di norma
+restituisce il \acr{pgid} del processo corrente; \func{getpgrp} è di norma
 equivalente a \code{getpgid(0)}.
 
-In maniera analoga l'identificatore della sessione può essere letto dalla
-funzione \funcd{getsid}, che però nelle \acr{glibc}\footnote{la system call è
+In maniera analoga l'identificatore della sessione può essere letto dalla
+funzione \funcd{getsid}, che però nelle \acr{glibc}\footnote{la system call è
   stata introdotta in Linux a partire dalla versione 1.3.44, il supporto nelle
-  librerie del C è iniziato dalla versione 5.2.19. La funzione non è prevista
+  librerie del C è iniziato dalla versione 5.2.19. La funzione non è prevista
   da POSIX.1, che parla solo di processi leader di sessione, e non di
-  identificatori di sessione.} è accessibile solo definendo
+  identificatori di sessione.} è accessibile solo definendo
 \macro{\_XOPEN\_SOURCE} e \macro{\_XOPEN\_SOURCE\_EXTENDED}; il suo prototipo
-è:
+è:
 \begin{prototype}{unistd.h}{pid\_t getsid(pid\_t pid)}
   Legge l'identificatore di sessione del processo \param{pid}.
   
   \bodydesc{La funzione restituisce l'identificatore (un numero positivo) in
-  caso di successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà
+  caso di successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà
   i valori:
     \begin{errlist}
     \item[\errcode{ESRCH}] il processo selezionato non esiste.
@@ -178,20 +178,20 @@ funzione \funcd{getsid}, che per
 Entrambi gli identificatori vengono inizializzati alla creazione di ciascun
 processo con lo stesso valore che hanno nel processo padre, per cui un
 processo appena creato appartiene sempre allo stesso raggruppamento e alla
-stessa sessione del padre. Vedremo poi come sia possibile creare più
+stessa sessione del padre. Vedremo poi come sia possibile creare più
 \textit{process group} all'interno della stessa sessione, e spostare i
 processi dall'uno all'altro, ma sempre all'interno di una stessa sessione.
 
 Ciascun raggruppamento di processi ha sempre un processo principale, il
-cosiddetto \itindex{process~group~leader} \textit{process group leader}, che è
+cosiddetto \itindex{process~group~leader} \textit{process group leader}, che è
 identificato dall'avere un \acr{pgid} uguale al suo \acr{pid}, in genere
-questo è il primo processo del raggruppamento, che si incarica di lanciare
+questo è il primo processo del raggruppamento, che si incarica di lanciare
 tutti gli altri. Un nuovo raggruppamento si crea con la funzione
-\funcd{setpgrp},\footnote{questa è la definizione di POSIX.1, BSD definisce
-  una funzione con lo stesso nome, che però è identica a \func{setpgid}; nelle
+\funcd{setpgrp},\footnote{questa è la definizione di POSIX.1, BSD definisce
+  una funzione con lo stesso nome, che però è identica a \func{setpgid}; nelle
   \acr{glibc} viene sempre usata sempre questa definizione, a meno di non
-  richiedere esplicitamente la compatibilità all'indietro con BSD, definendo
-  la macro \macro{\_BSD\_SOURCE}.} il cui prototipo è:
+  richiedere esplicitamente la compatibilità all'indietro con BSD, definendo
+  la macro \macro{\_BSD\_SOURCE}.} il cui prototipo è:
 \begin{prototype}{unistd.h}{int setpgrp(void)}
   Modifica il \acr{pgid} al valore del \acr{pid} del processo corrente.
   
@@ -203,73 +203,73 @@ La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo
 corrente, rende questo \itindex{process~group~leader} \textit{group leader} di
 un nuovo raggruppamento, tutti i successivi processi da esso creati
 apparterranno (a meno di non cambiare di nuovo il \acr{pgid}) al nuovo
-raggruppamento. È possibile invece spostare un processo da un raggruppamento
-ad un altro con la funzione \funcd{setpgid}, il cui prototipo è:
+raggruppamento. È possibile invece spostare un processo da un raggruppamento
+ad un altro con la funzione \funcd{setpgid}, il cui prototipo è:
 \begin{prototype}{unistd.h}{int setpgid(pid\_t pid, pid\_t pgid)}
   Assegna al \acr{pgid} del processo \param{pid} il valore \param{pgid}.
   
   \bodydesc{La funzione ritorna il valore del nuovo \textit{process group}, e
-  -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
+  -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
     \begin{errlist}
     \item[\errcode{ESRCH}] il processo selezionato non esiste.
-    \item[\errcode{EPERM}] il cambiamento non è consentito.
-    \item[\errcode{EACCES}] il processo ha già eseguito una \func{exec}.
-    \item[\errcode{EINVAL}] il valore di \param{pgid} è negativo.
+    \item[\errcode{EPERM}] il cambiamento non è consentito.
+    \item[\errcode{EACCES}] il processo ha già eseguito una \func{exec}.
+    \item[\errcode{EINVAL}] il valore di \param{pgid} è negativo.
     \end{errlist}
  }
 \end{prototype}
 
 La funzione permette di cambiare il \acr{pgid} del processo \param{pid}, ma il
-cambiamento può essere effettuato solo se \param{pgid} indica un
-\textit{process group} che è nella stessa sessione del processo chiamante.
-Inoltre la funzione può essere usata soltanto sul processo corrente o su uno
+cambiamento può essere effettuato solo se \param{pgid} indica un
+\textit{process group} che è nella stessa sessione del processo chiamante.
+Inoltre la funzione può essere usata soltanto sul processo corrente o su uno
 dei suoi figli, ed in quest'ultimo caso ha successo soltanto se questo non ha
-ancora eseguito una \func{exec}.\footnote{questa caratteristica è implementata
+ancora eseguito una \func{exec}.\footnote{questa caratteristica è implementata
   dal kernel che mantiene allo scopo un altro campo, \var{did\_exec}, in
   \struct{task\_struct}.}  Specificando un valore nullo per \param{pid} si
 indica il processo corrente, mentre specificando un valore nullo per
 \param{pgid} si imposta il \textit{process group} al valore del \acr{pid} del
-processo selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0,
+processo selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0,
   0)}.
 
 Di norma questa funzione viene usata dalla shell quando si usano delle
 pipeline, per mettere nello stesso \textit{process group} tutti i programmi
 lanciati su ogni linea di comando; essa viene chiamata dopo una \func{fork}
 sia dal processo padre, per impostare il valore nel figlio, che da
-quest'ultimo, per sé stesso, in modo che il cambiamento di \textit{process
-  group} sia immediato per entrambi; una delle due chiamate sarà ridondante,
+quest'ultimo, per sé stesso, in modo che il cambiamento di \textit{process
+  group} sia immediato per entrambi; una delle due chiamate sarà ridondante,
 ma non potendo determinare quale dei due processi viene eseguito per primo,
 occorre eseguirle comunque entrambe per evitare di esporsi ad una
 \itindex{race~condition} \textit{race condition}.
 
 Si noti come nessuna delle funzioni esaminate finora permetta di spostare un
 processo da una sessione ad un altra; infatti l'unico modo di far cambiare
-sessione ad un processo è quello di crearne una nuova con l'uso di
-\funcd{setsid}; il suo prototipo è:
+sessione ad un processo è quello di crearne una nuova con l'uso di
+\funcd{setsid}; il suo prototipo è:
 \begin{prototype}{unistd.h}{pid\_t setsid(void)}
   Crea una nuova sessione sul processo corrente impostandone \acr{sid} e
   \acr{pgid}.
   
   \bodydesc{La funzione ritorna il valore del nuovo \acr{sid}, e -1 in caso di
-    errore, il solo errore possibile è \errval{EPERM}, che si ha quando il
+    errore, il solo errore possibile è \errval{EPERM}, che si ha quando il
     \acr{pgid} e \acr{pid} del processo coincidono.}
 \end{prototype}
 
 La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al
-valore del suo \acr{pid}, creando così una nuova sessione ed un nuovo
+valore del suo \acr{pid}, creando così una nuova sessione ed un nuovo
 \textit{process group} di cui esso diventa leader (come per i \textit{process
-  group} un processo si dice leader di sessione\footnote{in Linux la proprietà
-  è mantenuta in maniera indipendente con un apposito campo \var{leader} in
-  \struct{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}) ed
+  group} un processo si dice leader di sessione\footnote{in Linux la proprietà
+  è mantenuta in maniera indipendente con un apposito campo \var{leader} in
+  \struct{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}) ed
 unico componente.  Inoltre la funzione distacca il processo da ogni terminale
 di controllo (torneremo sull'argomento in sez.~\ref{sec:sess_ctrl_term}) cui
 fosse in precedenza associato.
 
-La funzione ha successo soltanto se il processo non è già
+La funzione ha successo soltanto se il processo non è già
 \itindex{process~group~leader} leader di un \textit{process group}, per cui
 per usarla di norma si esegue una \func{fork} e si esce, per poi chiamare
 \func{setsid} nel processo figlio, in modo che, avendo questo lo stesso
-\acr{pgid} del padre ma un \acr{pid} diverso, non ci siano possibilità di
+\acr{pgid} del padre ma un \acr{pid} diverso, non ci siano possibilità di
 errore.\footnote{potrebbe sorgere il dubbio che, per il riutilizzo dei valori
   dei \acr{pid} fatto nella creazione dei nuovi processi (vedi
   sez.~\ref{sec:proc_pid}), il figlio venga ad assumere un valore
@@ -287,17 +287,17 @@ i comandi eseguiti da un utente dalla sua shell.
 
 Come accennato in sez.~\ref{sec:sess_job_control_overview}, nel sistema del
 \textit{job control} i processi all'interno di una sessione fanno riferimento
-ad un terminale di controllo (ad esempio quello su cui si è effettuato il
+ad un terminale di controllo (ad esempio quello su cui si è effettuato il
 login), sul quale effettuano le operazioni di lettura e
-scrittura,\footnote{nel caso di login grafico la cosa può essere più
-  complessa, e di norma l'I/O è effettuato tramite il server X, ma ad esempio
+scrittura,\footnote{nel caso di login grafico la cosa può essere più
+  complessa, e di norma l'I/O è effettuato tramite il server X, ma ad esempio
   per i programmi, anche grafici, lanciati da un qualunque emulatore di
-  terminale, sarà quest'ultimo a fare da terminale (virtuale) di controllo.} e
+  terminale, sarà quest'ultimo a fare da terminale (virtuale) di controllo.} e
 dal quale ricevono gli eventuali segnali da tastiera.
 
 A tale scopo lo standard POSIX.1 prevede che ad ogni sessione possa essere
 associato un terminale di controllo; in Linux questo viene realizzato
-mantenendo fra gli attributi di ciascun processo anche qual'è il suo terminale
+mantenendo fra gli attributi di ciascun processo anche qual'è il suo terminale
 di controllo.\footnote{lo standard POSIX.1 non specifica nulla riguardo
   l'implementazione; in Linux anch'esso viene mantenuto nella solita struttura
   \struct{task\_struct}, nel campo \var{tty}.}  In generale ogni processo
@@ -307,26 +307,26 @@ originati dallo stesso leader di sessione mantengono lo stesso terminale di
 controllo.
 
 Alla creazione di una nuova sessione con \func{setsid} ogni associazione con
-il precedente terminale di controllo viene cancellata, ed il processo che è
-divenuto un nuovo leader di sessione dovrà riottenere\footnote{solo quando ciò
-  è necessario, cosa che, come vedremo in sez.~\ref{sec:sess_daemon}, non è
+il precedente terminale di controllo viene cancellata, ed il processo che è
+divenuto un nuovo leader di sessione dovrà riottenere\footnote{solo quando ciò
+  è necessario, cosa che, come vedremo in sez.~\ref{sec:sess_daemon}, non è
   sempre vera.}, un terminale di controllo. In generale questo viene fatto
 automaticamente dal sistema\footnote{a meno di non avere richiesto
   esplicitamente che questo non diventi un terminale di controllo con il flag
   \const{O\_NOCTTY} (vedi sez.~\ref{sec:file_open}). In questo Linux segue la
   semantica di SVr4; BSD invece richiede che il terminale venga allocato
   esplicitamente con una \func{ioctl} con il comando \const{TIOCSCTTY}.}
-quando viene aperto il primo terminale (cioè uno dei vari file di dispositivo
+quando viene aperto il primo terminale (cioè uno dei vari file di dispositivo
 \file{/dev/tty*}) che diventa automaticamente il terminale di controllo,
 mentre il processo diventa il \textsl{processo di controllo} di quella
 sessione.
 
-In genere (a meno di redirezioni) nelle sessioni di lavoro questo terminale è
+In genere (a meno di redirezioni) nelle sessioni di lavoro questo terminale è
 associato ai file standard (di input, output ed error) dei processi nella
 sessione, ma solo quelli che fanno parte del cosiddetto raggruppamento di
 \textit{foreground}, possono leggere e scrivere in certo istante. Per
 impostare il raggruppamento di \textit{foreground} di un terminale si usa la
-funzione \funcd{tcsetpgrp}, il cui prototipo è:
+funzione \funcd{tcsetpgrp}, il cui prototipo è:
 \begin{functions}
   \headdecl{unistd.h}
   \headdecl{termios.h}
@@ -336,37 +336,37 @@ funzione \funcd{tcsetpgrp}, il cui prototipo 
   file descriptor \param{fd}.
    
   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
     \begin{errlist}
     \item[\errcode{ENOTTY}] il file \param{fd} non corrisponde al terminale di
       controllo del processo chiamante.
     \item[\errcode{ENOSYS}] il sistema non supporta il job control.
-    \item[\errcode{EPERM}] il \textit{process group} specificato non è nella
+    \item[\errcode{EPERM}] il \textit{process group} specificato non è nella
     stessa sessione del processo chiamante.
     \end{errlist}
     ed inoltre \errval{EBADF} ed \errval{EINVAL}. 
   }
 \end{functions}
-\noindent la funzione può essere eseguita con successo solo da
+\noindent la funzione può essere eseguita con successo solo da
 un processo nella stessa sessione e con lo stesso terminale di controllo. 
 
 Come accennato in sez.~\ref{sec:sess_job_control_overview}, tutti i processi
 (e relativi raggruppamenti) che non fanno parte del gruppo di
 \textit{foreground} sono detti in \textit{background}; se uno si essi cerca di
-accedere al terminale di controllo provocherà l'invio da parte del kernel di
+accedere al terminale di controllo provocherà l'invio da parte del kernel di
 uno dei due segnali \const{SIGTTIN} o \const{SIGTTOU} (a seconda che l'accesso
 sia stato in lettura o scrittura) a tutto il suo \itindex{process~group}
 \textit{process group}; dato che il comportamento di default di questi segnali
-(si riveda quanto esposto in sez.~\ref{sec:sig_job_control}) è di fermare il
+(si riveda quanto esposto in sez.~\ref{sec:sig_job_control}) è di fermare il
 processo, di norma questo comporta che tutti i membri del gruppo verranno
 fermati, ma non si avranno condizioni di errore.\footnote{la shell in genere
   notifica comunque un avvertimento, avvertendo la presenza di processi
-  bloccati grazie all'uso di \func{waitpid}.} Se però si bloccano o ignorano i
+  bloccati grazie all'uso di \func{waitpid}.} Se però si bloccano o ignorano i
 due segnali citati, le funzioni di lettura e scrittura falliranno con un
 errore di \errcode{EIO}.
 
-Un processo può controllare qual è il gruppo di \textit{foreground} associato
-ad un terminale con la funzione \funcd{tcgetpgrp}, il cui prototipo è:
+Un processo può controllare qual è il gruppo di \textit{foreground} associato
+ad un terminale con la funzione \funcd{tcgetpgrp}, il cui prototipo è:
 \begin{functions}
   \headdecl{unistd.h} \headdecl{termios.h}
   
@@ -374,9 +374,9 @@ ad un terminale con la funzione \funcd{tcgetpgrp}, il cui prototipo 
   \textit{foreground} del terminale associato al file descriptor \param{fd}.
   \bodydesc{La funzione restituisce in caso di successo il \acr{pgid} del
     gruppo di \textit{foreground}, e -1 in caso di errore, nel qual caso
-    \var{errno} assumerà i valori:
+    \var{errno} assumerà i valori:
     \begin{errlist}
-    \item[\errcode{ENOTTY}] non c'è un terminale di controllo o \param{fd} non
+    \item[\errcode{ENOTTY}] non c'è un terminale di controllo o \param{fd} non
       corrisponde al terminale di controllo del processo chiamante.
     \end{errlist}
     ed inoltre \errval{EBADF} ed \errval{ENOSYS}. 
@@ -387,20 +387,20 @@ Si noti come entrambe le funzioni usino come argomento il valore di un file
 descriptor, il risultato comunque non dipende dal file descriptor che si usa
 ma solo dal terminale cui fa riferimento; il kernel inoltre permette a ciascun
 processo di accedere direttamente al suo terminale di controllo attraverso il
-file speciale \file{/dev/tty}, che per ogni processo è un sinonimo per il
+file speciale \file{/dev/tty}, che per ogni processo è un sinonimo per il
 proprio terminale di controllo.  Questo consente anche a processi che possono
 aver rediretto l'output di accedere al terminale di controllo, pur non
-disponendo più del file descriptor originario; un caso tipico è il programma
+disponendo più del file descriptor originario; un caso tipico è il programma
 \cmd{crypt} che accetta la redirezione sullo standard input di un file da
 decifrare, ma deve poi leggere la password dal terminale.
 
-Un'altra caratteristica del terminale di controllo usata nel job control è che
+Un'altra caratteristica del terminale di controllo usata nel job control è che
 utilizzando su di esso le combinazioni di tasti speciali (\texttt{C-z},
-\texttt{C-c}, \texttt{C-y} e \texttt{C-|}) si farà sì che il kernel invii i
+\texttt{C-c}, \texttt{C-y} e \texttt{C-|}) si farà sì che il kernel invii i
 corrispondenti segnali (rispettivamente \const{SIGTSTP}, \const{SIGINT},
 \const{SIGQUIT} e \const{SIGTERM}, trattati in sez.~\ref{sec:sig_job_control})
 a tutti i processi del raggruppamento di \textit{foreground}; in questo modo
-la shell può gestire il blocco e l'interruzione dei vari comandi.
+la shell può gestire il blocco e l'interruzione dei vari comandi.
 
 
 Per completare la trattazione delle caratteristiche del job control legate al
@@ -411,64 +411,64 @@ termine che viene usato per indicare la condizione in cui il terminale diventa
 inutilizzabile, (letteralmente sarebbe \textsl{impiccagione}).
 
 Quando si verifica questa condizione, ad esempio se si interrompe la linea, o
-va giù la rete o più semplicemente si chiude forzatamente la finestra di
-terminale su cui si stava lavorando, il kernel provvederà ad inviare il
+va giù la rete o più semplicemente si chiude forzatamente la finestra di
+terminale su cui si stava lavorando, il kernel provvederà ad inviare il
 segnale di \const{SIGHUP} al processo di controllo. L'azione preimpostata in
-questo caso è la terminazione del processo, il problema che si pone è cosa
-accade agli altri processi nella sessione, che non han più un processo di
+questo caso è la terminazione del processo, il problema che si pone è cosa
+accade agli altri processi nella sessione, che non han più un processo di
 controllo che possa gestire l'accesso al terminale, che potrebbe essere
 riutilizzato per qualche altra sessione.
 
 Lo standard POSIX.1 prevede che quando il processo di controllo termina, che
-ciò avvenga o meno per un \textit{hungup} del terminale (ad esempio si
+ciò avvenga o meno per un \textit{hungup} del terminale (ad esempio si
 potrebbe terminare direttamente la shell con \cmd{kill}) venga inviato un
 segnale di \const{SIGHUP} ai processi del raggruppamento di foreground. In
-questo modo essi potranno essere avvisati che non esiste più un processo in
-grado di gestire il terminale (di norma tutto ciò comporta la terminazione
+questo modo essi potranno essere avvisati che non esiste più un processo in
+grado di gestire il terminale (di norma tutto ciò comporta la terminazione
 anche di questi ultimi).
 
-Restano però gli eventuali processi in background, che non ricevono il
-segnale; in effetti se il terminale non dovesse più servire essi potrebbero
+Restano però gli eventuali processi in background, che non ricevono il
+segnale; in effetti se il terminale non dovesse più servire essi potrebbero
 proseguire fino al completamento della loro esecuzione; ma si pone il problema
 di come gestire quelli che sono bloccati, o che si bloccano nell'accesso al
 terminale, in assenza di un processo che sia in grado di effettuare il
 controllo dello stesso.
 
-Questa è la situazione in cui si ha quello che viene chiamato un
+Questa è la situazione in cui si ha quello che viene chiamato un
 \itindex{process~group~orphaned} \textit{orphaned process group}. Lo standard
 POSIX.1 lo definisce come un \itindex{process~group} \textit{process group} i
 cui processi hanno come padri esclusivamente o altri processi nel
 raggruppamento, o processi fuori della sessione.  Lo standard prevede inoltre
-che se la terminazione di un processo fa sì che un raggruppamento di processi
+che se la terminazione di un processo fa sì che un raggruppamento di processi
 diventi orfano e se i suoi membri sono bloccati, ad essi vengano inviati in
 sequenza i segnali di \const{SIGHUP} e \const{SIGCONT}.
 
-La definizione può sembrare complicata, e a prima vista non è chiaro cosa
-tutto ciò abbia a che fare con il problema della terminazione del processo di
+La definizione può sembrare complicata, e a prima vista non è chiaro cosa
+tutto ciò abbia a che fare con il problema della terminazione del processo di
 controllo.  Consideriamo allora cosa avviene di norma nel \textit{job
   control}: una sessione viene creata con \func{setsid} che crea anche un
 nuovo \itindex{process~group} \textit{process group}: per definizione
-quest'ultimo è sempre \itindex{process~group~orphaned} \textsl{orfano}, dato
-che il padre del leader di sessione è fuori dalla stessa e il nuovo
+quest'ultimo è sempre \itindex{process~group~orphaned} \textsl{orfano}, dato
+che il padre del leader di sessione è fuori dalla stessa e il nuovo
 \textit{process group} \itindex{process~group} contiene solo il leader di
-sessione. Questo è un caso limite, e non viene emesso nessun segnale perché
+sessione. Questo è un caso limite, e non viene emesso nessun segnale perché
 quanto previsto dallo standard riguarda solo i raggruppamenti che diventano
 orfani in seguito alla terminazione di un processo.\footnote{l'emissione dei
   segnali infatti avviene solo nella fase di uscita del processo, come una
   delle operazioni legate all'esecuzione di \func{\_exit}, secondo quanto
   illustrato in sez.~\ref{sec:proc_termination}.}
 
-Il leader di sessione provvederà a creare nuovi raggruppamenti che a questo
+Il leader di sessione provvederà a creare nuovi raggruppamenti che a questo
 punto non sono orfani in quanto esso resta padre per almeno uno dei processi
 del gruppo (gli altri possono derivare dal primo). Alla terminazione del
-leader di sessione però avremo che, come visto in
+leader di sessione però avremo che, come visto in
 sez.~\ref{sec:proc_termination}, tutti i suoi figli vengono adottati da
-\cmd{init}, che è fuori dalla sessione. Questo renderà orfani tutti i process
+\cmd{init}, che è fuori dalla sessione. Questo renderà orfani tutti i process
 group creati direttamente dal leader di sessione (a meno di non aver spostato
 con \func{setpgid} un processo da un gruppo ad un altro, cosa che di norma non
 viene fatta) i quali riceveranno, nel caso siano bloccati, i due segnali;
-\const{SIGCONT} ne farà proseguire l'esecuzione, ed essendo stato nel
-frattempo inviato anche \const{SIGHUP}, se non c'è un gestore per
+\const{SIGCONT} ne farà proseguire l'esecuzione, ed essendo stato nel
+frattempo inviato anche \const{SIGHUP}, se non c'è un gestore per
 quest'ultimo, i processi bloccati verranno automaticamente terminati.
 
 
@@ -476,8 +476,8 @@ quest'ultimo, i processi bloccati verranno automaticamente terminati.
 \subsection{Dal login alla shell}
 \label{sec:sess_login}
 
-L'organizzazione del sistema del job control è strettamente connessa alle
-modalità con cui un utente accede al sistema per dare comandi, collegandosi ad
+L'organizzazione del sistema del job control è strettamente connessa alle
+modalità con cui un utente accede al sistema per dare comandi, collegandosi ad
 esso con un terminale, che sia questo realmente tale, come un VT100 collegato
 ad una seriale o virtuale, come quelli associati a schermo e tastiera o ad una
 connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
@@ -487,10 +487,10 @@ fine le differenze sono\footnote{in generale nel caso di login via rete o di
 i file standard (vedi sez.~\ref{sec:file_std_descr}) per l'I/O, tratteremo
 solo il caso classico del terminale.
 
-Abbiamo già brevemente illustrato in sez.~\ref{sec:intro_kern_and_sys} le
-modalità con cui il sistema si avvia, e di come, a partire da \cmd{init},
-vengano lanciati tutti gli altri processi. Adesso vedremo in maniera più
-dettagliata le modalità con cui il sistema arriva a fornire ad un utente la
+Abbiamo già brevemente illustrato in sez.~\ref{sec:intro_kern_and_sys} le
+modalità con cui il sistema si avvia, e di come, a partire da \cmd{init},
+vengano lanciati tutti gli altri processi. Adesso vedremo in maniera più
+dettagliata le modalità con cui il sistema arriva a fornire ad un utente la
 shell che gli permette di lanciare i suoi comandi su un terminale.
 
 Nella maggior parte delle distribuzioni di GNU/Linux\footnote{fa eccezione la
@@ -498,14 +498,14 @@ Nella maggior parte delle distribuzioni di GNU/Linux\footnote{fa eccezione la
   altre distribuzioni dedicate a compiti limitati e specifici.}  viene usata
 la procedura di avvio di System V; questa prevede che \cmd{init} legga dal
 file di configurazione \conffile{/etc/inittab} quali programmi devono essere
-lanciati, ed in quali modalità, a seconda del cosiddetto \textit{run level},
+lanciati, ed in quali modalità, a seconda del cosiddetto \textit{run level},
 anch'esso definito nello stesso file.
 
 Tralasciando la descrizione del sistema dei run level, (per il quale si
 rimanda alla lettura delle pagine di manuale di \cmd{init} e di
-\file{inittab}) quello che comunque viene sempre fatto è di eseguire almeno
+\file{inittab}) quello che comunque viene sempre fatto è di eseguire almeno
 una istanza di un programma che permetta l'accesso ad un terminale. Uno schema
-di massima della procedura è riportato in fig.~\ref{fig:sess_term_login}.
+di massima della procedura è riportato in fig.~\ref{fig:sess_term_login}.
 
 \begin{figure}[htb]
   \centering
@@ -522,7 +522,7 @@ presenta un'interfaccia comune su un apposito file di dispositivo.
 Per controllare un terminale si usa di solito il programma \cmd{getty} (od una
 delle sue varianti), che permette di mettersi in ascolto su uno di questi
 dispositivi. Alla radice della catena che porta ad una shell per i comandi
-perciò c'è sempre \cmd{init} che esegue prima una \func{fork} e poi una
+perciò c'è sempre \cmd{init} che esegue prima una \func{fork} e poi una
 \func{exec} per lanciare una istanza di questo programma su un terminale, il
 tutto ripetuto per ciascuno dei terminali che si hanno a disposizione (o per
 un certo numero di essi, nel caso delle console virtuali), secondo quanto
@@ -533,14 +533,14 @@ Quando viene lanciato da \cmd{init} il programma parte con i privilegi di
 amministratore e con un ambiente vuoto; \cmd{getty} si cura di chiamare
 \func{setsid} per creare una nuova sessione ed un nuovo
 \itindex{process~group} \textit{process group}, e di aprire il terminale (che
-così diventa il terminale di controllo della sessione) in lettura sullo
+così diventa il terminale di controllo della sessione) in lettura sullo
 standard input ed in scrittura sullo standard output e sullo standard error;
-inoltre effettuerà, qualora servano, ulteriori impostazioni.\footnote{ad
-  esempio, come qualcuno si sarà accorto scrivendo un nome di login in
-  maiuscolo, può effettuare la conversione automatica dell'input in minuscolo,
-  ponendosi in una modalità speciale che non distingue fra i due tipi di
+inoltre effettuerà, qualora servano, ulteriori impostazioni.\footnote{ad
+  esempio, come qualcuno si sarà accorto scrivendo un nome di login in
+  maiuscolo, può effettuare la conversione automatica dell'input in minuscolo,
+  ponendosi in una modalità speciale che non distingue fra i due tipi di
   caratteri (a beneficio di alcuni vecchi terminali che non supportavano le
-  minuscole).}  Alla fine il programma stamperà un messaggio di benvenuto per
+  minuscole).}  Alla fine il programma stamperà un messaggio di benvenuto per
 poi porsi in attesa dell'immissione del nome di un utente.
 
 Una volta che si sia immesso il nome di login \cmd{getty} esegue direttamente
@@ -557,34 +557,34 @@ utenti,\footnote{in genere viene chiamata \func{getpwnam}, che abbiamo visto
   dal database degli utenti.} e richiede una password. Se l'utente non esiste
 o se la password non corrisponde\footnote{il confronto non viene effettuato
   con un valore in chiaro; quanto immesso da terminale viene invece a sua
-  volta criptato, ed è il risultato che viene confrontato con il valore che
+  volta criptato, ed è il risultato che viene confrontato con il valore che
   viene mantenuto nel database degli utenti.} la richiesta viene ripetuta un
 certo numero di volte dopo di che \cmd{login} esce ed \cmd{init} provvede a
 rilanciare un'altra istanza di \cmd{getty}.
 
 Se invece la password corrisponde \cmd{login} esegue \func{chdir} per settare
 la \textit{home directory} dell'utente, cambia i diritti di accesso al
-terminale (con \func{chown} e \func{chmod}) per assegnarne la titolarità
+terminale (con \func{chown} e \func{chmod}) per assegnarne la titolarità
 all'utente ed al suo gruppo principale, assegnandogli al contempo i diritti di
 lettura e scrittura. Inoltre il programma provvede a costruire gli opportuni
 valori per le variabili di ambiente, come \texttt{HOME}, \texttt{SHELL}, ecc.
 Infine attraverso l'uso di \func{setuid}, \func{setgid} e \func{initgroups}
-verrà cambiata l'identità del proprietario del processo, infatti, come
+verrà cambiata l'identità del proprietario del processo, infatti, come
 spiegato in sez.~\ref{sec:proc_setuid}, avendo invocato tali funzioni con i
 privilegi di amministratore, tutti gli user-ID ed i group-ID (reali, effettivi
 e salvati) saranno impostati a quelli dell'utente.
 
-A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
+A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
 iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
-ad eseguire con un'altra \func{exec} la shell, che si troverà con un ambiente
-già pronto con i file standard di sez.~\ref{sec:file_std_descr} impostati sul
+ad eseguire con un'altra \func{exec} la shell, che si troverà con un ambiente
+già pronto con i file standard di sez.~\ref{sec:file_std_descr} impostati sul
 terminale, e pronta, nel ruolo di leader di sessione e di processo di
 controllo per il terminale, a gestire l'esecuzione dei comandi come illustrato
 in sez.~\ref{sec:sess_job_control_overview}. 
 
-Dato che il processo padre resta sempre \cmd{init} quest'ultimo potrà
+Dato che il processo padre resta sempre \cmd{init} quest'ultimo potrà
 provvedere, ricevendo un \const{SIGCHLD} all'uscita della shell quando la
-sessione di lavoro è terminata, a rilanciare \cmd{getty} sul terminale per
+sessione di lavoro è terminata, a rilanciare \cmd{getty} sul terminale per
 ripetere da capo tutto il procedimento.
 
 
@@ -598,7 +598,7 @@ operazioni di sistema (come l'esecuzione dei comandi periodici, o la consegna
 della posta, ed in generale tutti i programmi di servizio) che non hanno
 niente a che fare con la gestione diretta dei comandi dell'utente.
 
-Questi programmi, che devono essere eseguiti in modalità non interattiva e
+Questi programmi, che devono essere eseguiti in modalità non interattiva e
 senza nessun intervento dell'utente, sono normalmente chiamati
 \textsl{demoni}, (o \textit{daemons}), nome ispirato dagli omonimi spiritelli
 della mitologia greca che svolgevano compiti che gli dei trovavano noiosi, di
@@ -606,10 +606,10 @@ cui parla anche Socrate (che sosteneva di averne uno al suo servizio).
 
 %TODO ricontrollare, i miei ricordi di filosofia sono piuttosto datati.
 
-Se però si lancia un programma demone dalla riga di comando in un sistema che
-supporta, come Linux, il \textit{job control} esso verrà comunque associato ad
+Se però si lancia un programma demone dalla riga di comando in un sistema che
+supporta, come Linux, il \textit{job control} esso verrà comunque associato ad
 un terminale di controllo e mantenuto all'interno di una sessione, e anche se
-può essere mandato in background e non eseguire più nessun I/O su terminale,
+può essere mandato in background e non eseguire più nessun I/O su terminale,
 si avranno comunque tutte le conseguenze che abbiamo appena visto in
 sez.~\ref{sec:sess_ctrl_term} (in particolare l'invio dei segnali in
 corrispondenza dell'uscita del leader di sessione).
@@ -623,68 +623,68 @@ prescrizioni\footnote{ad esempio sia Stevens in \cite{APUE}, che la
   identiche.} da seguire quando si scrive un demone.
 
 Pertanto, quando si lancia un programma che deve essere eseguito come demone
-occorrerà predisporlo in modo che esso compia le seguenti azioni:
+occorrerà predisporlo in modo che esso compia le seguenti azioni:
 \begin{enumerate}
 \item Eseguire una \func{fork} e terminare immediatamente il processo padre
   proseguendo l'esecuzione nel figlio.  In questo modo si ha la certezza che
-  il figlio non è un \itindex{process~group~leader} \textit{process group
-    leader}, (avrà il \acr{pgid} del padre, ma un \acr{pid} diverso) e si può
-  chiamare \func{setsid} con successo. Inoltre la shell considererà terminato
+  il figlio non è un \itindex{process~group~leader} \textit{process group
+    leader}, (avrà il \acr{pgid} del padre, ma un \acr{pid} diverso) e si può
+  chiamare \func{setsid} con successo. Inoltre la shell considererà terminato
   il comando all'uscita del padre.
 \item Eseguire \func{setsid} per creare una nuova sessione ed un nuovo
   raggruppamento di cui il processo diventa automaticamente il leader, che
-  però non ha associato nessun terminale di controllo.
+  però non ha associato nessun terminale di controllo.
 \item Assicurarsi che al processo non venga associato in seguito nessun nuovo
-  terminale di controllo; questo può essere fatto sia avendo cura di usare
+  terminale di controllo; questo può essere fatto sia avendo cura di usare
   sempre l'opzione \const{O\_NOCTTY} nell'aprire i file di terminale, che
   eseguendo una ulteriore \func{fork} uscendo nel padre e proseguendo nel
-  figlio. In questo caso, non essendo più quest'ultimo un leader di sessione
-  non potrà ottenere automaticamente un terminale di controllo.
+  figlio. In questo caso, non essendo più quest'ultimo un leader di sessione
+  non potrà ottenere automaticamente un terminale di controllo.
 \item Eseguire una \func{chdir} per impostare la directory di lavoro del
   processo (su \file{/} o su una directory che contenga dei file necessari per
-  il programma), per evitare che la directory da cui si è lanciato il processo
+  il programma), per evitare che la directory da cui si è lanciato il processo
   resti in uso e non sia possibile rimuoverla o smontare il filesystem che la
   contiene.
 \item Impostare la \itindex{umask} maschera dei permessi (di solito con
   \code{umask(0)}) in modo da non essere dipendenti dal valore ereditato da
   chi ha lanciato originariamente il processo.
-\item Chiudere tutti i file aperti che non servono più (in generale tutti); in
+\item Chiudere tutti i file aperti che non servono più (in generale tutti); in
   particolare vanno chiusi i file standard che di norma sono ancora associati
-  al terminale (un'altra opzione è quella di redirigerli verso
+  al terminale (un'altra opzione è quella di redirigerli verso
   \file{/dev/null}).
 \end{enumerate}
 
 
 In Linux buona parte di queste azioni possono venire eseguite invocando la
 funzione \funcd{daemon}, introdotta per la prima volta in BSD4.4; il suo
-prototipo è:
+prototipo è:
 \begin{prototype}{unistd.h}{int daemon(int nochdir, int noclose)}
   Esegue le operazioni che distaccano il processo dal terminale di controllo e
   lo fanno girare come demone.
   
   \bodydesc{La funzione restituisce (nel nuovo processo) 0 in caso di
-    successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
+    successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
     valori impostati dalle sottostanti \func{fork} e \func{setsid}.}
 \end{prototype}
 
 La funzione esegue una \func{fork}, per uscire subito, con \func{\_exit}, nel
 padre, mentre l'esecuzione prosegue nel figlio che esegue subito una
 \func{setsid}. In questo modo si compiono automaticamente i passi 1 e 2 della
-precedente lista. Se \param{nochdir} è nullo la funzione imposta anche la
-directory di lavoro su \file{/}, se \param{noclose} è nullo i file standard
+precedente lista. Se \param{nochdir} è nullo la funzione imposta anche la
+directory di lavoro su \file{/}, se \param{noclose} è nullo i file standard
 vengono rediretti su \file{/dev/null} (corrispondenti ai passi 4 e 6); in caso
 di valori non nulli non viene eseguita nessuna altra azione.
 
-Dato che un programma demone non può più accedere al terminale, si pone il
-problema di come fare per la notifica di eventuali errori, non potendosi più
-utilizzare lo standard error; per il normale I/O infatti ciascun demone avrà
-le sue modalità di interazione col sistema e gli utenti a seconda dei compiti
-e delle funzionalità che sono previste; ma gli errori devono normalmente
+Dato che un programma demone non può più accedere al terminale, si pone il
+problema di come fare per la notifica di eventuali errori, non potendosi più
+utilizzare lo standard error; per il normale I/O infatti ciascun demone avrà
+le sue modalità di interazione col sistema e gli utenti a seconda dei compiti
+e delle funzionalità che sono previste; ma gli errori devono normalmente
 essere notificati all'amministratore del sistema.
 
-Una soluzione può essere quella di scrivere gli eventuali messaggi su uno
+Una soluzione può essere quella di scrivere gli eventuali messaggi su uno
 specifico file (cosa che a volte viene fatta comunque) ma questo comporta il
-grande svantaggio che l'amministratore dovrà tenere sotto controllo un file
+grande svantaggio che l'amministratore dovrà tenere sotto controllo un file
 diverso per ciascun demone, e che possono anche generarsi conflitti di nomi.
 Per questo in BSD4.2 venne introdotto un servizio di sistema, il
 \textit{syslog}, che oggi si trova su tutti i sistemi Unix, e che permettesse
@@ -693,7 +693,7 @@ standardizzata.
 
 Il servizio prevede vari meccanismi di notifica, e, come ogni altro servizio
 in un sistema unix-like, viene gestito attraverso un apposito programma,
-\cmd{syslogd}, che è anch'esso un \textsl{demone}. In generale i messaggi di
+\cmd{syslogd}, che è anch'esso un \textsl{demone}. In generale i messaggi di
 errore vengono raccolti dal file speciale \file{/dev/log}, un socket locale
 (vedi sez.~\ref{sec:sock_sa_local}) dedicato a questo scopo, o via rete, con
 un socket UDP, o da un apposito demone, \cmd{klogd}, che estrae i messaggi del
@@ -705,10 +705,10 @@ kernel.\footnote{i messaggi del kernel sono tenuti in un buffer circolare e
 Il servizio permette poi di trattare i vari messaggi classificandoli
 attraverso due indici; il primo, chiamato \textit{facility}, suddivide in
 diverse categorie i vari demoni in modo di raggruppare i messaggi provenienti
-da operazioni che hanno attinenza fra loro, ed è organizzato in sottosistemi
+da operazioni che hanno attinenza fra loro, ed è organizzato in sottosistemi
 (kernel, posta elettronica, demoni di stampa, ecc.). Il secondo, chiamato
 \textit{priority}, identifica l'importanza dei vari messaggi, e permette di
-classificarli e differenziare le modalità di notifica degli stessi.
+classificarli e differenziare le modalità di notifica degli stessi.
 
 Il sistema di \textit{syslog} attraverso \cmd{syslogd} provvede poi a
 riportare i messaggi all'amministratore attraverso una serie differenti
@@ -720,21 +720,21 @@ meccanismi come:
 \item inviare ad un altro demone (anche via rete).
 \item scartare.
 \end{itemize*}
-secondo le modalità che questo preferisce e che possono essere impostate
+secondo le modalità che questo preferisce e che possono essere impostate
 attraverso il file di configurazione \conffile{/etc/syslog.conf} (maggiori
 dettagli si possono trovare sulle pagine di manuale per questo file e per
 \cmd{syslogd}).
 
 Le \acr{glibc} definiscono una serie di funzioni standard con cui un processo
-può accedere in maniera generica al servizio di \textit{syslog}, che però
+può accedere in maniera generica al servizio di \textit{syslog}, che però
 funzionano solo localmente; se si vogliono inviare i messaggi ad un altro
 sistema occorre farlo esplicitamente con un socket UDP, o utilizzare le
-capacità di reinvio del servizio.
+capacità di reinvio del servizio.
 
-La prima funzione definita dall'interfaccia è \funcd{openlog}, che apre una
-connessione al servizio di \textit{syslog}; essa in generale non è necessaria
+La prima funzione definita dall'interfaccia è \funcd{openlog}, che apre una
+connessione al servizio di \textit{syslog}; essa in generale non è necessaria
 per l'uso del servizio, ma permette di impostare alcuni valori che controllano
-gli effetti delle chiamate successive; il suo prototipo è:
+gli effetti delle chiamate successive; il suo prototipo è:
 \begin{prototype}{syslog.h}{void openlog(const char *ident, int option, 
 int facility)}
 
@@ -743,18 +743,18 @@ Apre una connessione al sistema di \textit{syslog}.
 \bodydesc{La funzione non restituisce nulla.}
 \end{prototype}
 
-La funzione permette di specificare, tramite \param{ident}, l'identità di chi
+La funzione permette di specificare, tramite \param{ident}, l'identità di chi
 ha inviato il messaggio (di norma si passa il nome del programma, come
-specificato da \code{argv[0]}); la stringa verrà preposta all'inizio di ogni
+specificato da \code{argv[0]}); la stringa verrà preposta all'inizio di ogni
 messaggio. Si tenga presente che il valore di \param{ident} che si passa alla
-funzione è un puntatore, se la stringa cui punta viene cambiata lo sarà pure
+funzione è un puntatore, se la stringa cui punta viene cambiata lo sarà pure
 nei successivi messaggi, e se viene cancellata i risultati potranno essere
-impredicibili, per questo è sempre opportuno usare una stringa costante. 
+impredicibili, per questo è sempre opportuno usare una stringa costante. 
 
 L'argomento \param{facility} permette invece di preimpostare per le successive
 chiamate l'omonimo indice che classifica la categoria del messaggio.
-L'argomento è interpretato come una maschera binaria, e pertanto è possibile
-inviare i messaggi su più categorie alla volta; i valori delle costanti che
+L'argomento è interpretato come una maschera binaria, e pertanto è possibile
+inviare i messaggi su più categorie alla volta; i valori delle costanti che
 identificano ciascuna categoria sono riportati in
 tab.~\ref{tab:sess_syslog_facility}, il valore di \param{facility} deve essere
 specificato con un OR aritmetico.
@@ -768,7 +768,7 @@ specificato con un OR aritmetico.
     \hline
     \hline
     \const{LOG\_AUTH}     & Messaggi relativi ad autenticazione e sicurezza,
-                            obsoleto, è sostituito da \const{LOG\_AUTHPRIV}.\\
+                            obsoleto, è sostituito da \const{LOG\_AUTHPRIV}.\\
     \const{LOG\_AUTHPRIV} & Sostituisce \const{LOG\_AUTH}.\\
     \const{LOG\_CRON}     & Messaggi dei demoni di gestione dei comandi
                             programmati (\cmd{cron} e \cmd{at}).\\
@@ -792,7 +792,7 @@ specificato con un OR aritmetico.
 \end{table}
 
 L'argomento \param{option} serve invece per controllare il comportamento della
-funzione \func{openlog} e delle modalità con cui le successive chiamate
+funzione \func{openlog} e delle modalità con cui le successive chiamate
 scriveranno i messaggi, esso viene specificato come maschera binaria composta
 con un OR aritmetico di una qualunque delle costanti riportate in
 tab.~\ref{tab:sess_openlog_option}.
@@ -819,38 +819,38 @@ tab.~\ref{tab:sess_openlog_option}.
 \label{tab:sess_openlog_option}
 \end{table}
 
-La funzione che si usa per generare un messaggio è \funcd{syslog}, dato che
-l'uso di \func{openlog} è opzionale, sarà quest'ultima a provvede a chiamare la
-prima qualora ciò non sia stato fatto (nel qual caso il valore di
-\param{ident} è nullo). Il suo prototipo è:
+La funzione che si usa per generare un messaggio è \funcd{syslog}, dato che
+l'uso di \func{openlog} è opzionale, sarà quest'ultima a provvede a chiamare la
+prima qualora ciò non sia stato fatto (nel qual caso il valore di
+\param{ident} è nullo). Il suo prototipo è:
 \begin{prototype}{syslog.h}
 {void syslog(int priority, const char *format, ...)}
 
-Genera un messaggio di priorità \param{priority}.
+Genera un messaggio di priorità \param{priority}.
 
 \bodydesc{La funzione non restituisce nulla.}
 \end{prototype}
 
-Il comportamento della funzione è analogo quello di \func{printf}, e il valore
-dell'argomento \param{format} è identico a quello descritto nella pagina di
-manuale di quest'ultima (per i valori principali si può vedere la trattazione
-sommaria che se ne è fatto in sez.~\ref{sec:file_formatted_io}); l'unica
-differenza è che la sequenza \val{\%m} viene rimpiazzata dalla stringa
+Il comportamento della funzione è analogo quello di \func{printf}, e il valore
+dell'argomento \param{format} è identico a quello descritto nella pagina di
+manuale di quest'ultima (per i valori principali si può vedere la trattazione
+sommaria che se ne è fatto in sez.~\ref{sec:file_formatted_io}); l'unica
+differenza è che la sequenza \val{\%m} viene rimpiazzata dalla stringa
 restituita da \code{strerror(errno)}. Gli argomenti seguenti i primi due
 devono essere forniti secondo quanto richiesto da \param{format}.
 
 L'argomento \param{priority} permette di impostare sia la \textit{facility}
-che la \textit{priority} del messaggio. In realtà viene prevalentemente usato
+che la \textit{priority} del messaggio. In realtà viene prevalentemente usato
 per specificare solo quest'ultima in quanto la prima viene di norma 
-preimpostata con \func{openlog}. La priorità è indicata con un valore
+preimpostata con \func{openlog}. La priorità è indicata con un valore
 numerico\footnote{le \acr{glibc}, seguendo POSIX.1-2001, prevedono otto
-  diverse priorità ordinate da 0 a 7, in ordine di importanza decrescente;
+  diverse priorità ordinate da 0 a 7, in ordine di importanza decrescente;
   questo comporta che i tre bit meno significativi dell'argomento
-  \param{priority} sono occupati da questo valore, mentre i restanti bit più
+  \param{priority} sono occupati da questo valore, mentre i restanti bit più
   significativi vengono usati per specificare la \textit{facility}.}
 specificabile attraverso le costanti riportate in
 tab.~\ref{tab:sess_syslog_priority}.  Nel caso si voglia specificare anche la
-\textit{facility} basta eseguire un OR aritmetico del valore della priorità
+\textit{facility} basta eseguire un OR aritmetico del valore della priorità
 con la maschera binaria delle costanti di tab.~\ref{tab:sess_syslog_facility}.
 
 \begin{table}[htb]
@@ -861,11 +861,11 @@ con la maschera binaria delle costanti di tab.~\ref{tab:sess_syslog_facility}.
     \textbf{Valore}& \textbf{Significato}\\
     \hline
     \hline
-    \const{LOG\_EMERG}   & Il sistema è inutilizzabile.\\
-    \const{LOG\_ALERT}   & C'è una emergenza che richiede intervento
+    \const{LOG\_EMERG}   & Il sistema è inutilizzabile.\\
+    \const{LOG\_ALERT}   & C'è una emergenza che richiede intervento
                            immediato.\\
-    \const{LOG\_CRIT}    & Si è in una condizione critica.\\
-    \const{LOG\_ERR}     & Si è in una condizione di errore.\\
+    \const{LOG\_CRIT}    & Si è in una condizione critica.\\
+    \const{LOG\_ERR}     & Si è in una condizione di errore.\\
     \const{LOG\_WARNING} & Messaggio di avvertimento.\\
     \const{LOG\_NOTICE}  & Notizia significativa relativa al comportamento.\\
     \const{LOG\_INFO}    & Messaggio informativo.\\
@@ -878,7 +878,7 @@ con la maschera binaria delle costanti di tab.~\ref{tab:sess_syslog_facility}.
 \end{table}
 
 Una ulteriore funzione, \funcd{setlogmask}, permette di filtrare
-preliminarmente i messaggi in base alla loro priorità; il suo prototipo è:
+preliminarmente i messaggi in base alla loro priorità; il suo prototipo è:
 \begin{prototype}{syslog.h}{int setlogmask(int mask)}
 
 Imposta la maschera dei log al valore specificato.
@@ -887,25 +887,25 @@ Imposta la maschera dei log al valore specificato.
 \end{prototype}
 
 Le funzioni di gestione mantengono per ogni processo una maschera che determina
-quale delle chiamate effettuate a \func{syslog} verrà effettivamente
-registrata. La registrazione viene disabilitata per tutte quelle priorità che
+quale delle chiamate effettuate a \func{syslog} verrà effettivamente
+registrata. La registrazione viene disabilitata per tutte quelle priorità che
 non rientrano nella maschera; questa viene impostata usando la macro
-\macro{LOG\_MASK(p)} dove \code{p} è una delle costanti di
-tab.~\ref{tab:sess_syslog_priority}. É inoltre disponibile anche la macro
+\macro{LOG\_MASK(p)} dove \code{p} è una delle costanti di
+tab.~\ref{tab:sess_syslog_priority}. É inoltre disponibile anche la macro
 \macro{LOG\_UPTO(p)} che permette di specificare automaticamente tutte le
-priorità fino ad un certo valore.
+priorità fino ad un certo valore.
 
 
 
 \section{L'I/O su terminale}
 \label{sec:sess_terminal_io}
 
-Benché come ogni altro dispositivo i terminali siano accessibili come file,
+Benché come ogni altro dispositivo i terminali siano accessibili come file,
 essi hanno assunto storicamente (essendo stati a lungo l'unico modo di
-accedere al sistema) una loro rilevanza specifica, che abbiamo già avuto modo
+accedere al sistema) una loro rilevanza specifica, che abbiamo già avuto modo
 di incontrare nella precedente sezione.
 
-Esamineremo qui le peculiarità dell'I/O eseguito sui terminali, che per la
+Esamineremo qui le peculiarità dell'I/O eseguito sui terminali, che per la
 loro particolare natura presenta delle differenze rispetto ai normali file su
 disco e agli altri dispositivi.
 
@@ -917,22 +917,22 @@ disco e agli altri dispositivi.
 I terminali sono una classe speciale di dispositivi a caratteri (si ricordi la
 classificazione di sez.~\ref{sec:file_file_types}); un terminale ha infatti una
 caratteristica che lo contraddistingue da un qualunque altro dispositivo, e
-cioè che è destinato a gestire l'interazione con un utente (deve essere cioè
+cioè che è destinato a gestire l'interazione con un utente (deve essere cioè
 in grado di fare da terminale di controllo per una sessione), che comporta la
-presenza di ulteriori capacità.
+presenza di ulteriori capacità.
 
-L'interfaccia per i terminali è una delle più oscure e complesse, essendosi
+L'interfaccia per i terminali è una delle più oscure e complesse, essendosi
 stratificata dagli inizi dei sistemi Unix fino ad oggi. Questo comporta una
-grande quantità di opzioni e controlli relativi ad un insieme di
-caratteristiche (come ad esempio la velocità della linea) necessarie per
+grande quantità di opzioni e controlli relativi ad un insieme di
+caratteristiche (come ad esempio la velocità della linea) necessarie per
 dispositivi, come i terminali seriali, che al giorno d'oggi sono praticamente
 in disuso.
 
 Storicamente i primi terminali erano appunto terminali di telescriventi
 (\textit{teletype}), da cui deriva sia il nome dell'interfaccia, \textit{TTY},
 che quello dei relativi file di dispositivo, che sono sempre della forma
-\texttt{/dev/tty*}.\footnote{ciò vale solo in parte per i terminali virtuali,
-  essi infatti hanno due lati, un \textit{master}, che può assumere i nomi
+\texttt{/dev/tty*}.\footnote{ciò vale solo in parte per i terminali virtuali,
+  essi infatti hanno due lati, un \textit{master}, che può assumere i nomi
   \file{/dev/pty[p-za-e][0-9a-f]} ed un corrispondente \textit{slave} con nome
   \file{/dev/tty[p-za-e][0-9a-f]}.}  Oggi essi includono le porte seriali, le
 console virtuali dello schermo, i terminali virtuali che vengono creati come
@@ -940,34 +940,34 @@ canali di comunicazione dal kernel e che di solito vengono associati alle
 connessioni di rete (ad esempio per trattare i dati inviati con \cmd{telnet} o
 \cmd{ssh}).
 
-L'I/O sui terminali si effettua con le stesse modalità dei file normali: si
+L'I/O sui terminali si effettua con le stesse modalità dei file normali: si
 apre il relativo file di dispositivo, e si leggono e scrivono i dati con le
-usuali funzioni di lettura e scrittura, così se apriamo una console virtuale
-avremo che \func{read} leggerà quanto immesso dalla tastiera, mentre
-\func{write} scriverà sullo schermo.  In realtà questo è vero solo a grandi
-linee, perché non tiene conto delle caratteristiche specifiche dei terminali;
-una delle principali infatti è che essi prevedono due modalità di operazione,
+usuali funzioni di lettura e scrittura, così se apriamo una console virtuale
+avremo che \func{read} leggerà quanto immesso dalla tastiera, mentre
+\func{write} scriverà sullo schermo.  In realtà questo è vero solo a grandi
+linee, perché non tiene conto delle caratteristiche specifiche dei terminali;
+una delle principali infatti è che essi prevedono due modalità di operazione,
 dette rispettivamente \textsl{modo canonico} e \textsl{modo non canonico}, che
 comportano dei comportamenti nettamente diversi.
 
-La modalità preimpostata all'apertura del terminale è quella canonica, in cui
+La modalità preimpostata all'apertura del terminale è quella canonica, in cui
 le operazioni di lettura vengono sempre effettuate assemblando i dati in una
 linea;\footnote{per cui eseguendo una \func{read} su un terminale in modo
-  canonico la funzione si bloccherà, anche se si sono scritti dei caratteri,
+  canonico la funzione si bloccherà, anche se si sono scritti dei caratteri,
   fintanto che non si preme il tasto di ritorno a capo: a questo punto la
-  linea sarà completa e la funzione ritornerà.} ed in cui alcuni caratteri
+  linea sarà completa e la funzione ritornerà.} ed in cui alcuni caratteri
 vengono interpretati per compiere operazioni (come la generazione dei segnali
-illustrati in sez.~\ref{sec:sig_job_control}), questa di norma è la modalità in
+illustrati in sez.~\ref{sec:sig_job_control}), questa di norma è la modalità in
 cui funziona la shell.
 
 Un terminale in modo non canonico invece non effettua nessun accorpamento dei
-dati in linee né li interpreta; esso viene di solito usato dai programmi (gli
+dati in linee né li interpreta; esso viene di solito usato dai programmi (gli
 editor ad esempio) che necessitano di poter leggere un carattere alla volta e
 che gestiscono al loro interno i vari comandi.
 
 Per capire le caratteristiche dell'I/O sui terminali, occorre esaminare le
-modalità con cui esso viene effettuato; l'accesso, come per tutti i
-dispositivi, viene gestito da un driver apposito, la cui struttura generica è
+modalità con cui esso viene effettuato; l'accesso, come per tutti i
+dispositivi, viene gestito da un driver apposito, la cui struttura generica è
 mostrata in fig.~\ref{fig:term_struct}. Ad un terminale sono sempre associate
 due code per gestire l'input e l'output, che ne implementano una
 bufferizzazione\footnote{completamente indipendente dalla eventuale ulteriore
@@ -981,21 +981,21 @@ kernel.
 \end{figure}
 
 La coda di ingresso mantiene i caratteri che sono stati letti dal terminale ma
-non ancora letti da un processo, la sua dimensione è definita dal parametro di
+non ancora letti da un processo, la sua dimensione è definita dal parametro di
 sistema \const{MAX\_INPUT} (si veda sez.~\ref{sec:sys_file_limits}), che ne
-specifica il limite minimo, in realtà la coda può essere più grande e cambiare
-dimensione dinamicamente. Se è stato abilitato il controllo di flusso in
+specifica il limite minimo, in realtà la coda può essere più grande e cambiare
+dimensione dinamicamente. Se è stato abilitato il controllo di flusso in
 ingresso il driver emette i caratteri di STOP e START per bloccare e sbloccare
 l'ingresso dei dati; altrimenti i caratteri immessi oltre le dimensioni
 massime vengono persi; in alcuni casi il driver provvede ad inviare
 automaticamente un avviso (un carattere di BELL, che provoca un beep)
-sull'output quando si eccedono le dimensioni della coda.  Se è abilitato il
+sull'output quando si eccedono le dimensioni della coda.  Se è abilitato il
 modo canonico i caratteri in ingresso restano nella coda fintanto che non
 viene ricevuto un a capo; un altro parametro del sistema, \const{MAX\_CANON},
 specifica la dimensione massima di una riga in modo canonico.
 
-La coda di uscita è analoga a quella di ingresso e contiene i caratteri
-scritti dai processi ma non ancora inviati al terminale. Se è abilitato il
+La coda di uscita è analoga a quella di ingresso e contiene i caratteri
+scritti dai processi ma non ancora inviati al terminale. Se è abilitato il
 controllo di flusso in uscita il driver risponde ai caratteri di START e STOP
 inviati dal terminale. Le dimensioni della coda non sono specificate, ma non
 hanno molta importanza, in quanto qualora esse vengano eccedute il driver
@@ -1006,28 +1006,28 @@ provvede automaticamente a bloccare la funzione chiamante.
 \subsection{La gestione delle caratteristiche di un terminale}
 \label{sec:term_attr}
 
-Data le loro peculiarità, fin dall'inizio si è posto il problema di come
+Data le loro peculiarità, fin dall'inizio si è posto il problema di come
 gestire le caratteristiche specifiche dei terminali; storicamente i vari
-dialetti di Unix hanno utilizzato diverse funzioni, alla fine con POSIX.1, è
+dialetti di Unix hanno utilizzato diverse funzioni, alla fine con POSIX.1, è
 stata effettuata una standardizzazione, unificando le differenze fra BSD e
-System V in una unica interfaccia, che è quella usata dal Linux.
+System V in una unica interfaccia, che è quella usata dal Linux.
 
 Alcune di queste funzioni prendono come argomento un file descriptor (in
 origine molte operazioni venivano effettuate con \func{ioctl}), ma ovviamente
 possono essere usate solo con file che corrispondano effettivamente ad un
-terminale (altrimenti si otterrà un errore di \errcode{ENOTTY}); questo può
-essere evitato utilizzando la funzione \funcd{isatty}, il cui prototipo è:
+terminale (altrimenti si otterrà un errore di \errcode{ENOTTY}); questo può
+essere evitato utilizzando la funzione \funcd{isatty}, il cui prototipo è:
 \begin{prototype}{unistd.h}{int isatty(int desc)}
   
-  Controlla se il file descriptor \param{desc} è un terminale.
+  Controlla se il file descriptor \param{desc} è un terminale.
   
-\bodydesc{La funzione restituisce 1 se \param{desc} è connesso ad un
+\bodydesc{La funzione restituisce 1 se \param{desc} è connesso ad un
   terminale, 0 altrimenti.}
 \end{prototype}
 
-Un'altra funzione che fornisce informazioni su un terminale è \funcd{ttyname},
+Un'altra funzione che fornisce informazioni su un terminale è \funcd{ttyname},
 che permette di ottenere il nome del terminale associato ad un file
-descriptor; il suo prototipo è:
+descriptor; il suo prototipo è:
 \begin{prototype}{unistd.h}{char *ttyname(int desc)}
   
   Restituisce il nome del terminale associato al file \param{desc}.
@@ -1039,8 +1039,8 @@ descriptor; il suo prototipo 
 
 Si tenga presente che la funzione restituisce un indirizzo di dati statici,
 che pertanto possono essere sovrascritti da successive chiamate. Una funzione
-funzione analoga, anch'essa prevista da POSIX.1, è \funcd{ctermid}, il cui
-prototipo è:
+funzione analoga, anch'essa prevista da POSIX.1, è \funcd{ctermid}, il cui
+prototipo è:
 \begin{prototype}{stdio.h}{char *ctermid(char *s)}
   
   Restituisce il nome del terminale di controllo del processo.
@@ -1053,22 +1053,22 @@ La funzione scrive il \itindex{pathname} \textit{pathname} del terminale di
 controllo del processo chiamante nella stringa posta all'indirizzo specificato
 dall'argomento \param{s}.  La memoria per contenere la stringa deve essere
 stata allocata in precedenza ed essere lunga almeno
-\const{L\_ctermid}\footnote{\const{L\_ctermid} è una delle varie costanti del
+\const{L\_ctermid}\footnote{\const{L\_ctermid} è una delle varie costanti del
   sistema, non trattata esplicitamente in sez.~\ref{sec:sys_characteristics}
   che indica la dimensione che deve avere una stringa per poter contenere il
   nome di un terminale.} caratteri.
 
 Esiste infine una versione \index{funzioni!rientranti} rientrante
 \funcd{ttyname\_r} della funzione \func{ttyname}, che non presenta il problema
-dell'uso di una zona di memoria statica; il suo prototipo è:
+dell'uso di una zona di memoria statica; il suo prototipo è:
 \begin{prototype}{unistd.h}{int ttyname\_r(int desc, char *buff, size\_t len)}
   
   Restituisce il nome del terminale associato al file \param{desc}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
     \begin{errlist}
-    \item[\errcode{ERANGE}] la lunghezza del buffer, \param{len}, non è
+    \item[\errcode{ERANGE}] la lunghezza del buffer, \param{len}, non è
       sufficiente per contenere la stringa restituita.
     \end{errlist}
     ed inoltre \errval{EBADF} ed \errval{ENOSYS}.
@@ -1076,20 +1076,20 @@ dell'uso di una zona di memoria statica; il suo prototipo 
 \end{prototype}
 
 La funzione prende due argomenti, il puntatore alla zona di memoria
-\param{buff}, in cui l'utente vuole che il risultato venga scritto (dovrà
+\param{buff}, in cui l'utente vuole che il risultato venga scritto (dovrà
 ovviamente essere stata allocata in precedenza), e la relativa dimensione,
 \param{len}; se la stringa che deve essere restituita eccede questa dimensione
-si avrà una condizione di errore.
+si avrà una condizione di errore.
 
 Se si passa come argomento \val{NULL} la funzione restituisce il puntatore ad
-una stringa statica che può essere sovrascritta da chiamate successive. Si
+una stringa statica che può essere sovrascritta da chiamate successive. Si
 tenga presente che il \itindex{pathname} \textit{pathname} restituito
 potrebbe non identificare univocamente il terminale (ad esempio potrebbe
-essere \file{/dev/tty}), inoltre non è detto che il processo possa
+essere \file{/dev/tty}), inoltre non è detto che il processo possa
 effettivamente aprire il terminale.
 
 I vari attributi vengono mantenuti per ciascun terminale in una struttura
-\struct{termios}, (la cui definizione è riportata in
+\struct{termios}, (la cui definizione è riportata in
 fig.~\ref{fig:term_termios}), usata dalle varie funzioni dell'interfaccia. In
 fig.~\ref{fig:term_termios} si sono riportati tutti i campi della definizione
 usata in Linux; di questi solo i primi cinque sono previsti dallo standard
@@ -1097,7 +1097,7 @@ POSIX.1, ma le varie implementazioni ne aggiungono degli altri per mantenere
 ulteriori informazioni.\footnote{la definizione della struttura si trova in
   \file{bits/termios.h}, da non includere mai direttamente, Linux, seguendo
   l'esempio di BSD, aggiunge i due campi \var{c\_ispeed} e \var{c\_ospeed} per
-  mantenere le velocità delle linee seriali, ed un campo ulteriore,
+  mantenere le velocità delle linee seriali, ed un campo ulteriore,
   \var{c\_line} per ... (NdT, trovare a che serve).}
 % TODO trovare a che serve
 
@@ -1107,14 +1107,14 @@ ulteriori informazioni.\footnote{la definizione della struttura si trova in
     \includestruct{listati/termios.h}
   \end{minipage} 
   \normalsize 
-  \caption{La struttura \structd{termios}, che identifica le proprietà di un
+  \caption{La struttura \structd{termios}, che identifica le proprietà di un
     terminale.}
   \label{fig:term_termios}
 \end{figure}
 
 I primi quattro campi sono quattro flag che controllano il comportamento del
 terminale; essi sono realizzati come maschera binaria, pertanto il tipo
-\type{tcflag\_t} è di norma realizzato con un intero senza segno di lunghezza
+\type{tcflag\_t} è di norma realizzato con un intero senza segno di lunghezza
 opportuna. I valori devono essere specificati bit per bit, avendo cura di non
 modificare i bit su cui non si interviene.
 
@@ -1126,41 +1126,41 @@ modificare i bit su cui non si interviene.
     \textbf{Valore}& \textbf{Significato}\\
     \hline
     \hline
-    \const{INPCK}  & Abilita il controllo di parità in ingresso. Se non viene
+    \const{INPCK}  & Abilita il controllo di parità in ingresso. Se non viene
                      impostato non viene fatto nessun controllo ed i caratteri
                      vengono passati in input direttamente.\\
-    \const{IGNPAR} & Ignora gli errori di parità, il carattere viene passato
-                     come ricevuto. Ha senso solo se si è impostato 
+    \const{IGNPAR} & Ignora gli errori di parità, il carattere viene passato
+                     come ricevuto. Ha senso solo se si è impostato 
                      \const{INPCK}.\\
-    \const{PARMRK} & Controlla come vengono riportati gli errori di parità. Ha 
-                     senso solo se \const{INPCK} è impostato e \const{IGNPAR}
+    \const{PARMRK} & Controlla come vengono riportati gli errori di parità. Ha 
+                     senso solo se \const{INPCK} è impostato e \const{IGNPAR}
                      no. Se impostato inserisce una sequenza \texttt{0xFF
                        0x00} prima di ogni carattere che presenta errori di
-                     parità, se non impostato un carattere con errori di
-                     parità viene letto come uno \texttt{0x00}. Se un
+                     parità, se non impostato un carattere con errori di
+                     parità viene letto come uno \texttt{0x00}. Se un
                      carattere ha il valore \texttt{0xFF} e \const{ISTRIP} 
-                     non è impostato, per evitare ambiguità esso viene sempre
+                     non è impostato, per evitare ambiguità esso viene sempre
                      riportato come \texttt{0xFF 0xFF}.\\
     \const{ISTRIP} & Se impostato i caratteri in input sono tagliati a sette
-                     bit mettendo a zero il bit più significativo, altrimenti 
+                     bit mettendo a zero il bit più significativo, altrimenti 
                      vengono passati tutti gli otto bit.\\
     \const{IGNBRK} & Ignora le condizioni di BREAK sull'input. Una
-                     \textit{condizione di BREAK} è definita nel contesto di
+                     \textit{condizione di BREAK} è definita nel contesto di
                      una trasmissione seriale asincrona come una sequenza di
-                     bit nulli più lunga di un byte.\\
+                     bit nulli più lunga di un byte.\\
     \const{BRKINT} & Controlla la reazione ad un BREAK quando
-                     \const{IGNBRK} non è impostato. Se \const{BRKINT} è
+                     \const{IGNBRK} non è impostato. Se \const{BRKINT} è
                      impostato il BREAK causa lo scarico delle code, 
-                     e se il terminale è il terminale di controllo per un 
+                     e se il terminale è il terminale di controllo per un 
                      gruppo in foreground anche l'invio di \const{SIGINT} ai
-                     processi di quest'ultimo. Se invece \const{BRKINT} non è
+                     processi di quest'ultimo. Se invece \const{BRKINT} non è
                      impostato un BREAK viene letto come un carattere
                      NUL, a meno che non sia impostato \const{PARMRK}
                      nel qual caso viene letto come la sequenza di caratteri
                      \texttt{0xFF 0x00 0x00}.\\
     \const{IGNCR}  & Se impostato il carattere di ritorno carrello 
                      (\textit{carriage return}, \verb|'\r'|) viene scartato 
-                     dall'input. Può essere utile per i terminali che inviano 
+                     dall'input. Può essere utile per i terminali che inviano 
                      entrambi i caratteri di ritorno carrello e a capo 
                      (\textit{newline}, \verb|'\n'|).\\
     \const{ICRNL}  & Se impostato un carattere di ritorno carrello  
@@ -1188,26 +1188,26 @@ modificare i bit su cui non si interviene.
                      bloccare l'input dal terminale e lo sblocca con il
                      carattere START.\\
     \const{IMAXBEL}& Se impostato fa suonare il cicalino se si riempie la cosa
-                     di ingresso; in Linux non è implementato e il kernel si
-                     comporta cose se fosse sempre impostato (è una estensione
+                     di ingresso; in Linux non è implementato e il kernel si
+                     comporta cose se fosse sempre impostato (è una estensione
                      BSD).\\
     \hline
   \end{tabular}
   \caption{Costanti identificative dei vari bit del flag di controllo
-    \var{c\_iflag} delle modalità di input di un terminale.}
+    \var{c\_iflag} delle modalità di input di un terminale.}
   \label{tab:sess_termios_iflag}
 \end{table}
 
-Il primo flag, mantenuto nel campo \var{c\_iflag}, è detto \textsl{flag di
-  input} e controlla le modalità di funzionamento dell'input dei caratteri sul
-terminale, come il controllo di parità, il controllo di flusso, la gestione
+Il primo flag, mantenuto nel campo \var{c\_iflag}, è detto \textsl{flag di
+  input} e controlla le modalità di funzionamento dell'input dei caratteri sul
+terminale, come il controllo di parità, il controllo di flusso, la gestione
 dei caratteri speciali; un elenco dei vari bit, del loro significato e delle
-costanti utilizzate per identificarli è riportato in
+costanti utilizzate per identificarli è riportato in
 tab.~\ref{tab:sess_termios_iflag}.
 
 Si noti come alcuni di questi flag (come quelli per la gestione del flusso)
 fanno riferimento a delle caratteristiche che ormai sono completamente
-obsolete; la maggior parte inoltre è tipica di terminali seriali, e non ha
+obsolete; la maggior parte inoltre è tipica di terminali seriali, e non ha
 alcun effetto su dispositivi diversi come le console virtuali o gli
 pseudo-terminali usati nelle connessioni di rete.
 
@@ -1222,7 +1222,7 @@ pseudo-terminali usati nelle connessioni di rete.
     \const{OPOST} & Se impostato i caratteri vengono convertiti opportunamente
                     (in maniera dipendente dall'implementazione) per la 
                     visualizzazione sul terminale, ad esempio al
-                    carattere di a capo (NL) può venire aggiunto un ritorno
+                    carattere di a capo (NL) può venire aggiunto un ritorno
                     carrello (CR).\\
     \const{OCRNL} & Se impostato converte automaticamente il carattere di a
                     capo (NL) nella coppia di caratteri ritorno carrello, a 
@@ -1238,7 +1238,7 @@ pseudo-terminali usati nelle connessioni di rete.
                     carrello (CR).\\
     \const{OFILL} & Se impostato in caso di ritardo sulla linea invia dei
                     caratteri di riempimento invece di attendere.\\
-    \const{OFDEL} & Se impostato il carattere di riempimento è DEL
+    \const{OFDEL} & Se impostato il carattere di riempimento è DEL
                     (\texttt{0x3F}), invece che NUL (\texttt{0x00}).\\
     \const{NLDLY} & Maschera per i bit che indicano il ritardo per il
                     carattere di a capo (NL), i valori possibili sono 
@@ -1261,15 +1261,15 @@ pseudo-terminali usati nelle connessioni di rete.
     \hline
   \end{tabular}
   \caption{Costanti identificative dei vari bit del flag di controllo
-    \var{c\_oflag} delle modalità di output di un terminale.}
+    \var{c\_oflag} delle modalità di output di un terminale.}
   \label{tab:sess_termios_oflag}
 \end{table}
 
-Il secondo flag, mantenuto nel campo \var{c\_oflag}, è detto \textsl{flag di
-  output} e controlla le modalità di funzionamento dell'output dei caratteri,
+Il secondo flag, mantenuto nel campo \var{c\_oflag}, è detto \textsl{flag di
+  output} e controlla le modalità di funzionamento dell'output dei caratteri,
 come l'impacchettamento dei caratteri sullo schermo, la traslazione degli a
 capo, la conversione dei caratteri speciali; un elenco dei vari bit, del loro
-significato e delle costanti utilizzate per identificarli è riportato in
+significato e delle costanti utilizzate per identificarli è riportato in
 tab.~\ref{tab:sess_termios_oflag}.
 
 Si noti come alcuni dei valori riportati in tab.~\ref{tab:sess_termios_oflag}
@@ -1283,7 +1283,7 @@ Si tenga presente inoltre che nel caso delle maschere il valore da inserire in
 \var{c\_oflag} deve essere fornito avendo cura di cancellare prima tutti i bit
 della maschera, i valori da immettere infatti (quelli riportati nella
 spiegazione corrispondente) sono numerici e non per bit, per cui possono
-sovrapporsi fra di loro. Occorrerà perciò utilizzare un codice del tipo:
+sovrapporsi fra di loro. Occorrerà perciò utilizzare un codice del tipo:
 
 \includecodesnip{listati/oflag.c}
 
@@ -1299,64 +1299,64 @@ valore.
     \textbf{Valore}& \textbf{Significato}\\
     \hline
     \hline
-    \const{CLOCAL} & Se impostato indica che il terminale è connesso in locale
+    \const{CLOCAL} & Se impostato indica che il terminale è connesso in locale
                      e che le linee di controllo del modem devono essere
                      ignorate. Se non impostato effettuando una chiamata ad
                      \func{open} senza aver specificato il flag di
-                     \const{O\_NOBLOCK} si bloccherà il processo finché 
-                     non si è stabilita una connessione con il modem; inoltre 
+                     \const{O\_NOBLOCK} si bloccherà il processo finché 
+                     non si è stabilita una connessione con il modem; inoltre 
                      se viene rilevata una disconnessione viene inviato un
                      segnale di \const{SIGHUP} al processo di controllo del
                      terminale. La lettura su un terminale sconnesso comporta
                      una condizione di \textit{end of file} e la scrittura un
                      errore di \errcode{EIO}.\\
-    \const{HUPCL}  & Se è impostato viene distaccata la connessione del
+    \const{HUPCL}  & Se è impostato viene distaccata la connessione del
                      modem quando l'ultimo dei processi che ha ancora un file
                      aperto sul terminale lo chiude o esce.\\
-    \const{CREAD}  & Se è impostato si può leggere l'input del terminale,
+    \const{CREAD}  & Se è impostato si può leggere l'input del terminale,
                      altrimenti i caratteri in ingresso vengono scartati
                      quando arrivano.\\
     \const{CSTOPB} & Se impostato vengono usati due bit di stop sulla linea
                      seriale, se non impostato ne viene usato soltanto uno.\\
     \const{PARENB} & Se impostato abilita la generazione il controllo di
-                     parità. La reazione in caso di errori dipende dai
+                     parità. La reazione in caso di errori dipende dai
                      relativi valori per \var{c\_iflag}, riportati in 
-                     tab.~\ref{tab:sess_termios_iflag}. Se non è impostato i
-                     bit di parità non vengono generati e i caratteri non
+                     tab.~\ref{tab:sess_termios_iflag}. Se non è impostato i
+                     bit di parità non vengono generati e i caratteri non
                      vengono controllati.\\
-    \const{PARODD} & Ha senso solo se è attivo anche \const{PARENB}. Se 
-                     impostato viene usata una parità è dispari, altrimenti 
-                     viene usata una parità pari.\\
+    \const{PARODD} & Ha senso solo se è attivo anche \const{PARENB}. Se 
+                     impostato viene usata una parità è dispari, altrimenti 
+                     viene usata una parità pari.\\
     \const{CSIZE}  & Maschera per i bit usati per specificare la dimensione 
                      del carattere inviato lungo la linea di trasmissione, i
                      valore ne indica la lunghezza (in bit), ed i valori   
                      possibili sono \val{CS5}, \val{CS6}, \val{CS7} e \val{CS8}
                      corrispondenti ad un analogo numero di bit.\\
-    \const{CBAUD}  & Maschera dei bit (4+1) usati per impostare della velocità
+    \const{CBAUD}  & Maschera dei bit (4+1) usati per impostare della velocità
                      della linea (il \textit{baud rate}) in ingresso; in Linux
-                     non è implementato in quanto viene  usato un apposito
+                     non è implementato in quanto viene  usato un apposito
                      campo di \struct{termios}.\\
-    \const{CBAUDEX}& Bit aggiuntivo per l'impostazione della velocità della
-                     linea, per le stesse motivazioni del precedente non è
+    \const{CBAUDEX}& Bit aggiuntivo per l'impostazione della velocità della
+                     linea, per le stesse motivazioni del precedente non è
                      implementato in Linux.\\
-    \const{CIBAUD} & Maschera dei bit della velocità della linea in
-                     ingresso; analogo a \const{CBAUD}, anch'esso in Linux è
+    \const{CIBAUD} & Maschera dei bit della velocità della linea in
+                     ingresso; analogo a \const{CBAUD}, anch'esso in Linux è
                      mantenuto in un apposito campo di \struct{termios}.\\
     \const{CRTSCTS}& Abilita il controllo di flusso hardware sulla seriale,
                      attraverso l'utilizzo delle dei due fili di RTS e CTS.\\
     \hline
   \end{tabular}
   \caption{Costanti identificative dei vari bit del flag di controllo
-    \var{c\_cflag} delle modalità di controllo di un terminale.}
+    \var{c\_cflag} delle modalità di controllo di un terminale.}
   \label{tab:sess_termios_cflag}
 \end{table}
 
-Il terzo flag, mantenuto nel campo \var{c\_cflag}, è detto \textsl{flag di
-  controllo} ed è legato al funzionamento delle linee seriali, permettendo di
+Il terzo flag, mantenuto nel campo \var{c\_cflag}, è detto \textsl{flag di
+  controllo} ed è legato al funzionamento delle linee seriali, permettendo di
 impostarne varie caratteristiche, come il numero di bit di stop, le
-impostazioni della parità, il funzionamento del controllo di flusso; esso ha
+impostazioni della parità, il funzionamento del controllo di flusso; esso ha
 senso solo per i terminali connessi a linee seriali. Un elenco dei vari bit,
-del loro significato e delle costanti utilizzate per identificarli è riportato
+del loro significato e delle costanti utilizzate per identificarli è riportato
 in tab.~\ref{tab:sess_termios_cflag}.
 
 I valori di questo flag sono molto specifici, e completamente indirizzati al
@@ -1366,7 +1366,7 @@ le console virtuali e gli pseudo-terminali usati dalle connessioni di rete.
 
 Inoltre alcuni valori sono previsti solo per quelle implementazioni (lo
 standard POSIX non specifica nulla riguardo l'implementazione, ma solo delle
-funzioni di lettura e scrittura) che mantengono le velocità delle linee
+funzioni di lettura e scrittura) che mantengono le velocità delle linee
 seriali all'interno dei flag; come accennato in Linux questo viene fatto
 (seguendo l'esempio di BSD) attraverso due campi aggiuntivi, \var{c\_ispeed} e
 \var{c\_ospeed}, nella struttura \struct{termios} (mostrati in
@@ -1382,44 +1382,44 @@ fig.~\ref{fig:term_termios}).
     \hline
     \const{ICANON} & Se impostato il terminale opera in modo canonico,
                      altrimenti opera in modo non canonico.\\
-    \const{ECHO}   & Se è impostato viene attivato l'eco dei caratteri in
+    \const{ECHO}   & Se è impostato viene attivato l'eco dei caratteri in
                      input sull'output del terminale.\\
-    \const{ECHOE}  & Se è impostato l'eco mostra la cancellazione di un
+    \const{ECHOE}  & Se è impostato l'eco mostra la cancellazione di un
                      carattere in input (in reazione al carattere ERASE)
                      cancellando l'ultimo carattere della riga corrente dallo
-                     schermo; altrimenti il carattere è rimandato in eco per
+                     schermo; altrimenti il carattere è rimandato in eco per
                      mostrare quanto accaduto (usato per i terminali con
                      l'uscita su una stampante).\\
     \const{ECHOPRT}& Se impostato abilita la visualizzazione del carattere di
-                     cancellazione in una modalità adatta ai terminali con
+                     cancellazione in una modalità adatta ai terminali con
                      l'uscita su stampante; l'invio del carattere di ERASE
                      comporta la stampa di un ``\texttt{|}'' seguito dal
-                     carattere cancellato, e così via in caso di successive
+                     carattere cancellato, e così via in caso di successive
                      cancellazioni, quando si riprende ad immettere carattere 
-                     normali prima verrà stampata una ``\texttt{/}''.\\
+                     normali prima verrà stampata una ``\texttt{/}''.\\
     \const{ECHOK}  & Se impostato abilita il trattamento della visualizzazione
                      del carattere KILL, andando a capo dopo aver visualizzato
                      lo stesso, altrimenti viene solo mostrato il carattere e
-                     sta all'utente ricordare che l'input precedente è stato
+                     sta all'utente ricordare che l'input precedente è stato
                      cancellato.\\
     \const{ECHOKE} & Se impostato abilita il trattamento della visualizzazione
                      del carattere KILL cancellando i caratteri precedenti
-                     nella linea secondo le modalità specificate dai valori di
+                     nella linea secondo le modalità specificate dai valori di
                      \const{ECHOE} e \const{ECHOPRT}.\\
     \const{ECHONL} & Se impostato viene effettuato l'eco di un a
-                     capo (\verb|\n|) anche se non è stato impostato
+                     capo (\verb|\n|) anche se non è stato impostato
                      \const{ECHO}.\\
     \const{ECHOCTL}& Se impostato insieme ad \const{ECHO} i caratteri di
                      controllo ASCII (tranne TAB, NL, START, e STOP) sono
                      mostrati nella forma che prepone un ``\texttt{\circonf}'' 
                      alla lettera ottenuta sommando \texttt{0x40} al valore del
                      carattere (di solito questi si possono ottenere anche
-                     direttamente premendo il tasto \texttt{ctrl} più la
+                     direttamente premendo il tasto \texttt{ctrl} più la
                      relativa lettera).\\
     \const{ISIG}   & Se impostato abilita il riconoscimento dei caratteri
                      INTR, QUIT, e SUSP generando il relativo segnale.\\
     \const{IEXTEN} & Abilita alcune estensioni previste dalla
-                     implementazione. Deve essere impostato perché caratteri
+                     implementazione. Deve essere impostato perché caratteri
                      speciali come EOL2, LNEXT, REPRINT e WERASE possano
                      essere interpretati.\\
     \const{NOFLSH} & Se impostato disabilita lo scarico delle code di ingresso
@@ -1429,48 +1429,48 @@ fig.~\ref{fig:term_termios}).
                      genera il segnale \const{SIGTTOU} per un processo in
                      background che cerca di scrivere sul terminale.\\
     \const{XCASE}  & Se impostato il terminale funziona solo con le
-                     maiuscole. L'input è convertito in minuscole tranne per i
+                     maiuscole. L'input è convertito in minuscole tranne per i
                      caratteri preceduti da una ``\texttt{\bslash}''. In output
                      le maiuscole sono precedute da una ``\texttt{\bslash}'' e 
                      le minuscole convertite in maiuscole.\\
-    \const{DEFECHO}& Se impostato effettua l'eco solo se c'è un processo in
+    \const{DEFECHO}& Se impostato effettua l'eco solo se c'è un processo in
                      lettura.\\
     \const{FLUSHO} & Effettua la cancellazione della coda di uscita. Viene
-                     attivato dal carattere DISCARD. Non è supportato in
+                     attivato dal carattere DISCARD. Non è supportato in
                      Linux.\\
     \const{PENDIN} & Indica che la linea deve essere ristampata, viene
                      attivato dal carattere REPRINT e resta attivo fino alla
-                     fine della ristampa. Non è supportato in Linux.\\
+                     fine della ristampa. Non è supportato in Linux.\\
     \hline
   \end{tabular}
   \caption{Costanti identificative dei vari bit del flag di controllo
-    \var{c\_lflag} delle modalità locali di un terminale.}
+    \var{c\_lflag} delle modalità locali di un terminale.}
   \label{tab:sess_termios_lflag}
 \end{table}
 
-Il quarto flag, mantenuto nel campo \var{c\_lflag}, è detto \textsl{flag
+Il quarto flag, mantenuto nel campo \var{c\_lflag}, è detto \textsl{flag
   locale}, e serve per controllare il funzionamento dell'interfaccia fra il
 driver e l'utente, come abilitare l'eco, gestire i caratteri di controllo e
 l'emissione dei segnali, impostare modo canonico o non canonico; un elenco dei
-vari bit, del loro significato e delle costanti utilizzate per identificarli è
+vari bit, del loro significato e delle costanti utilizzate per identificarli è
 riportato in tab.~\ref{tab:sess_termios_lflag}. Con i terminali odierni l'unico
-flag con cui probabilmente si può avere a che fare è questo, in quanto è con
+flag con cui probabilmente si può avere a che fare è questo, in quanto è con
 questo che si impostano le caratteristiche generiche comuni a tutti i
 terminali.
 
-Si tenga presente che i flag che riguardano le modalità di eco dei caratteri
+Si tenga presente che i flag che riguardano le modalità di eco dei caratteri
 (\const{ECHOE}, \const{ECHOPRT}, \const{ECHOK}, \const{ECHOKE},
 \const{ECHONL}) controllano solo il comportamento della visualizzazione, il
-riconoscimento dei vari caratteri dipende dalla modalità di operazione, ed
+riconoscimento dei vari caratteri dipende dalla modalità di operazione, ed
 avviene solo in modo canonico, pertanto questi flag non hanno significato se
-non è impostato \const{ICANON}.
+non è impostato \const{ICANON}.
 
 Oltre ai vari flag per gestire le varie caratteristiche dei terminali,
 \struct{termios} contiene pure il campo \var{c\_cc} che viene usato per
 impostare i caratteri speciali associati alle varie funzioni di controllo. Il
-numero di questi caratteri speciali è indicato dalla costante \const{NCCS},
+numero di questi caratteri speciali è indicato dalla costante \const{NCCS},
 POSIX ne specifica almeno 11, ma molte implementazioni ne definiscono molti
-altri.\footnote{in Linux il valore della costante è 32, anche se i caratteri
+altri.\footnote{in Linux il valore della costante è 32, anche se i caratteri
   effettivamente definiti sono solo 17.}
 
 \begin{table}[htb]
@@ -1497,11 +1497,11 @@ altri.\footnote{in Linux il valore della costante 
                                                  l'invio del contenuto del
                                                  buffer di ingresso al
                                                  processo in lettura anche se
-                                                 non è ancora stato ricevuto
-                                                 un a capo. Se è il primo
+                                                 non è ancora stato ricevuto
+                                                 un a capo. Se è il primo
                                                  carattere immesso comporta il
                                                  ritorno di \func{read} con
-                                                 zero caratteri, cioè la
+                                                 zero caratteri, cioè la
                                                  condizione di
                                                  \textit{end-of-file}.\\
     \const{VTIME} &     ---     &  ---   & Timeout, in decimi di secondo, per
@@ -1521,7 +1521,7 @@ altri.\footnote{in Linux il valore della costante 
                                                  \const{SIGTSTP}.\\
     \const{VEOL}  &\texttt{0x00}& NUL &    Carattere di fine riga. Agisce come
                                            un a capo, ma non viene scartato ed
-                                           è letto come l'ultimo carattere
+                                           è letto come l'ultimo carattere
                                            nella riga.\\
     \const{VREPRINT}&\texttt{0x12}&(\texttt{C-r})& Ristampa i caratteri non
                                                  ancora letti.\\
@@ -1535,7 +1535,7 @@ altri.\footnote{in Linux il valore della costante 
                                                  direttamente all'output.\\
     \const{VEOL2} &\texttt{0x00}&   NUL  & Ulteriore carattere di fine
                                            riga. Ha lo stesso effetto di
-                                           \const{VEOL} ma può essere un
+                                           \const{VEOL} ma può essere un
                                            carattere diverso. \\
     \hline
   \end{tabular}
@@ -1546,12 +1546,12 @@ altri.\footnote{in Linux il valore della costante 
 
 
 A ciascuna di queste funzioni di controllo corrisponde un elemento del vettore
-\var{c\_cc} che specifica quale è il carattere speciale associato; per
-portabilità invece di essere indicati con la loro posizione numerica nel
+\var{c\_cc} che specifica quale è il carattere speciale associato; per
+portabilità invece di essere indicati con la loro posizione numerica nel
 vettore, i vari elementi vengono indicizzati attraverso delle opportune
 costanti, il cui nome corrisponde all'azione ad essi associata. Un elenco
-completo dei caratteri di controllo, con le costanti e delle funzionalità
-associate è riportato in tab.~\ref{tab:sess_termios_cc}, usando quelle
+completo dei caratteri di controllo, con le costanti e delle funzionalità
+associate è riportato in tab.~\ref{tab:sess_termios_cc}, usando quelle
 definizioni diventa possibile assegnare un nuovo carattere di controllo con un
 codice del tipo:
 \includecodesnip{listati/value_c_cc.c}
@@ -1567,9 +1567,9 @@ vengono interpretati e non sono passati sulla coda di ingresso.
 
 Per leggere ed scrivere tutte le varie impostazioni dei terminali viste finora
 lo standard POSIX prevede due funzioni che utilizzano come argomento un
-puntatore ad una struttura \struct{termios} che sarà quella in cui andranno
+puntatore ad una struttura \struct{termios} che sarà quella in cui andranno
 immagazzinate le impostazioni.  Le funzioni sono \funcd{tcgetattr} e
-\funcd{tcsetattr} ed il loro prototipo è:
+\funcd{tcsetattr} ed il loro prototipo è:
 \begin{functions}
   \headdecl{unistd.h} 
   \headdecl{termios.h}  
@@ -1581,9 +1581,9 @@ immagazzinate le impostazioni.  Le funzioni sono \funcd{tcgetattr} e
   Scrive le impostazioni di un terminale.
   
   \bodydesc{Entrambe le funzioni restituiscono 0 in caso di successo e -1 in
-    caso di errore, nel qual caso \var{errno} assumerà i valori:
+    caso di errore, nel qual caso \var{errno} assumerà i valori:
     \begin{errlist}
-    \item[\errcode{EINTR}] la funzione è stata interrotta. 
+    \item[\errcode{EINTR}] la funzione è stata interrotta. 
     \end{errlist}
     ed inoltre \errval{EBADF}, \errval{ENOTTY} ed \errval{EINVAL}. 
   }
@@ -1592,28 +1592,28 @@ immagazzinate le impostazioni.  Le funzioni sono \funcd{tcgetattr} e
 Le funzioni operano sul terminale cui fa riferimento il file descriptor
 \param{fd} utilizzando la struttura indicata dal puntatore \param{termios\_p}
 per lo scambio dei dati. Si tenga presente che le impostazioni sono associate
-al terminale e non al file descriptor; questo significa che se si è cambiata
+al terminale e non al file descriptor; questo significa che se si è cambiata
 una impostazione un qualunque altro processo che apra lo stesso terminale, od
-un qualunque altro file descriptor che vi faccia riferimento, vedrà le nuove
-impostazioni pur non avendo nulla a che fare con il file descriptor che si è
+un qualunque altro file descriptor che vi faccia riferimento, vedrà le nuove
+impostazioni pur non avendo nulla a che fare con il file descriptor che si è
 usato per effettuare i cambiamenti.
 
-Questo significa che non è possibile usare file descriptor diversi per
-utilizzare automaticamente il terminale in modalità diverse, se esiste una
-necessità di accesso differenziato di questo tipo occorrerà cambiare
-esplicitamente la modalità tutte le volte che si passa da un file descriptor
+Questo significa che non è possibile usare file descriptor diversi per
+utilizzare automaticamente il terminale in modalità diverse, se esiste una
+necessità di accesso differenziato di questo tipo occorrerà cambiare
+esplicitamente la modalità tutte le volte che si passa da un file descriptor
 ad un altro.
 
 La funzione \func{tcgetattr} legge i valori correnti delle impostazioni di un
 terminale qualunque nella struttura puntata da \param{termios\_p};
 \func{tcsetattr} invece effettua la scrittura delle impostazioni e quando
-viene invocata sul proprio terminale di controllo può essere eseguita con
+viene invocata sul proprio terminale di controllo può essere eseguita con
 successo solo da un processo in foreground.  Se invocata da un processo in
-background infatti tutto il gruppo riceverà un segnale di \const{SIGTTOU} come
+background infatti tutto il gruppo riceverà un segnale di \const{SIGTTOU} come
 se si fosse tentata una scrittura, a meno che il processo chiamante non abbia
-\const{SIGTTOU} ignorato o bloccato, nel qual caso l'operazione sarà eseguita.
+\const{SIGTTOU} ignorato o bloccato, nel qual caso l'operazione sarà eseguita.
 
-La funzione \func{tcsetattr} prevede tre diverse modalità di funzionamento,
+La funzione \func{tcsetattr} prevede tre diverse modalità di funzionamento,
 specificabili attraverso l'argomento \param{optional\_actions}, che permette
 di stabilire come viene eseguito il cambiamento delle impostazioni del
 terminale, i valori possibili sono riportati in
@@ -1631,8 +1631,8 @@ utili qualora si cambino i parametri di output.
     \hline
     \const{TCSANOW}  & Esegue i cambiamenti in maniera immediata.\\
     \const{TCSADRAIN}& I cambiamenti vengono eseguiti dopo aver atteso che
-                       tutto l'output presente sulle code è stato scritto.\\
-    \const{TCSAFLUSH}& È identico a \const{TCSADRAIN}, ma in più scarta
+                       tutto l'output presente sulle code è stato scritto.\\
+    \const{TCSAFLUSH}& È identico a \const{TCSADRAIN}, ma in più scarta
                        tutti i dati presenti sulla coda di input.\\
     \hline
   \end{tabular}
@@ -1642,8 +1642,8 @@ utili qualora si cambino i parametri di output.
 \end{table}
 
 Occorre infine tenere presente che \func{tcsetattr} ritorna con successo anche
-se soltanto uno dei cambiamenti richiesti è stato eseguito. Pertanto se si
-effettuano più cambiamenti è buona norma controllare con una ulteriore
+se soltanto uno dei cambiamenti richiesti è stato eseguito. Pertanto se si
+effettuano più cambiamenti è buona norma controllare con una ulteriore
 chiamata a \func{tcgetattr} che essi siano stati eseguiti tutti quanti.
 
 \begin{figure}[!htb]
@@ -1657,24 +1657,24 @@ chiamata a \func{tcgetattr} che essi siano stati eseguiti tutti quanti.
   \label{fig:term_set_attr}
 \end{figure}
 
-Come già accennato per i cambiamenti effettuati ai vari flag di controllo
+Come già accennato per i cambiamenti effettuati ai vari flag di controllo
 occorre che i valori di ciascun bit siano specificati avendo cura di mantenere
 intatti gli altri; per questo motivo in generale si deve prima leggere il
 valore corrente delle impostazioni con \func{tcgetattr} per poi modificare i
 valori impostati.
 
-In fig.~\ref{fig:term_set_attr} e fig.~\ref{fig:term_unset_attr} si è riportato
+In fig.~\ref{fig:term_set_attr} e fig.~\ref{fig:term_unset_attr} si è riportato
 rispettivamente il codice delle due funzioni \func{SetTermAttr} e
 \func{UnSetTermAttr}, che possono essere usate per impostare o rimuovere, con
 le dovute precauzioni, un qualunque bit di \var{c\_lflag}. Il codice di
-entrambe le funzioni può essere trovato nel file \file{SetTermAttr.c} dei
+entrambe le funzioni può essere trovato nel file \file{SetTermAttr.c} dei
 sorgenti allegati.
 
 La funzione \func{SetTermAttr} provvede ad impostare il bit specificato
 dall'argomento \param{flag}; prima si leggono i valori correnti
 (\texttt{\small 10}) con \func{tcgetattr}, uscendo con un messaggio in caso di
 errore (\texttt{\small 11--14}), poi si provvede a impostare solo i bit
-richiesti (possono essere più di uno) con un OR binario (\texttt{\small 15});
+richiesti (possono essere più di uno) con un OR binario (\texttt{\small 15});
 infine si scrive il nuovo valore modificato con \func{tcsetattr}
 (\texttt{\small 16}), notificando un eventuale errore (\texttt{\small 11--14})
 o uscendo normalmente.
@@ -1690,7 +1690,7 @@ o uscendo normalmente.
   \label{fig:term_unset_attr}
 \end{figure}
 
-La seconda funzione, \func{UnSetTermAttr}, è assolutamente identica alla
+La seconda funzione, \func{UnSetTermAttr}, è assolutamente identica alla
 prima, solo che in questo caso, in (\texttt{\small 15}), si rimuovono i bit
 specificati dall'argomento \param{flag} usando un AND binario del valore
 negato.
@@ -1698,80 +1698,80 @@ negato.
 
 Al contrario di tutte le altre caratteristiche dei terminali, che possono
 essere impostate esplicitamente utilizzando gli opportuni campi di
-\struct{termios}, per le velocità della linea (il cosiddetto \textit{baud
-  rate}) non è prevista una implementazione standardizzata, per cui anche se
+\struct{termios}, per le velocità della linea (il cosiddetto \textit{baud
+  rate}) non è prevista una implementazione standardizzata, per cui anche se
 in Linux sono mantenute in due campi dedicati nella struttura, questi non
 devono essere acceduti direttamente ma solo attraverso le apposite funzioni di
 interfaccia provviste da POSIX.1.
 
-Lo standard prevede due funzioni per scrivere la velocità delle linee seriali,
-\funcd{cfsetispeed} per la velocità della linea di ingresso e
-\funcd{cfsetospeed} per la velocità della linea di uscita; i loro prototipi
+Lo standard prevede due funzioni per scrivere la velocità delle linee seriali,
+\funcd{cfsetispeed} per la velocità della linea di ingresso e
+\funcd{cfsetospeed} per la velocità della linea di uscita; i loro prototipi
 sono:
 \begin{functions}
   \headdecl{unistd.h} 
   \headdecl{termios.h}  
   \funcdecl{int cfsetispeed(struct termios *termios\_p, speed\_t speed)} 
-  Imposta la velocità delle linee seriali in ingresso.
+  Imposta la velocità delle linee seriali in ingresso.
   
   \funcdecl{int cfsetospeed(struct termios *termios\_p, speed\_t speed)} 
-  Imposta la velocità delle linee seriali in uscita.
+  Imposta la velocità delle linee seriali in uscita.
   
   \bodydesc{Entrambe le funzioni restituiscono 0 in caso di successo e -1 in
-    caso di errore, che avviene solo quando il valore specificato non è
+    caso di errore, che avviene solo quando il valore specificato non è
     valido.}
 \end{functions}
  
 Si noti che le funzioni si limitano a scrivere opportunamente il valore della
-velocità prescelta \param{speed} all'interno della struttura puntata da
-\param{termios\_p}; per effettuare l'impostazione effettiva occorrerà poi
+velocità prescelta \param{speed} all'interno della struttura puntata da
+\param{termios\_p}; per effettuare l'impostazione effettiva occorrerà poi
 chiamare \func{tcsetattr}.
 
-Si tenga presente che per le linee seriali solo alcuni valori di velocità sono
+Si tenga presente che per le linee seriali solo alcuni valori di velocità sono
 validi; questi possono essere specificati direttamente (le \acr{glibc}
 prevedono che i valori siano indicati in bit per secondo), ma in generale
 altre versioni di librerie possono utilizzare dei valori diversi; per questo
-POSIX.1 prevede una serie di costanti che però servono solo per specificare le
-velocità tipiche delle linee seriali:
+POSIX.1 prevede una serie di costanti che però servono solo per specificare le
+velocità tipiche delle linee seriali:
 \begin{verbatim}
      B0       B50      B75      B110     B134     B150     B200     
      B300     B600     B1200    B1800    B2400    B4800    B9600    
      B19200   B38400   B57600   B115200  B230400  B460800
 \end{verbatim}
 
-Un terminale può utilizzare solo alcune delle velocità possibili, le funzioni
-però non controllano se il valore specificato è valido, dato che non possono
-sapere a quale terminale le velocità saranno applicate; sarà l'esecuzione di
-\func{tcsetattr} a fallire quando si cercherà di eseguire l'impostazione.
+Un terminale può utilizzare solo alcune delle velocità possibili, le funzioni
+però non controllano se il valore specificato è valido, dato che non possono
+sapere a quale terminale le velocità saranno applicate; sarà l'esecuzione di
+\func{tcsetattr} a fallire quando si cercherà di eseguire l'impostazione.
 Di norma il valore ha senso solo per i terminali seriali dove indica appunto
-la velocità della linea di trasmissione; se questa non corrisponde a quella
-del terminale quest'ultimo non potrà funzionare: quando il terminale non è
-seriale il valore non influisce sulla velocità di trasmissione dei dati. 
+la velocità della linea di trasmissione; se questa non corrisponde a quella
+del terminale quest'ultimo non potrà funzionare: quando il terminale non è
+seriale il valore non influisce sulla velocità di trasmissione dei dati. 
 
 In generale impostare un valore nullo (\val{B0}) sulla linea di output fa si
-che il modem non asserisca più le linee di controllo, interrompendo di fatto
+che il modem non asserisca più le linee di controllo, interrompendo di fatto
 la connessione, qualora invece si utilizzi questo valore per la linea di input
-l'effetto sarà quello di rendere la sua velocità identica a quella della linea
+l'effetto sarà quello di rendere la sua velocità identica a quella della linea
 di output.
 
-Analogamente a quanto avviene per l'impostazione, le velocità possono essere
+Analogamente a quanto avviene per l'impostazione, le velocità possono essere
 lette da una struttura \struct{termios} utilizzando altre due funzioni,
 \funcd{cfgetispeed} e \funcd{cfgetospeed}, i cui prototipi sono:
 \begin{functions}
   \headdecl{unistd.h} 
   \headdecl{termios.h}  
   \funcdecl{speed\_t cfgetispeed(struct termios *termios\_p)} 
-  Legge la velocità delle linee seriali in ingresso.
+  Legge la velocità delle linee seriali in ingresso.
   
   \funcdecl{speed\_t cfgetospeed(struct termios *termios\_p)} 
-  Legge la velocità delle linee seriali in uscita.
+  Legge la velocità delle linee seriali in uscita.
   
-  \bodydesc{Entrambe le funzioni restituiscono la velocità della linea, non
+  \bodydesc{Entrambe le funzioni restituiscono la velocità della linea, non
   sono previste condizioni di errore.}
 \end{functions}
 
-Anche in questo caso le due funzioni estraggono i valori della velocità della
-linea da una struttura, il cui indirizzo è specificato dall'argomento
+Anche in questo caso le due funzioni estraggono i valori della velocità della
+linea da una struttura, il cui indirizzo è specificato dall'argomento
 \param{termios\_p} che deve essere stata letta in precedenza con
 \func{tcgetattr}.
 
@@ -1781,7 +1781,7 @@ linea da una struttura, il cui indirizzo 
 \label{sec:term_line_discipline}
 
 Come illustrato dalla struttura riportata in fig.~\ref{fig:term_struct} tutti
-i terminali hanno un insieme di funzionalità comuni, che prevedono la presenza
+i terminali hanno un insieme di funzionalità comuni, che prevedono la presenza
 di code di ingresso ed uscita; in generale si fa riferimento ad esse con il
 nome di \textsl{discipline di linea}.
 
@@ -1792,12 +1792,12 @@ vengono considerate, dal punto di vista dell'accesso al terminale, come delle
 funzioni di scrittura, pertanto se usate da processi in background sul loro
 terminale di controllo provocano l'emissione di \const{SIGTTOU} come
 illustrato in sez.~\ref{sec:sess_ctrl_term}.\footnote{con la stessa eccezione,
-  già vista per \func{tcsetattr}, che quest'ultimo sia bloccato o ignorato dal
+  già vista per \func{tcsetattr}, che quest'ultimo sia bloccato o ignorato dal
   processo chiamante.}
 
-Una prima funzione, che è efficace solo in caso di terminali seriali asincroni
-(non fa niente per tutti gli altri terminali), è \funcd{tcsendbreak}; il suo
-prototipo è:
+Una prima funzione, che è efficace solo in caso di terminali seriali asincroni
+(non fa niente per tutti gli altri terminali), è \funcd{tcsendbreak}; il suo
+prototipo è:
 \begin{functions}
   \headdecl{unistd.h} 
   \headdecl{termios.h}  
@@ -1806,21 +1806,21 @@ prototipo 
   break inviando un flusso di bit nulli.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
+    errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
     \errval{ENOTTY}.}
 \end{functions}
 
 La funzione invia un flusso di bit nulli (che genera una condizione di break)
 sul terminale associato a \param{fd}; un valore nullo di \param{duration}
 implica una durata del flusso fra 0.25 e 0.5 secondi, un valore diverso da
-zero implica una durata pari a \code{duration*T} dove \code{T} è un valore
+zero implica una durata pari a \code{duration*T} dove \code{T} è un valore
 compreso fra 0.25 e 0.5.\footnote{lo standard POSIX specifica il comportamento
   solo nel caso si sia impostato un valore nullo per \param{duration}; il
-  comportamento negli altri casi può dipendere dalla implementazione.}
+  comportamento negli altri casi può dipendere dalla implementazione.}
 
 Le altre funzioni previste da POSIX servono a controllare il comportamento
-dell'interazione fra le code associate al terminale e l'utente; la prima è
-\funcd{tcdrain}, il cui prototipo è:
+dell'interazione fra le code associate al terminale e l'utente; la prima è
+\funcd{tcdrain}, il cui prototipo è:
 \begin{functions}
   \headdecl{unistd.h} 
   \headdecl{termios.h}  
@@ -1828,19 +1828,19 @@ dell'interazione fra le code associate al terminale e l'utente; la prima 
   \funcdecl{int tcdrain(int fd)} Attende lo svuotamento della coda di output.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
+    errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
     \errval{ENOTTY}.}
 \end{functions}
 
 La funzione blocca il processo fino a che tutto l'output presente sulla coda
-di uscita non è stato trasmesso al terminale associato ad \param{fd}. % La
-                                % funzione è  un punto di cancellazione per i
+di uscita non è stato trasmesso al terminale associato ad \param{fd}. % La
+                                % funzione è  un punto di cancellazione per i
                                 % programmi multi-thread, in tal caso le
                                 % chiamate devono essere protette con dei
                                 % gestori di cancellazione. 
 
 Una seconda funzione, \funcd{tcflush}, permette svuotare immediatamente le code
-di cancellando tutti i dati presenti al loro interno; il suo prototipo è:
+di cancellando tutti i dati presenti al loro interno; il suo prototipo è:
 \begin{functions}
   \headdecl{unistd.h} \headdecl{termios.h}
   
@@ -1848,16 +1848,16 @@ di cancellando tutti i dati presenti al loro interno; il suo prototipo 
   nelle code di ingresso o di uscita.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
+    errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
     \errval{ENOTTY}.}
 \end{functions}
 
 La funzione agisce sul terminale associato a \param{fd}, l'argomento
 \param{queue} permette di specificare su quale coda (ingresso, uscita o
-entrambe), operare. Esso può prendere i valori riportati in
+entrambe), operare. Esso può prendere i valori riportati in
 tab.~\ref{tab:sess_tcflush_queue}, nel caso si specifichi la coda di ingresso
-cancellerà i dati ricevuti ma non ancora letti, nel caso si specifichi la coda
-di uscita cancellerà i dati scritti ma non ancora trasmessi.
+cancellerà i dati ricevuti ma non ancora letti, nel caso si specifichi la coda
+di uscita cancellerà i dati scritti ma non ancora trasmessi.
 
 \begin{table}[htb]
   \footnotesize
@@ -1878,9 +1878,9 @@ di uscita canceller
 \end{table}
 
 
-L'ultima funzione dell'interfaccia che interviene sulla disciplina di linea è
+L'ultima funzione dell'interfaccia che interviene sulla disciplina di linea è
 \funcd{tcflow}, che viene usata per sospendere la trasmissione e la ricezione
-dei dati sul terminale; il suo prototipo è:
+dei dati sul terminale; il suo prototipo è:
 \begin{functions}
   \headdecl{unistd.h} 
   \headdecl{termios.h}  
@@ -1890,13 +1890,13 @@ dei dati sul terminale; il suo prototipo 
   Sospende e riavvia il flusso dei dati sul terminale.
 
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
+    errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
     \errval{ENOTTY}.}
 \end{functions}
 
 La funzione permette di controllare (interrompendo e facendo riprendere) il
 flusso dei dati fra il terminale ed il sistema sia in ingresso che in uscita.
-Il comportamento della funzione è regolato dall'argomento \param{action}, i
+Il comportamento della funzione è regolato dall'argomento \param{action}, i
 cui possibili valori, e relativa azione eseguita dalla funzione, sono
 riportati in tab.~\ref{tab:sess_tcflow_action}.
 
@@ -1926,14 +1926,14 @@ riportati in tab.~\ref{tab:sess_tcflow_action}.
 \subsection{Operare in \textsl{modo non canonico}}
 \label{sec:term_non_canonical}
 
-Operare con un terminale in modo canonico è relativamente semplice; basta
-eseguire una lettura e la funzione ritornerà quando una il driver del
-terminale avrà completato una linea di input. Non è detto che la linea sia
-letta interamente (si può aver richiesto un numero inferiore di byte) ma in
-ogni caso nessun dato verrà perso, e il resto della linea sarà letto alla
+Operare con un terminale in modo canonico è relativamente semplice; basta
+eseguire una lettura e la funzione ritornerà quando una il driver del
+terminale avrà completato una linea di input. Non è detto che la linea sia
+letta interamente (si può aver richiesto un numero inferiore di byte) ma in
+ogni caso nessun dato verrà perso, e il resto della linea sarà letto alla
 chiamata successiva.
 
-Inoltre in modo canonico la gestione dell'input è di norma eseguita
+Inoltre in modo canonico la gestione dell'input è di norma eseguita
 direttamente dal driver del terminale, che si incarica (a seconda di quanto
 impostato con le funzioni viste nei paragrafi precedenti) di cancellare i
 caratteri, bloccare e riavviare il flusso dei dati, terminare la linea quando
@@ -1941,36 +1941,36 @@ viene ricevuti uno dei vari caratteri di terminazione (NL, EOL, EOL2, EOF).
 
 In modo non canonico tocca invece al programma gestire tutto quanto, i
 caratteri NL, EOL, EOL2, EOF, ERASE, KILL, CR, REPRINT non vengono
-interpretati automaticamente ed inoltre, non dividendo più l'input in linee,
-il sistema non ha più un limite definito per quando ritornare i dati ad un
+interpretati automaticamente ed inoltre, non dividendo più l'input in linee,
+il sistema non ha più un limite definito per quando ritornare i dati ad un
 processo. Per questo motivo abbiamo visto che in \var{c\_cc} sono previsti due
 caratteri speciali, MIN e TIME (specificati dagli indici \const{VMIN} e
 \const{VTIME} in \var{c\_cc}) che dicono al sistema di ritornare da una
-\func{read} quando è stata letta una determinata quantità di dati o è passato
+\func{read} quando è stata letta una determinata quantità di dati o è passato
 un certo tempo.
 
 Come accennato nella relativa spiegazione in tab.~\ref{tab:sess_termios_cc},
-TIME e MIN non sono in realtà caratteri ma valori numerici. Il comportamento
-del sistema per un terminale in modalità non canonica prevede quattro casi
+TIME e MIN non sono in realtà caratteri ma valori numerici. Il comportamento
+del sistema per un terminale in modalità non canonica prevede quattro casi
 distinti:
 \begin{description}
 \item[MIN$>0$, TIME$>0$] In questo caso MIN stabilisce il numero minimo di
   caratteri desiderati e TIME un tempo di attesa, in decimi di secondo, fra un
   carattere e l'altro. Una \func{read} ritorna se vengono ricevuti almeno MIN
-  caratteri prima della scadenza di TIME (MIN è solo un limite inferiore, se
+  caratteri prima della scadenza di TIME (MIN è solo un limite inferiore, se
   la funzione ha richiesto un numero maggiore di caratteri ne possono essere
-  restituiti di più); se invece TIME scade vengono restituiti i byte ricevuti
+  restituiti di più); se invece TIME scade vengono restituiti i byte ricevuti
   fino ad allora (un carattere viene sempre letto, dato che il timer inizia a
   scorrere solo dopo la ricezione del primo carattere).
 \item[MIN$>0$, TIME$=0$] Una \func{read} ritorna solo dopo che sono stati
-  ricevuti almeno MIN caratteri. Questo significa che una \func{read} può
+  ricevuti almeno MIN caratteri. Questo significa che una \func{read} può
   bloccarsi indefinitamente. 
 \item[MIN$=0$, TIME$>0$] In questo caso TIME indica un tempo di attesa dalla
   chiamata di \func{read}, la funzione ritorna non appena viene ricevuto un
-  carattere o scade il tempo. Si noti che è possibile che \func{read} ritorni
+  carattere o scade il tempo. Si noti che è possibile che \func{read} ritorni
   con un valore nullo.
 \item[MIN$=0$, TIME$=0$] In questo caso una \func{read} ritorna immediatamente
-  restituendo tutti i caratteri ricevuti. Anche in questo caso può ritornare
+  restituendo tutti i caratteri ricevuti. Anche in questo caso può ritornare
   con un valore nullo.
 \end{description}
 
@@ -1981,7 +1981,7 @@ distinti:
 
 % 
 % TODO terminali virtuali 
-% Qui c'è da mettere tutta la parte sui terminali virtuali, e la gestione
+% Qui c'è da mettere tutta la parte sui terminali virtuali, e la gestione
 % degli stessi
 %
 
@@ -2049,4 +2049,4 @@ Qui vanno le cose su \func{openpty} e compagnia.
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"
-%%% End: 
\ No newline at end of file
+%%% End: 
diff --git a/signal.tex b/signal.tex
index b3e1a76..2fa2d6f 100644
--- a/signal.tex
+++ b/signal.tex
@@ -12,8 +12,8 @@
 \chapter{I segnali}
 \label{cha:signals}
 
-I segnali sono il primo e più semplice meccanismo di comunicazione nei
-confronti dei processi. Nella loro versione originale essi portano con sé
+I segnali sono il primo e più semplice meccanismo di comunicazione nei
+confronti dei processi. Nella loro versione originale essi portano con sé
 nessuna informazione che non sia il loro tipo; si tratta in sostanza di
 un'interruzione software portata ad un processo.
 
@@ -25,7 +25,7 @@ esempio vengono usati per il controllo di sessione), per notificare eventi
 
 In questo capitolo esamineremo i vari aspetti della gestione dei segnali,
 partendo da una introduzione relativa ai concetti base con cui essi vengono
-realizzati, per poi affrontarne la classificazione a secondo di uso e modalità
+realizzati, per poi affrontarne la classificazione a secondo di uso e modalità
 di generazione fino ad esaminare in dettaglio le funzioni e le metodologie di
 gestione avanzate e le estensioni fatte all'interfaccia classica nelle nuovi
 versioni dello standard POSIX.
@@ -36,7 +36,7 @@ versioni dello standard POSIX.
 
 In questa sezione esamineremo i concetti generali relativi ai segnali, vedremo
 le loro caratteristiche di base, introdurremo le nozioni di fondo relative
-all'architettura del funzionamento dei segnali e alle modalità con cui il
+all'architettura del funzionamento dei segnali e alle modalità con cui il
 sistema gestisce l'interazione fra di essi ed i processi.
 
 
@@ -45,7 +45,7 @@ sistema gestisce l'interazione fra di essi ed i processi.
 
 Come il nome stesso indica i segnali sono usati per notificare ad un processo
 l'occorrenza di un qualche evento. Gli eventi che possono generare un segnale
-sono vari; un breve elenco di possibili cause per l'emissione di un segnale è
+sono vari; un breve elenco di possibili cause per l'emissione di un segnale è
 il seguente:
 
 \begin{itemize*}
@@ -53,7 +53,7 @@ il seguente:
   accesso alla memoria fuori dai limiti validi;
 \item la terminazione di un processo figlio;
 \item la scadenza di un timer o di un allarme;
-\item il tentativo di effettuare un'operazione di input/output che non può
+\item il tentativo di effettuare un'operazione di input/output che non può
   essere eseguita;
 \item una richiesta dell'utente di terminare o fermare il programma. In genere
   si realizza attraverso un segnale mandato dalla shell in corrispondenza
@@ -71,14 +71,14 @@ kernel che causa la generazione di un particolare tipo di segnale.
 Quando un processo riceve un segnale, invece del normale corso del programma,
 viene eseguita una azione predefinita o una apposita funzione di gestione
 (quello che da qui in avanti chiameremo il \textsl{gestore} del segnale,
-dall'inglese \textit{signal handler}) che può essere stata specificata
+dall'inglese \textit{signal handler}) che può essere stata specificata
 dall'utente (nel qual caso si dice che si \textsl{intercetta} il segnale).
 
 
 \subsection{Le \textsl{semantiche} del funzionamento dei segnali}
 \label{sec:sig_semantics}
 
-Negli anni il comportamento del sistema in risposta ai segnali è stato
+Negli anni il comportamento del sistema in risposta ai segnali è stato
 modificato in vari modi nelle differenti implementazioni di Unix.  Si possono
 individuare due tipologie fondamentali di comportamento dei segnali (dette
 \textsl{semantiche}) che vengono chiamate rispettivamente \textsl{semantica
@@ -87,21 +87,21 @@ individuare due tipologie fondamentali di comportamento dei segnali (dette
 
 Nella \textsl{semantica inaffidabile} (quella implementata dalle prime
 versioni di Unix) la funzione di gestione del segnale specificata dall'utente
-non resta attiva una volta che è stata eseguita; è perciò compito dell'utente
+non resta attiva una volta che è stata eseguita; è perciò compito dell'utente
 stesso ripetere l'installazione all'interno del \textsl{gestore} del segnale,
 in tutti quei casi in cui si vuole che esso resti attivo.
 
-In questo caso è possibile una situazione in cui i segnali possono essere
+In questo caso è possibile una situazione in cui i segnali possono essere
 perduti. Si consideri il segmento di codice riportato in
 fig.~\ref{fig:sig_old_handler}, nel programma principale viene installato un
 gestore (\texttt{\small 5}), ed in quest'ultimo la prima operazione
-(\texttt{\small 11}) è quella di reinstallare se stesso. Se nell'esecuzione
+(\texttt{\small 11}) è quella di reinstallare se stesso. Se nell'esecuzione
 del gestore un secondo segnale arriva prima che esso abbia potuto eseguire la
-reinstallazione, verrà eseguito il comportamento predefinito assegnato al
-segnale stesso, il che può comportare, a seconda dei casi, che il segnale
+reinstallazione, verrà eseguito il comportamento predefinito assegnato al
+segnale stesso, il che può comportare, a seconda dei casi, che il segnale
 viene perso (se l'impostazione predefinita era quello di ignorarlo) o la
 terminazione immediata del processo; in entrambi i casi l'azione prevista non
-verrà eseguita.
+verrà eseguita.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -114,16 +114,16 @@ verr
   \label{fig:sig_old_handler}
 \end{figure}
 
-Questa è la ragione per cui l'implementazione dei segnali secondo questa
+Questa è la ragione per cui l'implementazione dei segnali secondo questa
 semantica viene chiamata \textsl{inaffidabile}; infatti la ricezione del
 segnale e la reinstallazione del suo gestore non sono operazioni atomiche, e
 sono sempre possibili delle \itindex{race~condition} \textit{race condition}
 (sull'argomento vedi quanto detto in sez.~\ref{sec:proc_multi_prog}).
 
-Un altro problema è che in questa semantica non esiste un modo per bloccare i
+Un altro problema è che in questa semantica non esiste un modo per bloccare i
 segnali quando non si vuole che arrivino; i processi possono ignorare il
-segnale, ma non è possibile istruire il sistema a non fare nulla in occasione
-di un segnale, pur mantenendo memoria del fatto che è avvenuto.
+segnale, ma non è possibile istruire il sistema a non fare nulla in occasione
+di un segnale, pur mantenendo memoria del fatto che è avvenuto.
 
 Nella semantica \textsl{affidabile} (quella utilizzata da Linux e da ogni Unix
 moderno) il gestore una volta installato resta attivo e non si hanno tutti i
@@ -136,21 +136,21 @@ genere questo viene fatto dal kernel impostando l'apposito campo della
 Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
 \textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
 per tutto il tempo che passa fra la generazione del segnale e la sua consegna
-esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
+esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
 procedura viene effettuata dallo \itindex{scheduler} scheduler quando,
 riprendendo l'esecuzione del processo in questione, verifica la presenza del
 segnale nella \struct{task\_struct} e mette in esecuzione il gestore.
 
-In questa semantica un processo ha la possibilità di bloccare la consegna dei
-segnali, in questo caso, se l'azione per il suddetto segnale non è quella di
+In questa semantica un processo ha la possibilità di bloccare la consegna dei
+segnali, in questo caso, se l'azione per il suddetto segnale non è quella di
 ignorarlo, il segnale resta \textsl{pendente} fintanto che il processo non lo
 sblocca (nel qual caso viene consegnato) o imposta l'azione corrispondente per
 ignorarlo.
 
-Si tenga presente che il kernel stabilisce cosa fare con un segnale che è
+Si tenga presente che il kernel stabilisce cosa fare con un segnale che è
 stato bloccato al momento della consegna, non quando viene generato; questo
 consente di cambiare l'azione per il segnale prima che esso venga consegnato,
-e si può usare la funzione \func{sigpending} (vedi sez.~\ref{sec:sig_sigmask})
+e si può usare la funzione \func{sigpending} (vedi sez.~\ref{sec:sig_sigmask})
 per determinare quali segnali sono bloccati e quali sono pendenti.
 
 
@@ -160,9 +160,9 @@ per determinare quali segnali sono bloccati e quali sono pendenti.
 In generale gli eventi che generano segnali si possono dividere in tre
 categorie principali: errori, eventi esterni e richieste esplicite.
 
-Un errore significa che un programma ha fatto qualcosa di sbagliato e non può
+Un errore significa che un programma ha fatto qualcosa di sbagliato e non può
 continuare ad essere eseguito. Non tutti gli errori causano dei segnali, in
-genere le condizioni di errore più comuni comportano la restituzione di un
+genere le condizioni di errore più comuni comportano la restituzione di un
 codice di errore da parte di una funzione di libreria; sono gli errori che
 possono avvenire nella esecuzione delle istruzioni di un programma che causano
 l'emissione di un segnale, come le divisioni per zero o l'uso di indirizzi di
@@ -175,12 +175,12 @@ input, scadenze di un timer, terminazione di processi figli.
 Una richiesta esplicita significa l'uso di una chiamata di sistema (come
 \func{kill} o \func{raise}) per la generazione di un segnale, cosa che
 viene fatta usualmente dalla shell quando l'utente invoca la sequenza di tasti
-di stop o di suspend, ma può essere pure inserita all'interno di un programma.
+di stop o di suspend, ma può essere pure inserita all'interno di un programma.
 
 Si dice poi che i segnali possono essere \textsl{asincroni} o
-\textsl{sincroni}. Un segnale \textsl{sincrono} è legato ad una azione
-specifica di un programma ed è inviato (a meno che non sia bloccato) durante
-tale azione; molti errori generano segnali \textsl{sincroni}, così come la
+\textsl{sincroni}. Un segnale \textsl{sincrono} è legato ad una azione
+specifica di un programma ed è inviato (a meno che non sia bloccato) durante
+tale azione; molti errori generano segnali \textsl{sincroni}, così come la
 richiesta esplicita da parte del processo tramite le chiamate al sistema.
 Alcuni errori come la divisione per zero non sono completamente sincroni e
 possono arrivare dopo qualche istruzione.
@@ -188,13 +188,13 @@ possono arrivare dopo qualche istruzione.
 I segnali \textsl{asincroni} sono generati da eventi fuori dal controllo del
 processo che li riceve, e arrivano in tempi impredicibili nel corso
 dell'esecuzione del programma. Eventi esterni come la terminazione di un
-processo figlio generano segnali \textsl{asincroni}, così come le richieste di
+processo figlio generano segnali \textsl{asincroni}, così come le richieste di
 generazione di un segnale effettuate da altri processi.
 
-In generale un tipo di segnale o è sincrono o è asincrono, salvo il caso in
+In generale un tipo di segnale o è sincrono o è asincrono, salvo il caso in
 cui esso sia generato attraverso una richiesta esplicita tramite chiamata al
 sistema, nel qual caso qualunque tipo di segnale (quello scelto nella
-chiamata) può diventare sincrono o asincrono a seconda che sia generato
+chiamata) può diventare sincrono o asincrono a seconda che sia generato
 internamente o esternamente al processo.
 
 
@@ -202,37 +202,37 @@ internamente o esternamente al processo.
 \label{sec:sig_notification}
 
 Come accennato quando un segnale viene generato, se la sua azione predefinita
-non è quella di essere ignorato, il kernel prende nota del fatto nella
-\struct{task\_struct} del processo; si dice così che il segnale diventa
+non è quella di essere ignorato, il kernel prende nota del fatto nella
+\struct{task\_struct} del processo; si dice così che il segnale diventa
 \textsl{pendente} (o \textit{pending}), e rimane tale fino al momento in cui
-verrà notificato al processo (o verrà specificata come azione quella di
+verrà notificato al processo (o verrà specificata come azione quella di
 ignorarlo).
 
-Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
+Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
 avviene non appena questo viene rimesso in esecuzione dallo
 \itindex{scheduler} scheduler che esegue l'azione specificata. Questo a meno
 che il segnale in questione non sia stato bloccato prima della notifica, nel
 qual caso l'invio non avviene ed il segnale resta \textsl{pendente}
-indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
-notificato. Si tenga presente però che i segnali \textsl{pendenti} non si
+indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
+notificato. Si tenga presente però che i segnali \textsl{pendenti} non si
 accodano, alla generazione infatti il kernel marca un flag nella
 \struct{task\_struct} del processo, per cui se prima della notifica ne vengono
-generati altri il flag è comunque marcato, ed il gestore viene eseguito sempre
+generati altri il flag è comunque marcato, ed il gestore viene eseguito sempre
 una sola volta.
 
-Si ricordi però che se l'azione specificata per un segnale è quella di essere
-ignorato questo sarà scartato immediatamente al momento della sua generazione,
-e questo anche se in quel momento il segnale è bloccato (perché bloccare su un
+Si ricordi però che se l'azione specificata per un segnale è quella di essere
+ignorato questo sarà scartato immediatamente al momento della sua generazione,
+e questo anche se in quel momento il segnale è bloccato (perché bloccare su un
 segnale significa bloccarne la notifica). Per questo motivo un segnale,
-fintanto che viene ignorato, non sarà mai notificato, anche se prima è stato
-bloccato ed in seguito si è specificata una azione diversa (nel qual caso solo
+fintanto che viene ignorato, non sarà mai notificato, anche se prima è stato
+bloccato ed in seguito si è specificata una azione diversa (nel qual caso solo
 i segnali successivi alla nuova specificazione saranno notificati).
 
 Una volta che un segnale viene notificato (che questo avvenga subito o dopo
-una attesa più o meno lunga) viene eseguita l'azione specificata per il
+una attesa più o meno lunga) viene eseguita l'azione specificata per il
 segnale. Per alcuni segnali (\const{SIGKILL} e \const{SIGSTOP}) questa azione
-è fissa e non può essere cambiata, ma per tutti gli altri si può selezionare
-una  delle tre possibilità seguenti:
+è fissa e non può essere cambiata, ma per tutti gli altri si può selezionare
+una  delle tre possibilità seguenti:
 
 \begin{itemize*}
 \item ignorare il segnale;
@@ -240,22 +240,22 @@ una  delle tre possibilit
 \item accettare l'azione predefinita per quel segnale.
 \end{itemize*}
 
-Un programma può specificare queste scelte usando le due funzioni
+Un programma può specificare queste scelte usando le due funzioni
 \func{signal} e \func{sigaction} (vedi sez.~\ref{sec:sig_signal} e
-sez.~\ref{sec:sig_sigaction}). Se si è installato un gestore sarà quest'ultimo
-ad essere eseguito alla notifica del segnale.  Inoltre il sistema farà si che
+sez.~\ref{sec:sig_sigaction}). Se si è installato un gestore sarà quest'ultimo
+ad essere eseguito alla notifica del segnale.  Inoltre il sistema farà si che
 mentre viene eseguito il gestore di un segnale, quest'ultimo venga
-automaticamente bloccato (così si possono evitare \itindex{race~condition}
+automaticamente bloccato (così si possono evitare \itindex{race~condition}
 \textit{race condition}).
 
 Nel caso non sia stata specificata un'azione, viene utilizzata l'azione
-standard che (come vedremo in sez.~\ref{sec:sig_standard}) è propria di ciascun
+standard che (come vedremo in sez.~\ref{sec:sig_standard}) è propria di ciascun
 segnale; nella maggior parte dei casi essa porta alla terminazione del
 processo, ma alcuni segnali che rappresentano eventi innocui vengono ignorati.
 
-Quando un segnale termina un processo, il padre può determinare la causa della
+Quando un segnale termina un processo, il padre può determinare la causa della
 terminazione esaminando il codice di stato riportato dalle funzioni
-\func{wait} e \func{waitpid} (vedi sez.~\ref{sec:proc_wait}); questo è il modo
+\func{wait} e \func{waitpid} (vedi sez.~\ref{sec:proc_wait}); questo è il modo
 in cui la shell determina i motivi della terminazione di un programma e scrive
 un eventuale messaggio di errore.
 
@@ -263,7 +263,7 @@ I segnali che rappresentano errori del programma (divisione per zero o
 violazioni di accesso) hanno anche la caratteristica di scrivere un file di
 \itindex{core~dump} \textit{core dump} che registra lo stato del processo (ed
 in particolare della memoria e dello \itindex{stack} \textit{stack}) prima
-della terminazione.  Questo può essere esaminato in seguito con un debugger
+della terminazione.  Questo può essere esaminato in seguito con un debugger
 per investigare sulla causa dell'errore.  Lo stesso avviene se i suddetti
 segnali vengono generati con una \func{kill}.
 
@@ -279,9 +279,9 @@ di identificarli, e le funzioni che ne stampano la descrizione.
 \subsection{I segnali standard}
 \label{sec:sig_standard}
 
-Ciascun segnale è identificato rispetto al sistema da un numero, ma l'uso
-diretto di questo numero da parte dei programmi è da evitare, in quanto esso
-può variare a seconda dell'implementazione del sistema, e nel caso di Linux,
+Ciascun segnale è identificato rispetto al sistema da un numero, ma l'uso
+diretto di questo numero da parte dei programmi è da evitare, in quanto esso
+può variare a seconda dell'implementazione del sistema, e nel caso di Linux,
 anche a seconda dell'architettura hardware. 
 Per questo motivo ad ogni segnale viene associato un nome, definendo con una
 macro di preprocessore una costante uguale al suddetto numero. Sono questi
@@ -289,10 +289,10 @@ nomi, che sono standardizzati e sostanzialmente uniformi rispetto alle varie
 implementazioni, che si devono usare nei programmi. Tutti i nomi e le funzioni
 che concernono i segnali sono definiti nell'header di sistema \file{signal.h}.
 
-Il numero totale di segnali presenti è dato dalla macro \const{NSIG}, e dato
+Il numero totale di segnali presenti è dato dalla macro \const{NSIG}, e dato
 che i numeri dei segnali sono allocati progressivamente, essa corrisponde
 anche al successivo del valore numerico assegnato all'ultimo segnale definito.
-In tab.~\ref{tab:sig_signal_list} si è riportato l'elenco completo dei segnali
+In tab.~\ref{tab:sig_signal_list} si è riportato l'elenco completo dei segnali
 definiti in Linux (estratto dalle pagine di manuale), comparati con quelli
 definiti in vari standard.
 
@@ -304,13 +304,13 @@ definiti in vari standard.
     \textbf{Sigla} & \textbf{Significato} \\
     \hline
     \hline
-    A & L'azione predefinita è terminare il processo.\\
-    B & L'azione predefinita è ignorare il segnale.\\
-    C & L'azione predefinita è terminare il processo e scrivere un 
+    A & L'azione predefinita è terminare il processo.\\
+    B & L'azione predefinita è ignorare il segnale.\\
+    C & L'azione predefinita è terminare il processo e scrivere un 
         \itindex{core~dump} \textit{core dump}.\\
-    D & L'azione predefinita è fermare il processo.\\
-    E & Il segnale non può essere intercettato.\\
-    F & Il segnale non può essere ignorato.\\
+    D & L'azione predefinita è fermare il processo.\\
+    E & Il segnale non può essere intercettato.\\
+    F & Il segnale non può essere ignorato.\\
     \hline
   \end{tabular}
   \caption{Legenda delle azioni predefinite dei segnali riportate in 
@@ -319,11 +319,11 @@ definiti in vari standard.
 \end{table}
 
 In tab.~\ref{tab:sig_signal_list} si sono anche riportate le azioni predefinite
-di ciascun segnale (riassunte con delle lettere, la cui legenda completa è in
-tab.~\ref{tab:sig_action_leg}), quando nessun gestore è installato un
-segnale può essere ignorato o causare la terminazione del processo. Nella
+di ciascun segnale (riassunte con delle lettere, la cui legenda completa è in
+tab.~\ref{tab:sig_action_leg}), quando nessun gestore è installato un
+segnale può essere ignorato o causare la terminazione del processo. Nella
 colonna standard sono stati indicati anche gli standard in cui ciascun segnale
-è definito, secondo lo schema di tab.~\ref{tab:sig_standard_leg}.
+è definito, secondo lo schema di tab.~\ref{tab:sig_standard_leg}.
 
 
 \begin{table}[htb]
@@ -345,10 +345,10 @@ colonna standard sono stati indicati anche gli standard in cui ciascun segnale
   \label{tab:sig_standard_leg}
 \end{table}
 
-In alcuni casi alla terminazione del processo è associata la creazione di un
+In alcuni casi alla terminazione del processo è associata la creazione di un
 file (posto nella directory corrente del processo e chiamato \file{core}) su
 cui viene salvata un'immagine della memoria del processo (il cosiddetto
-\itindex{core~dump} \textit{core dump}), che può essere usata da un debugger
+\itindex{core~dump} \textit{core dump}), che può essere usata da un debugger
 per esaminare lo stato dello \itindex{stack} \textit{stack} e delle variabili
 al momento della ricezione del segnale.
 
@@ -397,13 +397,13 @@ al momento della ricezione del segnale.
     \const{SIGEMT}   &L  &   &                                               \\
 % TODO che roba e` SIGEMT
     \const{SIGSTKFLT}&L  & A & Errore sullo stack del coprocessore.          \\
-    \const{SIGIO}    &LB & A & L'I/O è possibile (4.2 BSD).                  \\
+    \const{SIGIO}    &LB & A & L'I/O è possibile (4.2 BSD).                  \\
     \const{SIGCLD}   &L  &   & Sinonimo di \const{SIGCHLD}.                  \\
     \const{SIGPWR}   &L  & A & Fallimento dell'alimentazione.                \\
     \const{SIGINFO}  &L  &   & Sinonimo di \const{SIGPWR}.                   \\
     \const{SIGLOST}  &L  & A & Perso un lock sul file (per NFS).             \\
     \const{SIGWINCH} &LB & B & Finestra ridimensionata (4.3 BSD, Sun).       \\
-    \const{SIGUNUSED}&L  & A & Segnale inutilizzato (diventerà 
+    \const{SIGUNUSED}&L  & A & Segnale inutilizzato (diventerà 
                                \const{SIGSYS}).                              \\
     \hline
   \end{tabular}
@@ -412,7 +412,7 @@ al momento della ricezione del segnale.
 \end{table}
 
 La descrizione dettagliata del significato dei vari segnali, raggruppati per
-tipologia, verrà affrontata nei paragrafi successivi.
+tipologia, verrà affrontata nei paragrafi successivi.
 
 
 \subsection{Segnali di errore di programma}
@@ -423,28 +423,28 @@ l'hardware (come per i \itindex{page~fault} \textit{page fault} non validi)
 rileva un qualche errore insanabile nel programma in esecuzione. In generale
 la generazione di questi segnali significa che il programma ha dei gravi
 problemi (ad esempio ha dereferenziato un puntatore non valido o ha eseguito
-una operazione aritmetica proibita) e l'esecuzione non può essere proseguita.
+una operazione aritmetica proibita) e l'esecuzione non può essere proseguita.
 
 In genere si intercettano questi segnali per permettere al programma di
 terminare in maniera pulita, ad esempio per ripristinare le impostazioni della
 console o eliminare i \index{file!di lock} file di lock prima dell'uscita.  In
 questo caso il gestore deve concludersi ripristinando l'azione predefinita e
-rialzando il segnale, in questo modo il programma si concluderà senza effetti
+rialzando il segnale, in questo modo il programma si concluderà senza effetti
 spiacevoli, ma riportando lo stesso stato di uscita che avrebbe avuto se il
 gestore non ci fosse stato.
 
-L'azione predefinita per tutti questi segnali è causare la terminazione del
+L'azione predefinita per tutti questi segnali è causare la terminazione del
 processo che li ha causati. In genere oltre a questo il segnale provoca pure
 la registrazione su disco di un file di \itindex{core~dump} \textit{core dump}
 che viene scritto in un file \file{core} nella directory corrente del processo
-al momento dell'errore, che il debugger può usare per ricostruire lo stato del
+al momento dell'errore, che il debugger può usare per ricostruire lo stato del
 programma al momento della terminazione.  Questi segnali sono:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
+\item[\const{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
   derivi da \textit{floating point exception} si applica a tutti gli errori
   aritmetici compresa la divisione per zero e l'overflow.  Se il gestore
-  ritorna il comportamento del processo è indefinito, ed ignorare questo
-  segnale può condurre ad un ciclo infinito.
+  ritorna il comportamento del processo è indefinito, ed ignorare questo
+  segnale può condurre ad un ciclo infinito.
 
 %   Per questo segnale le cose sono complicate dal fatto che possono esserci
 %   molte diverse eccezioni che \texttt{SIGFPE} non distingue, mentre lo
@@ -454,27 +454,27 @@ programma al momento della terminazione.  Questi segnali sono:
   
 \item[\const{SIGILL}] Il nome deriva da \textit{illegal instruction},
   significa che il programma sta cercando di eseguire una istruzione
-  privilegiata o inesistente, in generale del codice illecito. Poiché il
+  privilegiata o inesistente, in generale del codice illecito. Poiché il
   compilatore del C genera del codice valido si ottiene questo segnale se il
-  file eseguibile è corrotto o si stanno cercando di eseguire dei dati.
-  Quest'ultimo caso può accadere quando si passa un puntatore sbagliato al
+  file eseguibile è corrotto o si stanno cercando di eseguire dei dati.
+  Quest'ultimo caso può accadere quando si passa un puntatore sbagliato al
   posto di un puntatore a funzione, o si eccede la scrittura di un vettore di
   una variabile locale, andando a corrompere lo \itindex{stack}
   \textit{stack}. Lo stesso segnale viene generato in caso di overflow dello
   \itindex{stack} \textit{stack} o di problemi nell'esecuzione di un gestore.
-  Se il gestore ritorna il comportamento del processo è indefinito.
+  Se il gestore ritorna il comportamento del processo è indefinito.
 \item[\const{SIGSEGV}] Il nome deriva da \itindex{segment~violation}
   \textit{segment violation}, e significa che il programma sta cercando di
   leggere o scrivere in una zona di memoria protetta al di fuori di quella che
-  gli è stata riservata dal sistema. In genere è il meccanismo della
+  gli è stata riservata dal sistema. In genere è il meccanismo della
   protezione della memoria che si accorge dell'errore ed il kernel genera il
-  segnale.  Se il gestore ritorna il comportamento del processo è indefinito.
+  segnale.  Se il gestore ritorna il comportamento del processo è indefinito.
 
-  È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
-  inizializzato leggendo al di là della fine di un vettore. 
+  È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
+  inizializzato leggendo al di là della fine di un vettore. 
 \item[\const{SIGBUS}] Il nome deriva da \textit{bus error}. Come
-  \const{SIGSEGV} questo è un segnale che viene generato di solito quando si
-  dereferenzia un puntatore non inizializzato, la differenza è che
+  \const{SIGSEGV} questo è un segnale che viene generato di solito quando si
+  dereferenzia un puntatore non inizializzato, la differenza è che
   \const{SIGSEGV} indica un accesso non permesso su un indirizzo esistente
   (tipo fuori dallo heap o dallo \itindex{stack} \textit{stack}), mentre
   \const{SIGBUS} indica l'accesso ad un indirizzo non valido, come nel caso di
@@ -482,11 +482,11 @@ programma al momento della terminazione.  Questi segnali sono:
 \item[\const{SIGABRT}] Il nome deriva da \textit{abort}. Il segnale indica che
   il programma stesso ha rilevato un errore che viene riportato chiamando la
   funzione \func{abort} che genera questo segnale.
-\item[\const{SIGTRAP}] È il segnale generato da un'istruzione di breakpoint o
-  dall'attivazione del tracciamento per il processo. È usato dai programmi per
+\item[\const{SIGTRAP}] È il segnale generato da un'istruzione di breakpoint o
+  dall'attivazione del tracciamento per il processo. È usato dai programmi per
   il debugging e un programma normale non dovrebbe ricevere questo segnale.
-\item[\const{SIGSYS}] Sta ad indicare che si è eseguita una istruzione che
-  richiede l'esecuzione di una system call, ma si è fornito un codice
+\item[\const{SIGSYS}] Sta ad indicare che si è eseguita una istruzione che
+  richiede l'esecuzione di una system call, ma si è fornito un codice
   sbagliato per quest'ultima.
 \end{basedescript}
 
@@ -495,67 +495,67 @@ programma al momento della terminazione.  Questi segnali sono:
 \label{sec:sig_termination}
 
 Questo tipo di segnali sono usati per terminare un processo; hanno vari nomi a
-causa del differente uso che se ne può fare, ed i programmi possono
+causa del differente uso che se ne può fare, ed i programmi possono
 trattarli in maniera differente. 
 
-La ragione per cui può essere necessario trattare questi segnali è che il
-programma può dover eseguire una serie di azioni di pulizia prima di
+La ragione per cui può essere necessario trattare questi segnali è che il
+programma può dover eseguire una serie di azioni di pulizia prima di
 terminare, come salvare informazioni sullo stato in cui si trova, cancellare
 file temporanei, o ripristinare delle condizioni alterate durante il
 funzionamento (come il modo del terminale o le impostazioni di una qualche
 periferica).
 
-L'azione predefinita di questi segnali è di terminare il processo, questi
+L'azione predefinita di questi segnali è di terminare il processo, questi
 segnali sono:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{SIGTERM}] Il nome sta per \textit{terminate}. È un segnale
+\item[\const{SIGTERM}] Il nome sta per \textit{terminate}. È un segnale
   generico usato per causare la conclusione di un programma. Al contrario di
-  \const{SIGKILL} può essere intercettato, ignorato, bloccato. In genere lo si
+  \const{SIGKILL} può essere intercettato, ignorato, bloccato. In genere lo si
   usa per chiedere in maniera ``\textsl{educata}'' ad un processo di
   concludersi.
 
-\item[\const{SIGINT}] Il nome sta per \textit{interrupt}. È il segnale di
-  interruzione per il programma. È quello che viene generato di default dal
+\item[\const{SIGINT}] Il nome sta per \textit{interrupt}. È il segnale di
+  interruzione per il programma. È quello che viene generato di default dal
   comando \cmd{kill} o dall'invio sul terminale del carattere di controllo
   INTR (interrupt, generato dalla sequenza \cmd{C-c}).
 
-\item[\const{SIGQUIT}] È analogo a \const{SIGINT} con la differenza che è
+\item[\const{SIGQUIT}] È analogo a \const{SIGINT} con la differenza che è
   controllato da un altro carattere di controllo, QUIT, corrispondente alla
   sequenza \texttt{C-\bslash}. A differenza del precedente l'azione
   predefinita, oltre alla terminazione del processo, comporta anche la
   creazione di un \itindex{core~dump} \textit{core dump}.
 
-  In genere lo si può pensare come corrispondente ad una condizione di errore
-  del programma rilevata dall'utente. Per questo motivo non è opportuno fare
+  In genere lo si può pensare come corrispondente ad una condizione di errore
+  del programma rilevata dall'utente. Per questo motivo non è opportuno fare
   eseguire al gestore di questo segnale le operazioni di pulizia normalmente
   previste (tipo la cancellazione di file temporanei), dato che in certi casi
   esse possono eliminare informazioni utili nell'esame dei \itindex{core~dump}
   \textit{core dump}.
   
 
-\item[\const{SIGKILL}] Il nome è utilizzato per terminare in maniera immediata
-  qualunque programma. Questo segnale non può essere né intercettato, né
-  ignorato, né bloccato, per cui causa comunque la terminazione del processo.
+\item[\const{SIGKILL}] Il nome è utilizzato per terminare in maniera immediata
+  qualunque programma. Questo segnale non può essere né intercettato, né
+  ignorato, né bloccato, per cui causa comunque la terminazione del processo.
   In genere esso viene generato solo per richiesta esplicita dell'utente dal
-  comando (o tramite la funzione) \cmd{kill}. Dato che non lo si può
-  intercettare è sempre meglio usarlo come ultima risorsa quando metodi meno
+  comando (o tramite la funzione) \cmd{kill}. Dato che non lo si può
+  intercettare è sempre meglio usarlo come ultima risorsa quando metodi meno
   brutali, come \const{SIGTERM} o \cmd{C-c} non funzionano. 
 
   Se un processo non risponde a nessun altro segnale \const{SIGKILL} ne causa
   sempre la terminazione (in effetti il fallimento della terminazione di un
   processo da parte di \const{SIGKILL} costituirebbe un malfunzionamento del
-  kernel). Talvolta è il sistema stesso che può generare questo segnale quando
-  per condizioni particolari il processo non può più essere eseguito neanche
+  kernel). Talvolta è il sistema stesso che può generare questo segnale quando
+  per condizioni particolari il processo non può più essere eseguito neanche
   per eseguire un gestore.
 
 \item[\const{SIGHUP}] Il nome sta per \textit{hang-up}. Segnala che il
-  terminale dell'utente si è disconnesso (ad esempio perché si è interrotta la
+  terminale dell'utente si è disconnesso (ad esempio perché si è interrotta la
   rete). Viene usato anche per riportare la terminazione del processo di
   controllo di un terminale a tutti i processi della sessione, in modo che
   essi possano disconnettersi dal relativo terminale. 
   
   Viene inoltre usato in genere per segnalare ai demoni (che non hanno un
-  terminale di controllo) la necessità di reinizializzarsi e rileggere il/i
+  terminale di controllo) la necessità di reinizializzarsi e rileggere il/i
   file di configurazione.
 \end{basedescript}
 
@@ -564,16 +564,16 @@ segnali sono:
 \label{sec:sig_alarm}
 
 Questi segnali sono generati dalla scadenza di un timer (vedi
-sez.~\ref{sec:sig_alarm_abort}). Il loro comportamento predefinito è quello di
+sez.~\ref{sec:sig_alarm_abort}). Il loro comportamento predefinito è quello di
 causare la terminazione del programma, ma con questi segnali la scelta
-predefinita è irrilevante, in quanto il loro uso presuppone sempre la
-necessità di un gestore.  Questi segnali sono:
+predefinita è irrilevante, in quanto il loro uso presuppone sempre la
+necessità di un gestore.  Questi segnali sono:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\const{SIGALRM}] Il nome sta per \textit{alarm}. Segnale la scadenza di
-  un timer misurato sul tempo reale o sull'orologio di sistema. È normalmente
+  un timer misurato sul tempo reale o sull'orologio di sistema. È normalmente
   usato dalla funzione \func{alarm}.
 
-\item[\const{SIVGTALRM}] Il nome sta per \textit{virtual alarm}. È analogo al
+\item[\const{SIVGTALRM}] Il nome sta per \textit{virtual alarm}. È analogo al
   precedente ma segnala la scadenza di un timer sul tempo di CPU usato dal
   processo. 
 
@@ -590,22 +590,22 @@ necessit
 
 Questi segnali operano in congiunzione con le funzioni di I/O asincrono. Per
 questo occorre comunque usare \func{fcntl} per abilitare un file descriptor a
-generare questi segnali.  L'azione predefinita è di essere ignorati. Questi
+generare questi segnali.  L'azione predefinita è di essere ignorati. Questi
 segnali sono:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{SIGIO}] Questo segnale viene inviato quando un file descriptor è
+\item[\const{SIGIO}] Questo segnale viene inviato quando un file descriptor è
   pronto per eseguire dell'input/output. In molti sistemi solo i
   socket e i terminali possono generare questo segnale, in Linux
-  questo può essere usato anche per i file, posto che la \func{fcntl} abbia
+  questo può essere usato anche per i file, posto che la \func{fcntl} abbia
   avuto successo.
 
-\item[\const{SIGURG}] Questo segnale è inviato quando arrivano dei dati
+\item[\const{SIGURG}] Questo segnale è inviato quando arrivano dei dati
   urgenti o \itindex{out-of-band} \textit{out-of-band} su di un
   socket; per maggiori dettagli al proposito si veda
   sez.~\ref{sec:TCP_urgent_data}.
 
-\item[\const{SIGPOLL}] Questo segnale è equivalente a \const{SIGIO}, è
-  definito solo per compatibilità con i sistemi System V.
+\item[\const{SIGPOLL}] Questo segnale è equivalente a \const{SIGIO}, è
+  definito solo per compatibilità con i sistemi System V.
 \end{basedescript}
 
 
@@ -613,53 +613,53 @@ segnali sono:
 \label{sec:sig_job_control}
 
 Questi sono i segnali usati dal controllo delle sessioni e dei processi, il
-loro uso è specializzato e viene trattato in maniera specifica nelle sezioni
+loro uso è specializzato e viene trattato in maniera specifica nelle sezioni
 in cui si trattano gli argomenti relativi.  Questi segnali sono:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{SIGCHLD}] Questo è il segnale mandato al processo padre quando un
-  figlio termina o viene fermato. L'azione predefinita è di ignorare il
-  segnale, la sua gestione è trattata in sez.~\ref{sec:proc_wait}.
+\item[\const{SIGCHLD}] Questo è il segnale mandato al processo padre quando un
+  figlio termina o viene fermato. L'azione predefinita è di ignorare il
+  segnale, la sua gestione è trattata in sez.~\ref{sec:proc_wait}.
 
-\item[\const{SIGCLD}] Per Linux questo è solo un segnale identico al
-  precedente, il nome è obsoleto e andrebbe evitato. 
+\item[\const{SIGCLD}] Per Linux questo è solo un segnale identico al
+  precedente, il nome è obsoleto e andrebbe evitato. 
 
 \item[\const{SIGCONT}] Il nome sta per \textit{continue}. Il segnale viene
   usato per fare ripartire un programma precedentemente fermato da
   \const{SIGSTOP}. Questo segnale ha un comportamento speciale, e fa sempre
   ripartire il processo prima della sua consegna. Il comportamento predefinito
-  è di fare solo questo; il segnale non può essere bloccato. Si può anche
+  è di fare solo questo; il segnale non può essere bloccato. Si può anche
   installare un gestore, ma il segnale provoca comunque il riavvio del
   processo.
   
-  La maggior pare dei programmi non hanno necessità di intercettare il
-  segnale, in quanto esso è completamente trasparente rispetto all'esecuzione
+  La maggior pare dei programmi non hanno necessità di intercettare il
+  segnale, in quanto esso è completamente trasparente rispetto all'esecuzione
   che riparte senza che il programma noti niente. Si possono installare dei
   gestori per far si che un programma produca una qualche azione speciale
   se viene fermato e riavviato, come per esempio riscrivere un prompt, o
   inviare un avviso. 
-\item[\const{SIGSTOP}] Il segnale ferma un processo (lo porta cioè in uno
-  stato di sleep, vedi sez.~\ref{sec:proc_sched}); il segnale non può essere né
-  intercettato, né ignorato, né bloccato.
+\item[\const{SIGSTOP}] Il segnale ferma un processo (lo porta cioè in uno
+  stato di sleep, vedi sez.~\ref{sec:proc_sched}); il segnale non può essere né
+  intercettato, né ignorato, né bloccato.
 
 \item[\const{SIGTSTP}] Il nome sta per \textit{interactive stop}. Il segnale
-  ferma il processo interattivamente, ed è generato dal carattere SUSP
+  ferma il processo interattivamente, ed è generato dal carattere SUSP
   (prodotto dalla combinazione \cmd{C-z}), ed al contrario di
-  \const{SIGSTOP} può essere intercettato e ignorato. In genere un programma
+  \const{SIGSTOP} può essere intercettato e ignorato. In genere un programma
   installa un gestore per questo segnale quando vuole lasciare il sistema
   o il terminale in uno stato definito prima di fermarsi; se per esempio un
-  programma ha disabilitato l'eco sul terminale può installare un gestore
+  programma ha disabilitato l'eco sul terminale può installare un gestore
   per riabilitarlo prima di fermarsi.
 
-\item[\const{SIGTTIN}] Un processo non può leggere dal terminale se esegue una
+\item[\const{SIGTTIN}] Un processo non può leggere dal terminale se esegue una
   sessione di lavoro in \textit{background}. Quando un processo in background
   tenta di leggere da un terminale viene inviato questo segnale a tutti i
-  processi della sessione di lavoro. L'azione predefinita è di fermare il
-  processo.  L'argomento è trattato in
+  processi della sessione di lavoro. L'azione predefinita è di fermare il
+  processo.  L'argomento è trattato in
   sez.~\ref{sec:sess_job_control_overview}.
 
 \item[\const{SIGTTOU}] Segnale analogo al precedente \const{SIGTTIN}, ma
   generato quando si tenta di scrivere o modificare uno dei modi del
-  terminale. L'azione predefinita è di fermare il processo, l'argomento è
+  terminale. L'azione predefinita è di fermare il processo, l'argomento è
   trattato in sez.~\ref{sec:sess_job_control_overview}.
 \end{basedescript}
 
@@ -670,27 +670,27 @@ in cui si trattano gli argomenti relativi.  Questi segnali sono:
 Questi segnali sono usati per riportare al programma errori generati da
 operazioni da lui eseguite; non indicano errori del programma quanto errori
 che impediscono il completamento dell'esecuzione dovute all'interazione con il
-resto del sistema.  L'azione predefinita di questi segnali è di terminare il
+resto del sistema.  L'azione predefinita di questi segnali è di terminare il
 processo, questi segnali sono:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\const{SIGPIPE}] Sta per \textit{Broken pipe}. Se si usano delle pipe,
-  (o delle FIFO o dei socket) è necessario, prima che un processo inizi a
+  (o delle FIFO o dei socket) è necessario, prima che un processo inizi a
   scrivere su una di esse, che un altro l'abbia aperta in lettura (si veda
-  sez.~\ref{sec:ipc_pipes}). Se il processo in lettura non è partito o è
+  sez.~\ref{sec:ipc_pipes}). Se il processo in lettura non è partito o è
   terminato inavvertitamente alla scrittura sulla pipe il kernel genera questo
-  segnale. Se il segnale è bloccato, intercettato o ignorato la chiamata che
+  segnale. Se il segnale è bloccato, intercettato o ignorato la chiamata che
   lo ha causato fallisce, restituendo l'errore \errcode{EPIPE}.
-\item[\const{SIGLOST}] Sta per \textit{Resource lost}. Tradizionalmente è il
+\item[\const{SIGLOST}] Sta per \textit{Resource lost}. Tradizionalmente è il
   segnale che viene generato quando si perde un advisory lock su un file su
-  NFS perché il server NFS è stato riavviato. Il progetto GNU lo utilizza per
-  indicare ad un client il crollo inaspettato di un server. In Linux è
-  definito come sinonimo di \const{SIGIO}.\footnote{ed è segnalato come BUG
+  NFS perché il server NFS è stato riavviato. Il progetto GNU lo utilizza per
+  indicare ad un client il crollo inaspettato di un server. In Linux è
+  definito come sinonimo di \const{SIGIO}.\footnote{ed è segnalato come BUG
     nella pagina di manuale.}
 \item[\const{SIGXCPU}] Sta per \textit{CPU time limit exceeded}. Questo
-  segnale è generato quando un processo eccede il limite impostato per il
+  segnale è generato quando un processo eccede il limite impostato per il
   tempo di CPU disponibile, vedi sez.~\ref{sec:sys_resource_limit}. 
 \item[\const{SIGXFSZ}] Sta per \textit{File size limit exceeded}. Questo
-  segnale è generato quando un processo tenta di estendere un file oltre le
+  segnale è generato quando un processo tenta di estendere un file oltre le
   dimensioni specificate dal limite impostato per le dimensioni massime di un
   file, vedi sez.~\ref{sec:sys_resource_limit}. 
 \end{basedescript}
@@ -702,20 +702,20 @@ processo, questi segnali sono:
 Raccogliamo qui infine una serie di segnali che hanno scopi differenti non
 classificabili in maniera omogenea. Questi segnali sono:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{SIGUSR1}] Insieme a \const{SIGUSR2} è un segnale a disposizione
-  dell'utente che lo può usare per quello che vuole. Viene generato solo
+\item[\const{SIGUSR1}] Insieme a \const{SIGUSR2} è un segnale a disposizione
+  dell'utente che lo può usare per quello che vuole. Viene generato solo
   attraverso l'invocazione della funzione \func{kill}. Entrambi i segnali
   possono essere utili per implementare una comunicazione elementare fra
   processi diversi, o per eseguire a richiesta una operazione utilizzando un
-  gestore. L'azione predefinita è di terminare il processo.
-\item[\const{SIGUSR2}] È il secondo segnale a disposizione degli utenti. Vedi
+  gestore. L'azione predefinita è di terminare il processo.
+\item[\const{SIGUSR2}] È il secondo segnale a disposizione degli utenti. Vedi
   quanto appena detto per \const{SIGUSR1}.
 \item[\const{SIGWINCH}] Il nome sta per \textit{window (size) change} e viene
   generato in molti sistemi (GNU/Linux compreso) quando le dimensioni (in
   righe e colonne) di un terminale vengono cambiate. Viene usato da alcuni
   programmi testuali per riformattare l'uscita su schermo quando si cambia
-  dimensione a quest'ultimo. L'azione predefinita è di essere ignorato.
-\item[\const{SIGINFO}] Il segnale indica una richiesta di informazioni. È
+  dimensione a quest'ultimo. L'azione predefinita è di essere ignorato.
+\item[\const{SIGINFO}] Il segnale indica una richiesta di informazioni. È
   usato con il controllo di sessione, causa la stampa di informazioni da parte
   del processo leader del gruppo associato al terminale di controllo, gli
   altri processi lo ignorano.
@@ -728,36 +728,36 @@ classificabili in maniera omogenea. Questi segnali sono:
 Per la descrizione dei segnali il sistema mette a disposizione due funzioni
 che stampano un messaggio di descrizione dato il numero. In genere si usano
 quando si vuole notificare all'utente il segnale ricevuto (nel caso di
-terminazione di un processo figlio o di un gestore che gestisce più segnali);
-la prima funzione, \funcd{strsignal}, è una estensione GNU, accessibile avendo
-definito \macro{\_GNU\_SOURCE}, ed è analoga alla funzione \func{strerror} (si
+terminazione di un processo figlio o di un gestore che gestisce più segnali);
+la prima funzione, \funcd{strsignal}, è una estensione GNU, accessibile avendo
+definito \macro{\_GNU\_SOURCE}, ed è analoga alla funzione \func{strerror} (si
 veda sez.~\ref{sec:sys_strerror}) per gli errori:
 \begin{prototype}{string.h}{char *strsignal(int signum)} 
   Ritorna il puntatore ad una stringa che contiene la descrizione del segnale
   \param{signum}.
 \end{prototype}
-\noindent dato che la stringa è allocata staticamente non se ne deve
+\noindent dato che la stringa è allocata staticamente non se ne deve
 modificare il contenuto, che resta valido solo fino alla successiva chiamata
-di \func{strsignal}. Nel caso si debba mantenere traccia del messaggio sarà
+di \func{strsignal}. Nel caso si debba mantenere traccia del messaggio sarà
 necessario copiarlo.
 
-La seconda funzione, \funcd{psignal}, deriva da BSD ed è analoga alla funzione
+La seconda funzione, \funcd{psignal}, deriva da BSD ed è analoga alla funzione
 \func{perror} descritta sempre in sez.~\ref{sec:sys_strerror}; il suo prototipo
-è:
+è:
 \begin{prototype}{signal.h}{void psignal(int sig, const char *s)} 
   Stampa sullo standard error un messaggio costituito dalla stringa \param{s},
   seguita da due punti ed una descrizione del segnale indicato da \param{sig}.
 \end{prototype}
 
-Una modalità alternativa per utilizzare le descrizioni restituite da
-\func{strsignal} e \func{psignal} è quello di usare la variabile
-\var{sys\_siglist}, che è definita in \file{signal.h} e può essere acceduta
+Una modalità alternativa per utilizzare le descrizioni restituite da
+\func{strsignal} e \func{psignal} è quello di usare la variabile
+\var{sys\_siglist}, che è definita in \file{signal.h} e può essere acceduta
 con la dichiarazione:
 \includecodesnip{listati/siglist.c}
 
 L'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
 indicizzate per numero di segnale, per cui una chiamata del tipo di \code{char
-  *decr = strsignal(SIGINT)} può essere sostituita dall'equivalente \code{char
+  *decr = strsignal(SIGINT)} può essere sostituita dall'equivalente \code{char
   *decr = sys\_siglist[SIGINT]}.
 
 
@@ -765,10 +765,10 @@ indicizzate per numero di segnale, per cui una chiamata del tipo di \code{char
 \section{La gestione di base dei segnali}
 \label{sec:sig_management}
 
-I segnali sono il primo e più classico esempio di eventi asincroni, cioè di
+I segnali sono il primo e più classico esempio di eventi asincroni, cioè di
 eventi che possono accadere in un qualunque momento durante l'esecuzione di un
-programma. Per questa loro caratteristica la loro gestione non può essere
-effettuata all'interno del normale flusso di esecuzione dello stesso, ma è
+programma. Per questa loro caratteristica la loro gestione non può essere
+effettuata all'interno del normale flusso di esecuzione dello stesso, ma è
 delegata appunto agli eventuali gestori che si sono installati.
 
 In questa sezione vedremo come si effettua la gestione dei segnali, a partire
@@ -780,8 +780,8 @@ alla loro occorrenza.
 \subsection{Il comportamento generale del sistema}
 \label{sec:sig_gen_beha}
 
-Abbiamo già trattato in sez.~\ref{sec:sig_intro} le modalità con cui il sistema
-gestisce l'interazione fra segnali e processi, ci resta da esaminare però il
+Abbiamo già trattato in sez.~\ref{sec:sig_intro} le modalità con cui il sistema
+gestisce l'interazione fra segnali e processi, ci resta da esaminare però il
 comportamento delle system call; in particolare due di esse, \func{fork} ed
 \func{exec}, dovranno essere prese esplicitamente in considerazione, data la
 loro stretta relazione con la creazione di nuovi processi.
@@ -794,12 +794,12 @@ vengono cancellati; essi infatti devono essere recapitati solo al padre, al
 figlio dovranno arrivare solo i segnali dovuti alle sue azioni.
 
 Quando si mette in esecuzione un nuovo programma con \func{exec} (si ricordi
-quanto detto in sez.~\ref{sec:proc_exec}) tutti i segnali per i quali è stato
-installato un gestore vengono reimpostati a \const{SIG\_DFL}. Non ha più
+quanto detto in sez.~\ref{sec:proc_exec}) tutti i segnali per i quali è stato
+installato un gestore vengono reimpostati a \const{SIG\_DFL}. Non ha più
 senso infatti fare riferimento a funzioni definite nel programma originario,
 che non sono presenti nello spazio di indirizzi del nuovo programma.
 
-Si noti che questo vale solo per le azioni per le quali è stato installato un
+Si noti che questo vale solo per le azioni per le quali è stato installato un
 gestore; viene mantenuto invece ogni eventuale impostazione dell'azione a
 \const{SIG\_IGN}. Questo permette ad esempio alla shell di impostare ad
 \const{SIG\_IGN} le risposte per \const{SIGINT} e \const{SIGQUIT} per i
@@ -809,18 +809,18 @@ successiva pressione di \texttt{C-c} o \texttt{C-y}.
 Per quanto riguarda il comportamento di tutte le altre system call si danno
 sostanzialmente due casi, a seconda che esse siano \index{system~call~lente}
 \textsl{lente} (\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran
-parte di esse appartiene a quest'ultima categoria, che non è influenzata
+parte di esse appartiene a quest'ultima categoria, che non è influenzata
 dall'arrivo di un segnale. Esse sono dette \textsl{veloci} in quanto la loro
-esecuzione è sostanzialmente immediata; la risposta al segnale viene sempre
-data dopo che la system call è stata completata, in quanto attendere per
+esecuzione è sostanzialmente immediata; la risposta al segnale viene sempre
+data dopo che la system call è stata completata, in quanto attendere per
 eseguire un gestore non comporta nessun inconveniente.
 
-In alcuni casi però alcune system call (che per questo motivo vengono chiamate
-\textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
-attendere la conclusione della system call, perché questo renderebbe
+In alcuni casi però alcune system call (che per questo motivo vengono chiamate
+\textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
+attendere la conclusione della system call, perché questo renderebbe
 impossibile una risposta pronta al segnale, per cui il gestore viene
 eseguito prima che la system call sia ritornata.  Un elenco dei casi in cui si
-presenta questa situazione è il seguente:
+presenta questa situazione è il seguente:
 \begin{itemize*}
 \item la lettura da file che possono bloccarsi in attesa di dati non ancora
   presenti (come per certi \index{file!di~dispositivo} file di dispositivo, i
@@ -830,58 +830,58 @@ presenta questa situazione 
 \item l'apertura di un file di dispositivo che richiede operazioni non
   immediate per una risposta (ad esempio l'apertura di un nastro che deve
   essere riavvolto);
-\item le operazioni eseguite con \func{ioctl} che non è detto possano essere
+\item le operazioni eseguite con \func{ioctl} che non è detto possano essere
   eseguite immediatamente;
 \item le funzioni di intercomunicazione che si bloccano in attesa di risposte
   da altri processi;
 \item la funzione \func{pause} (usata appunto per attendere l'arrivo di un
   segnale);
-\item la funzione \func{wait} (se nessun processo figlio è ancora terminato).
+\item la funzione \func{wait} (se nessun processo figlio è ancora terminato).
 \end{itemize*}
 
 In questo caso si pone il problema di cosa fare una volta che il gestore sia
 ritornato. La scelta originaria dei primi Unix era quella di far ritornare
-anche la system call restituendo l'errore di \errcode{EINTR}. Questa è a
+anche la system call restituendo l'errore di \errcode{EINTR}. Questa è a
 tutt'oggi una scelta corrente, ma comporta che i programmi che usano dei
 gestori controllino lo stato di uscita delle funzioni che eseguono una system
 call lenta per ripeterne la chiamata qualora l'errore fosse questo.
 
-Dimenticarsi di richiamare una system call interrotta da un segnale è un
+Dimenticarsi di richiamare una system call interrotta da un segnale è un
 errore comune, tanto che le \acr{glibc} provvedono una macro
 \code{TEMP\_FAILURE\_RETRY(expr)} che esegue l'operazione automaticamente,
 ripetendo l'esecuzione dell'espressione \var{expr} fintanto che il risultato
-non è diverso dall'uscita con un errore \errcode{EINTR}.
+non è diverso dall'uscita con un errore \errcode{EINTR}.
 
-La soluzione è comunque poco elegante e BSD ha scelto un approccio molto
-diverso, che è quello di fare ripartire automaticamente una system call
-interrotta invece di farla fallire. In questo caso ovviamente non c'è bisogno
-di preoccuparsi di controllare il codice di errore; si perde però la
-possibilità di eseguire azioni specifiche all'occorrenza di questa particolare
+La soluzione è comunque poco elegante e BSD ha scelto un approccio molto
+diverso, che è quello di fare ripartire automaticamente una system call
+interrotta invece di farla fallire. In questo caso ovviamente non c'è bisogno
+di preoccuparsi di controllare il codice di errore; si perde però la
+possibilità di eseguire azioni specifiche all'occorrenza di questa particolare
 condizione.
 
 Linux e le \acr{glibc} consentono di utilizzare entrambi gli approcci,
 attraverso una opportuna opzione di \func{sigaction} (vedi
-sez.~\ref{sec:sig_sigaction}). È da chiarire comunque che nel caso di
+sez.~\ref{sec:sig_sigaction}). È da chiarire comunque che nel caso di
 interruzione nel mezzo di un trasferimento parziale di dati, le system call
 ritornano sempre indicando i byte trasferiti.
 
-% TODO: alcune syscall danno EINTR anche se il segnale è installato con
+% TODO: alcune syscall danno EINTR anche se il segnale è installato con
 % SA_RESTART, vedi signal(7)
 
 
 \subsection{La funzione \func{signal}}
 \label{sec:sig_signal}
 
-L'interfaccia più semplice per la gestione dei segnali è costituita dalla
-funzione \funcd{signal} che è definita fin dallo standard ANSI C.
-Quest'ultimo però non considera sistemi multitasking, per cui la definizione è
-tanto vaga da essere del tutto inutile in un sistema Unix; è questo il motivo
+L'interfaccia più semplice per la gestione dei segnali è costituita dalla
+funzione \funcd{signal} che è definita fin dallo standard ANSI C.
+Quest'ultimo però non considera sistemi multitasking, per cui la definizione è
+tanto vaga da essere del tutto inutile in un sistema Unix; è questo il motivo
 per cui ogni implementazione successiva ne ha modificato e ridefinito il
-comportamento, pur mantenendone immutato il prototipo\footnote{in realtà in
+comportamento, pur mantenendone immutato il prototipo\footnote{in realtà in
   alcune vecchie implementazioni (SVr4 e 4.3+BSD in particolare) vengono usati
   alcuni argomenti aggiuntivi per definire il comportamento della funzione,
-  vedremo in sez.~\ref{sec:sig_sigaction} che questo è possibile usando la
-  funzione \func{sigaction}.}  che è:
+  vedremo in sez.~\ref{sec:sig_sigaction} che questo è possibile usando la
+  funzione \func{sigaction}.}  che è:
 \begin{prototype}{signal.h}
   {sighandler\_t signal(int signum, sighandler\_t handler)} 
   
@@ -892,107 +892,107 @@ comportamento, pur mantenendone immutato il prototipo\footnote{in realt
     o \const{SIG\_ERR} in caso di errore.}
 \end{prototype}
 
-In questa definizione si è usato un tipo di dato, \type{sighandler\_t}, che è
+In questa definizione si è usato un tipo di dato, \type{sighandler\_t}, che è
 una estensione GNU, definita dalle \acr{glibc}, che permette di riscrivere il
-prototipo di \func{signal} nella forma appena vista, molto più leggibile di
-quanto non sia la versione originaria, che di norma è definita come:
+prototipo di \func{signal} nella forma appena vista, molto più leggibile di
+quanto non sia la versione originaria, che di norma è definita come:
 \includecodesnip{listati/signal.c}
 questa infatti, per la poca chiarezza della sintassi del C quando si vanno a
-trattare puntatori a funzioni, è molto meno comprensibile.  Da un confronto
-con il precedente prototipo si può dedurre la definizione di
-\type{sighandler\_t} che è:
+trattare puntatori a funzioni, è molto meno comprensibile.  Da un confronto
+con il precedente prototipo si può dedurre la definizione di
+\type{sighandler\_t} che è:
 \includecodesnip{listati/sighandler_t.c}
-e cioè un puntatore ad una funzione \ctyp{void} (cioè senza valore di ritorno)
+e cioè un puntatore ad una funzione \ctyp{void} (cioè senza valore di ritorno)
 e che prende un argomento di tipo \ctyp{int}.\footnote{si devono usare le
   parentesi intorno al nome della funzione per via delle precedenze degli
   operatori del C, senza di esse si sarebbe definita una funzione che ritorna
   un puntatore a \ctyp{void} e non un puntatore ad una funzione \ctyp{void}.}
 La funzione \func{signal} quindi restituisce e prende come secondo argomento
-un puntatore a una funzione di questo tipo, che è appunto la funzione che
-verrà usata come gestore del segnale.
+un puntatore a una funzione di questo tipo, che è appunto la funzione che
+verrà usata come gestore del segnale.
 
-Il numero di segnale passato nell'argomento \param{signum} può essere indicato
+Il numero di segnale passato nell'argomento \param{signum} può essere indicato
 direttamente con una delle costanti definite in sez.~\ref{sec:sig_standard}.
 L'argomento \param{handler} che indica il gestore invece, oltre all'indirizzo
-della funzione da chiamare all'occorrenza del segnale, può assumere anche i
+della funzione da chiamare all'occorrenza del segnale, può assumere anche i
 due valori costanti \const{SIG\_IGN} e \const{SIG\_DFL}; il primo indica che
-il segnale deve essere ignorato,\footnote{si ricordi però che i due segnali
-  \const{SIGKILL} e \const{SIGSTOP} non possono essere né ignorati né
+il segnale deve essere ignorato,\footnote{si ricordi però che i due segnali
+  \const{SIGKILL} e \const{SIGSTOP} non possono essere né ignorati né
   intercettati; l'uso di \const{SIG\_IGN} per questi segnali non ha alcun
   effetto.} mentre il secondo ripristina l'azione predefinita.\footnote{e
-  serve a tornare al comportamento di default quando non si intende più
+  serve a tornare al comportamento di default quando non si intende più
   gestire direttamente un segnale.}
 
-La funzione restituisce l'indirizzo dell'azione precedente, che può essere
+La funzione restituisce l'indirizzo dell'azione precedente, che può essere
 salvato per poterlo ripristinare (con un'altra chiamata a \func{signal}) in un
 secondo tempo. Si ricordi che se si imposta come azione \const{SIG\_IGN} (o si
-imposta un \const{SIG\_DFL} per un segnale la cui azione predefinita è di
+imposta un \const{SIG\_DFL} per un segnale la cui azione predefinita è di
 essere ignorato), tutti i segnali pendenti saranno scartati, e non verranno
 mai notificati.
 
-L'uso di \func{signal} è soggetto a problemi di compatibilità, dato che essa
+L'uso di \func{signal} è soggetto a problemi di compatibilità, dato che essa
 si comporta in maniera diversa per sistemi derivati da BSD o da System V. In
-questi ultimi infatti la funzione è conforme al comportamento originale dei
+questi ultimi infatti la funzione è conforme al comportamento originale dei
 primi Unix in cui il gestore viene disinstallato alla sua chiamata, secondo la
 semantica inaffidabile; anche Linux seguiva questa convenzione con le vecchie
 librerie del C come le \acr{libc4} e le \acr{libc5}.\footnote{nelle
-  \acr{libc5} esiste però la possibilità di includere \file{bsd/signal.h} al
+  \acr{libc5} esiste però la possibilità di includere \file{bsd/signal.h} al
   posto di \file{signal.h}, nel qual caso la funzione \func{signal} viene
   ridefinita per seguire la semantica affidabile usata da BSD.}
 
 Al contrario BSD segue la semantica affidabile, non disinstallando il gestore
 e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo delle
-\acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento.  Il
-comportamento della versione originale della funzione, il cui uso è deprecato
-per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto
+\acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento.  Il
+comportamento della versione originale della funzione, il cui uso è deprecato
+per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto
 chiamando \func{sysv\_signal}, una volta che si sia definita la macro
 \macro{\_XOPEN\_SOURCE}.  In generale, per evitare questi problemi, l'uso di
 \func{signal}, che tra l'altro ha un comportamento indefinito in caso di
-processo \itindex{thread} multi-\textit{thread}, è da evitare; tutti i nuovi
+processo \itindex{thread} multi-\textit{thread}, è da evitare; tutti i nuovi
 programmi dovrebbero usare \func{sigaction}.
 
-È da tenere presente che, seguendo lo standard POSIX, il comportamento di un
+È da tenere presente che, seguendo lo standard POSIX, il comportamento di un
 processo che ignora i segnali \const{SIGFPE}, \const{SIGILL}, o
 \const{SIGSEGV} (qualora questi non originino da una chiamata ad una
-\func{kill} o ad una \func{raise}) è indefinito. Un gestore che ritorna da
-questi segnali può dare luogo ad un ciclo infinito.
+\func{kill} o ad una \func{raise}) è indefinito. Un gestore che ritorna da
+questi segnali può dare luogo ad un ciclo infinito.
 
 
 \subsection{Le funzioni \func{kill} e \func{raise}}
 \label{sec:sig_kill_raise}
 
-Come precedentemente accennato in sez.~\ref{sec:sig_types}, un segnale può
+Come precedentemente accennato in sez.~\ref{sec:sig_types}, un segnale può
 anche essere generato direttamente nell'esecuzione di un programma, attraverso
 la chiamata ad una opportuna system call. Le funzioni che si utilizzano di
 solito per inviare un segnale generico ad un processo sono due: \func{raise} e
 \func{kill}.
 
-La prima funzione è \funcd{raise}, che è definita dallo standard ANSI C, e
+La prima funzione è \funcd{raise}, che è definita dallo standard ANSI C, e
 serve per inviare un segnale al processo corrente,\footnote{non prevedendo la
   presenza di un sistema multiutente lo standard ANSI C non poteva che
   definire una funzione che invia il segnale al programma in esecuzione. Nel
-  caso di Linux questa viene implementata come funzione di compatibilità.}  il
-suo prototipo è:
+  caso di Linux questa viene implementata come funzione di compatibilità.}  il
+suo prototipo è:
 \begin{prototype}{signal.h}{int raise(int sig)}
   Invia il segnale \param{sig} al processo corrente.
 
   \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
-    errore, il solo errore restituito è \errval{EINVAL} qualora si sia
+    errore, il solo errore restituito è \errval{EINVAL} qualora si sia
     specificato un numero di segnale invalido.}
 \end{prototype}
 
-Il valore di \param{sig} specifica il segnale che si vuole inviare e può
+Il valore di \param{sig} specifica il segnale che si vuole inviare e può
 essere specificato con una delle macro definite in
 sez.~\ref{sec:sig_classification}.  In genere questa funzione viene usata per
 riprodurre il comportamento predefinito di un segnale che sia stato
 intercettato. In questo caso, una volta eseguite le operazioni volute, il
-gestore dovrà prima reinstallare l'azione predefinita, per poi attivarla
+gestore dovrà prima reinstallare l'azione predefinita, per poi attivarla
 chiamando \func{raise}.
 
-Mentre \func{raise} è una funzione di libreria, quando si vuole inviare un
+Mentre \func{raise} è una funzione di libreria, quando si vuole inviare un
 segnale generico ad un processo occorre utilizzare la apposita system call,
-questa può essere chiamata attraverso la funzione \funcd{kill}, il cui
-prototipo è:
+questa può essere chiamata attraverso la funzione \funcd{kill}, il cui
+prototipo è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{signal.h}
@@ -1000,7 +1000,7 @@ prototipo 
   processo specificato con \param{pid}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore nel qual caso \var{errno} assumerà uno dei valori:
+    errore nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] il segnale specificato non esiste.
     \item[\errcode{ESRCH}] il processo selezionato non esiste.
@@ -1012,25 +1012,25 @@ prototipo 
 Lo standard POSIX prevede che il valore 0 per \param{sig} sia usato per
 specificare il segnale nullo.  Se la funzione viene chiamata con questo valore
 non viene inviato nessun segnale, ma viene eseguito il controllo degli errori,
-in tal caso si otterrà un errore \errcode{EPERM} se non si hanno i permessi
+in tal caso si otterrà un errore \errcode{EPERM} se non si hanno i permessi
 necessari ed un errore \errcode{ESRCH} se il processo specificato non esiste.
-Si tenga conto però che il sistema ricicla i \acr{pid} (come accennato in
+Si tenga conto però che il sistema ricicla i \acr{pid} (come accennato in
 sez.~\ref{sec:proc_pid}) per cui l'esistenza di un processo non significa che
 esso sia realmente quello a cui si intendeva mandare il segnale.
 
 Il valore dell'argomento \param{pid} specifica il processo (o i processi) di
-destinazione a cui il segnale deve essere inviato e può assumere i valori
+destinazione a cui il segnale deve essere inviato e può assumere i valori
 riportati in tab.~\ref{tab:sig_kill_values}.
 
-Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
-termini di \func{kill}, ed è sostanzialmente equivalente ad una
-\code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
+Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
+termini di \func{kill}, ed è sostanzialmente equivalente ad una
+\code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
 standard ISO C, non esiste in alcune vecchie versioni di Unix, in generale
-l'uso di \func{kill} finisce per essere più portabile.
+l'uso di \func{kill} finisce per essere più portabile.
 
-Una seconda funzione che può essere definita in termini di \func{kill} è
-\funcd{killpg}, che è sostanzialmente equivalente a
-\code{kill(-pidgrp, signal)}; il suo prototipo è:
+Una seconda funzione che può essere definita in termini di \func{kill} è
+\funcd{killpg}, che è sostanzialmente equivalente a
+\code{kill(-pidgrp, signal)}; il suo prototipo è:
 \begin{prototype}{signal.h}{int killpg(pid\_t pidgrp, int signal)} 
   
   Invia il segnale \param{signal} al \itindex{process~group} \textit{process
@@ -1050,11 +1050,11 @@ Una seconda funzione che pu
     \textbf{Valore} & \textbf{Significato} \\
     \hline
     \hline
-    $>0$ & Il segnale è mandato al processo con il \acr{pid} indicato.\\
-    0    & Il segnale è mandato ad ogni processo del \itindex{process~group}
+    $>0$ & Il segnale è mandato al processo con il \acr{pid} indicato.\\
+    0    & Il segnale è mandato ad ogni processo del \itindex{process~group}
            \textit{process group} del chiamante.\\ 
-    $-1$ & Il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\
-    $<-1$ & Il segnale è mandato ad ogni processo del \textit{process group} 
+    $-1$ & Il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\
+    $<-1$ & Il segnale è mandato ad ogni processo del \textit{process group} 
             \itindex{process~group} $|\code{pid}|$.\\
     \hline
   \end{tabular}
@@ -1063,14 +1063,14 @@ Una seconda funzione che pu
   \label{tab:sig_kill_values}
 \end{table}
 
-Solo l'amministratore può inviare un segnale ad un processo qualunque, in
+Solo l'amministratore può inviare un segnale ad un processo qualunque, in
 tutti gli altri casi l'user-ID reale o l'user-ID effettivo del processo
 chiamante devono corrispondere all'user-ID reale o all'user-ID salvato della
 destinazione. Fa eccezione il caso in cui il segnale inviato sia
 \const{SIGCONT}, nel quale occorre che entrambi i processi appartengano alla
 stessa sessione. Inoltre, dato il ruolo fondamentale che riveste nel sistema
-(si ricordi quanto visto in sez.~\ref{sec:sig_termination}), non è possibile
-inviare al processo 1 (cioè a \cmd{init}) segnali per i quali esso non abbia
+(si ricordi quanto visto in sez.~\ref{sec:sig_termination}), non è possibile
+inviare al processo 1 (cioè a \cmd{init}) segnali per i quali esso non abbia
 un gestore installato.
 
 Infine, seguendo le specifiche POSIX 1003.1-2001, l'uso della chiamata
@@ -1084,11 +1084,11 @@ segnale al processo che ha effettuato la chiamata.
 \subsection{Le funzioni \func{alarm}, \func{abort} ed i \textit{timer}}
 \label{sec:sig_alarm_abort}
 
-Un caso particolare di segnali generati a richiesta è quello che riguarda i
+Un caso particolare di segnali generati a richiesta è quello che riguarda i
 vari segnali di temporizzazione e \const{SIGABRT}, per ciascuno di questi
-segnali sono previste funzioni specifiche che ne effettuino l'invio. La più
-comune delle funzioni usate per la temporizzazione è \funcd{alarm} il cui
-prototipo è:
+segnali sono previste funzioni specifiche che ne effettuino l'invio. La più
+comune delle funzioni usate per la temporizzazione è \funcd{alarm} il cui
+prototipo è:
 \begin{prototype}{unistd.h}{unsigned int alarm(unsigned int seconds)}
   Predispone l'invio di \const{SIGALRM} dopo \param{seconds} secondi.
   
@@ -1102,14 +1102,14 @@ dopo un certo periodo di tempo), programmando l'emissione di un segnale (nel
 caso in questione \const{SIGALRM}) dopo il numero di secondi specificato da
 \param{seconds}.
 
-Se si specifica per \param{seconds} un valore nullo non verrà inviato nessun
+Se si specifica per \param{seconds} un valore nullo non verrà inviato nessun
 segnale; siccome alla chiamata viene cancellato ogni precedente allarme,
-questo può essere usato per cancellare una programmazione precedente. 
+questo può essere usato per cancellare una programmazione precedente. 
 
 La funzione inoltre ritorna il numero di secondi rimanenti all'invio
-dell'allarme programmato in precedenza. In questo modo è possibile controllare
-se non si è cancellato un precedente allarme e predisporre eventuali misure
-che permettano di gestire il caso in cui servono più interruzioni.
+dell'allarme programmato in precedenza. In questo modo è possibile controllare
+se non si è cancellato un precedente allarme e predisporre eventuali misure
+che permettano di gestire il caso in cui servono più interruzioni.
 
 In sez.~\ref{sec:sys_unix_time} abbiamo visto che ad ogni processo sono
 associati tre tempi diversi: il \textit{clock time}, l'\textit{user time} ed
@@ -1129,16 +1129,16 @@ processo tre diversi timer:
   di questo timer provoca l'emissione di \const{SIGPROF}.
 \end{itemize*}
 
-Il timer usato da \func{alarm} è il \textit{clock time}, e corrisponde cioè al
-tempo reale. La funzione come abbiamo visto è molto semplice, ma proprio per
+Il timer usato da \func{alarm} è il \textit{clock time}, e corrisponde cioè al
+tempo reale. La funzione come abbiamo visto è molto semplice, ma proprio per
 questo presenta numerosi limiti: non consente di usare gli altri timer, non
-può specificare intervalli di tempo con precisione maggiore del secondo e
+può specificare intervalli di tempo con precisione maggiore del secondo e
 genera il segnale una sola volta.
 
 Per ovviare a questi limiti Linux deriva da BSD la funzione \funcd{setitimer}
 che permette di usare un timer qualunque e l'invio di segnali periodici, al
-costo però di una maggiore complessità d'uso e di una minore portabilità. Il
-suo prototipo è:
+costo però di una maggiore complessità d'uso e di una minore portabilità. Il
+suo prototipo è:
 \begin{prototype}{sys/time.h}{int setitimer(int which, const struct
     itimerval *value, struct itimerval *ovalue)} 
   
@@ -1146,7 +1146,7 @@ suo prototipo 
   \param{value} sul timer specificato da \param{which}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori \errval{EINVAL} o
+    errore, nel qual caso \var{errno} assumerà uno dei valori \errval{EINVAL} o
     \errval{EFAULT}.}
 \end{prototype}
 
@@ -1172,19 +1172,19 @@ tab.~\ref{tab:sig_setitimer_values}.
 \end{table}
 
 Il valore della struttura specificata \param{value} viene usato per impostare
-il timer, se il puntatore \param{ovalue} non è nullo il precedente valore
+il timer, se il puntatore \param{ovalue} non è nullo il precedente valore
 viene salvato qui. I valori dei timer devono essere indicati attraverso una
 struttura \struct{itimerval}, definita in fig.~\ref{fig:file_stat_struct}.
 
-La struttura è composta da due membri, il primo, \var{it\_interval} definisce
+La struttura è composta da due membri, il primo, \var{it\_interval} definisce
 il periodo del timer; il secondo, \var{it\_value} il tempo mancante alla
 scadenza. Entrambi esprimono i tempi tramite una struttura \struct{timeval} che
 permette una precisione fino al microsecondo.
 
 Ciascun timer decrementa il valore di \var{it\_value} fino a zero, poi invia
 il segnale e reimposta \var{it\_value} al valore di \var{it\_interval}, in
-questo modo il ciclo verrà ripetuto; se invece il valore di \var{it\_interval}
-è nullo il timer si ferma.
+questo modo il ciclo verrà ripetuto; se invece il valore di \var{it\_interval}
+è nullo il timer si ferma.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -1198,11 +1198,11 @@ questo modo il ciclo verr
 \end{figure}
 
 L'uso di \func{setitimer} consente dunque un controllo completo di tutte le
-caratteristiche dei timer, ed in effetti la stessa \func{alarm}, benché
-definita direttamente nello standard POSIX.1, può a sua volta essere espressa
+caratteristiche dei timer, ed in effetti la stessa \func{alarm}, benché
+definita direttamente nello standard POSIX.1, può a sua volta essere espressa
 in termini di \func{setitimer}, come evidenziato dal manuale delle \acr{glibc}
 \cite{glibc} che ne riporta la definizione mostrata in
-fig.~\ref{fig:sig_alarm_def}.\footnote{questo comporta anche che non è il caso
+fig.~\ref{fig:sig_alarm_def}.\footnote{questo comporta anche che non è il caso
   di mescolare chiamate ad \func{abort} e a \func{setitimer}.}
 
 \begin{figure}[!htb]
@@ -1217,41 +1217,41 @@ fig.~\ref{fig:sig_alarm_def}.\footnote{questo comporta anche che non 
 
 Si deve comunque tenere presente che fino al kernel 2.6.16 la precisione di
 queste funzioni era limitata dalla frequenza del timer di sistema,\footnote{il
-  valore della costante \texttt{HZ}, di cui abbiamo già parlato in
+  valore della costante \texttt{HZ}, di cui abbiamo già parlato in
   sez.~\ref{sec:proc_hierarchy}.} in quanto le temporizzazioni erano calcolate
 in numero di interruzioni del timer (i cosiddetti \itindex{jiffies}
 ''\textit{jiffies}''), ed era assicurato soltanto che il segnale non sarebbe
-stato mai generato prima della scadenza programmata (l'arrotondamento cioè era
-effettuato per eccesso).\footnote{questo in realtà non è del tutto vero a
+stato mai generato prima della scadenza programmata (l'arrotondamento cioè era
+effettuato per eccesso).\footnote{questo in realtà non è del tutto vero a
   causa di un bug, presente fino al kernel 2.6.12, che in certe circostanze
   causava l'emissione del segnale con un arrotondamento per difetto.} L'uso
 del contatore dei \itindex{jiffies} \textit{jiffies}, un intero a 32 bit,
-comportava inoltre l'impossibilità di specificare tempi molto
+comportava inoltre l'impossibilità di specificare tempi molto
 lunghi.\footnote{superiori al valore della costante
   \const{MAX\_SEC\_IN\_JIFFIES}, pari, nel caso di default di un valore di
   \const{HZ} di 250, a circa 99 giorni e mezzo.} Con il cambiamento della
-rappresentazione effettuato nel kernel 2.6.16 questo problema è scomparso e
+rappresentazione effettuato nel kernel 2.6.16 questo problema è scomparso e
 con l'introduzione dei timer ad alta risoluzione (vedi
-sez.~\ref{sec:sig_timer_adv}) nel kernel 2.6.21 la precisione è diventata
+sez.~\ref{sec:sig_timer_adv}) nel kernel 2.6.21 la precisione è diventata
 quella fornita dall'hardware disponibile.
 
-Una seconda causa di potenziali ritardi è che il segnale viene generato alla
+Una seconda causa di potenziali ritardi è che il segnale viene generato alla
 scadenza del timer, ma poi deve essere consegnato al processo; se quest'ultimo
-è attivo (questo è sempre vero per \const{ITIMER\_VIRT}) la consegna è
-immediata, altrimenti può esserci un ulteriore ritardo che può variare a
+è attivo (questo è sempre vero per \const{ITIMER\_VIRT}) la consegna è
+immediata, altrimenti può esserci un ulteriore ritardo che può variare a
 seconda del carico del sistema.
 
-Questo ha una conseguenza che può indurre ad errori molto subdoli, si tenga
-conto poi che in caso di sistema molto carico, si può avere il caso patologico
+Questo ha una conseguenza che può indurre ad errori molto subdoli, si tenga
+conto poi che in caso di sistema molto carico, si può avere il caso patologico
 in cui un timer scade prima che il segnale di una precedente scadenza sia
 stato consegnato; in questo caso, per il comportamento dei segnali descritto
-in sez.~\ref{sec:sig_sigchld}, un solo segnale sarà consegnato. Per questo
-oggi l'uso di questa funzione è deprecato a favore dei \textit{POSIX timer}
+in sez.~\ref{sec:sig_sigchld}, un solo segnale sarà consegnato. Per questo
+oggi l'uso di questa funzione è deprecato a favore dei \textit{POSIX timer}
 che tratteremo in sez.~\ref{sec:sig_timer_adv}.
 
 Dato che sia \func{alarm} che \func{setitimer} non consentono di leggere il
-valore corrente di un timer senza modificarlo, è possibile usare la funzione
-\funcd{getitimer}, il cui prototipo è:
+valore corrente di un timer senza modificarlo, è possibile usare la funzione
+\funcd{getitimer}, il cui prototipo è:
 \begin{prototype}{sys/time.h}{int getitimer(int which, struct
     itimerval *value)}
   
@@ -1264,21 +1264,21 @@ valore corrente di un timer senza modificarlo, 
 \func{setitimer}. 
 
 
-L'ultima funzione che permette l'invio diretto di un segnale è \funcd{abort},
+L'ultima funzione che permette l'invio diretto di un segnale è \funcd{abort},
 che, come accennato in sez.~\ref{sec:proc_termination}, permette di abortire
 l'esecuzione di un programma tramite l'invio di \const{SIGABRT}. Il suo
-prototipo è:
+prototipo è:
 \begin{prototype}{stdlib.h}{void abort(void)}
   
   Abortisce il processo corrente.
   
-  \bodydesc{La funzione non ritorna, il processo è terminato inviando il
+  \bodydesc{La funzione non ritorna, il processo è terminato inviando il
   segnale di \const{SIGABRT}.}
 \end{prototype}
 
-La differenza fra questa funzione e l'uso di \func{raise} è che anche se il
-segnale è bloccato o ignorato, la funzione ha effetto lo stesso. Il segnale
-può però essere intercettato per effettuare eventuali operazioni di chiusura
+La differenza fra questa funzione e l'uso di \func{raise} è che anche se il
+segnale è bloccato o ignorato, la funzione ha effetto lo stesso. Il segnale
+può però essere intercettato per effettuare eventuali operazioni di chiusura
 prima della terminazione del processo.
 
 Lo standard ANSI C richiede inoltre che anche se il gestore ritorna, la
@@ -1293,36 +1293,36 @@ eventuali funzioni registrate con \func{atexit} e \func{on\_exit}.
 \subsection{Le funzioni di pausa e attesa}
 \label{sec:sig_pause_sleep}
 
-Sono parecchie le occasioni in cui si può avere necessità di sospendere
-temporaneamente l'esecuzione di un processo. Nei sistemi più elementari in
+Sono parecchie le occasioni in cui si può avere necessità di sospendere
+temporaneamente l'esecuzione di un processo. Nei sistemi più elementari in
 genere questo veniva fatto con un opportuno loop di attesa, ma in un sistema
-multitasking un loop di attesa è solo un inutile spreco di CPU, per questo ci
+multitasking un loop di attesa è solo un inutile spreco di CPU, per questo ci
 sono apposite funzioni che permettono di mettere un processo in stato di
 attesa.\footnote{si tratta in sostanza di funzioni che permettono di portare
   esplicitamente il processo in stato di \textit{sleep}, vedi
   sez.~\ref{sec:proc_sched}.}
 
 Il metodo tradizionale per fare attendere ad un processo fino all'arrivo di un
-segnale è quello di usare la funzione \funcd{pause}, il cui prototipo è:
+segnale è quello di usare la funzione \funcd{pause}, il cui prototipo è:
 \begin{prototype}{unistd.h}{int pause(void)}
   
   Pone il processo in stato di sleep fino al ritorno di un gestore.
   
-  \bodydesc{La funzione ritorna solo dopo che un segnale è stato ricevuto ed
-    il relativo gestore è ritornato, nel qual caso restituisce $-1$ e
-    \var{errno} assumerà il valore \errval{EINTR}.}
+  \bodydesc{La funzione ritorna solo dopo che un segnale è stato ricevuto ed
+    il relativo gestore è ritornato, nel qual caso restituisce $-1$ e
+    \var{errno} assumerà il valore \errval{EINTR}.}
 \end{prototype}
 
 La funzione segnala sempre una condizione di errore (il successo sarebbe
 quello di aspettare indefinitamente). In genere si usa questa funzione quando
 si vuole mettere un processo in attesa di un qualche evento specifico che non
-è sotto il suo diretto controllo (ad esempio la si può usare per interrompere
+è sotto il suo diretto controllo (ad esempio la si può usare per interrompere
 l'esecuzione del processo fino all'arrivo di un segnale inviato da un altro
 processo).
 
 Quando invece si vuole fare attendere un processo per un intervallo di tempo
-già noto nello standard POSIX.1 viene definita la funzione \funcd{sleep}, il
-cui prototipo è:
+già noto nello standard POSIX.1 viene definita la funzione \funcd{sleep}, il
+cui prototipo è:
 \begin{prototype}{unistd.h}{unsigned int sleep(unsigned int seconds)}
   
   Pone il processo in stato di sleep per \param{seconds} secondi.
@@ -1332,26 +1332,26 @@ cui prototipo 
 \end{prototype}
 
 La funzione attende per il tempo specificato, a meno di non essere interrotta
-da un segnale. In questo caso non è una buona idea ripetere la chiamata per il
-tempo rimanente, in quanto la riattivazione del processo può avvenire in un
-qualunque momento, ma il valore restituito sarà sempre arrotondato al secondo,
-con la conseguenza che, se la successione dei segnali è particolarmente
+da un segnale. In questo caso non è una buona idea ripetere la chiamata per il
+tempo rimanente, in quanto la riattivazione del processo può avvenire in un
+qualunque momento, ma il valore restituito sarà sempre arrotondato al secondo,
+con la conseguenza che, se la successione dei segnali è particolarmente
 sfortunata e le differenze si accumulano, si potranno avere ritardi anche di
-parecchi secondi. In genere la scelta più sicura è quella di stabilire un
+parecchi secondi. In genere la scelta più sicura è quella di stabilire un
 termine per l'attesa, e ricalcolare tutte le volte il numero di secondi da
 aspettare.
 
-In alcune implementazioni inoltre l'uso di \func{sleep} può avere conflitti
-con quello di \const{SIGALRM}, dato che la funzione può essere realizzata con
+In alcune implementazioni inoltre l'uso di \func{sleep} può avere conflitti
+con quello di \const{SIGALRM}, dato che la funzione può essere realizzata con
 l'uso di \func{pause} e \func{alarm} (in maniera analoga all'esempio che
 vedremo in sez.~\ref{sec:sig_example}). In tal caso mescolare chiamata di
-\func{alarm} e \func{sleep} o modificare l'azione di \const{SIGALRM}, può
-causare risultati indefiniti. Nel caso delle \acr{glibc} è stata usata una
+\func{alarm} e \func{sleep} o modificare l'azione di \const{SIGALRM}, può
+causare risultati indefiniti. Nel caso delle \acr{glibc} è stata usata una
 implementazione completamente indipendente e questi problemi non ci sono.
 
-La granularità di \func{sleep} permette di specificare attese soltanto in
-secondi, per questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione
-\funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due
+La granularità di \func{sleep} permette di specificare attese soltanto in
+secondi, per questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione
+\funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due
 standard hanno delle definizioni diverse, ma le \acr{glibc}
 seguono\footnote{secondo la pagina di manuale almeno dalla versione 2.2.2.}
 seguono quella di SUSv2 che prevede il seguente prototipo:
@@ -1360,15 +1360,15 @@ seguono quella di SUSv2 che prevede il seguente prototipo:
   Pone il processo in stato di sleep per \param{usec} microsecondi.
   
   \bodydesc{La funzione restituisce zero se l'attesa viene completata, o $-1$
-    in caso di errore, nel qual caso \var{errno} assumerà il valore
+    in caso di errore, nel qual caso \var{errno} assumerà il valore
     \errval{EINTR}.}
 
 \end{prototype}
 
-Anche questa funzione, a seconda delle implementazioni, può presentare
-problemi nell'interazione con \func{alarm} e \const{SIGALRM}. È pertanto
+Anche questa funzione, a seconda delle implementazioni, può presentare
+problemi nell'interazione con \func{alarm} e \const{SIGALRM}. È pertanto
 deprecata in favore della funzione \funcd{nanosleep}, definita dallo standard
-POSIX1.b, il cui prototipo è:
+POSIX1.b, il cui prototipo è:
 \begin{prototype}{unistd.h}{int nanosleep(const struct timespec *req, struct
     timespec *rem)}
   
@@ -1376,19 +1376,19 @@ POSIX1.b, il cui prototipo 
   In caso di interruzione restituisce il tempo restante in \param{rem}.
   
   \bodydesc{La funzione restituisce zero se l'attesa viene completata, o $-1$
-    in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+    in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
-    \item[\errcode{EINVAL}] si è specificato un numero di secondi negativo o un
+    \item[\errcode{EINVAL}] si è specificato un numero di secondi negativo o un
       numero di nanosecondi maggiore di 999.999.999.
-    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+    \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
     \end{errlist}}
 \end{prototype}
 
 Lo standard richiede che la funzione sia implementata in maniera del tutto
-indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
+indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
   utilizzando direttamente il timer del kernel.} e sia utilizzabile senza
 interferenze con l'uso di \const{SIGALRM}. La funzione prende come argomenti
-delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
+delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
 fig.~\ref{fig:sys_timespec_struct}, che permette di specificare un tempo con
 una precisione fino al nanosecondo.
 
@@ -1399,62 +1399,62 @@ inizialmente,\footnote{con l'eccezione, valida solo nei kernel della serie
   2.4, in cui, per i processi riavviati dopo essere stati fermati da un
   segnale, il tempo passato in stato \texttt{T} non viene considerato nel
   calcolo della rimanenza.} e basta richiamare la funzione per completare
-l'attesa.\footnote{anche qui però occorre tenere presente che i tempi sono
+l'attesa.\footnote{anche qui però occorre tenere presente che i tempi sono
   arrotondati, per cui la precisione, per quanto migliore di quella ottenibile
-  con \func{sleep}, è relativa e in caso di molte interruzioni si può avere
+  con \func{sleep}, è relativa e in caso di molte interruzioni si può avere
   una deriva, per questo esiste la funzione \func{clock\_nanosleep} (vedi
   sez.~\ref{sec:sig_timer_adv}) che permette di specificare un tempo assoluto
-  anziché un tempo relativo.}
+  anziché un tempo relativo.}
 
-Chiaramente, anche se il tempo può essere specificato con risoluzioni fino al
-nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
-temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
+Chiaramente, anche se il tempo può essere specificato con risoluzioni fino al
+nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
+temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
 specificato, ma prima che il processo possa tornare ad essere eseguito
-occorrerà almeno attendere la successiva interruzione del timer di sistema,
-cioè un tempo che a seconda dei casi può arrivare fino a 1/\const{HZ}, (sempre
+occorrerà almeno attendere la successiva interruzione del timer di sistema,
+cioè un tempo che a seconda dei casi può arrivare fino a 1/\const{HZ}, (sempre
 che il sistema sia scarico ed il processa venga immediatamente rimesso in
-esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
+esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
 arrotondato al multiplo successivo di 1/\const{HZ}.
 
-Con i kernel della serie 2.4 in realtà era possibile ottenere anche pause più
+Con i kernel della serie 2.4 in realtà era possibile ottenere anche pause più
 precise del centesimo di secondo usando politiche di \itindex{scheduler}
 scheduling \textit{real-time} come \const{SCHED\_FIFO} o \const{SCHED\_RR}; in
 tal caso infatti il calcolo sul numero di interruzioni del timer veniva
 evitato utilizzando direttamente un ciclo di attesa con cui si raggiungevano
-pause fino ai 2~ms con precisioni del $\mu$s. Questa estensione è stata
-rimossa con i kernel della serie 2.6, che consentono una risoluzione più alta
+pause fino ai 2~ms con precisioni del $\mu$s. Questa estensione è stata
+rimossa con i kernel della serie 2.6, che consentono una risoluzione più alta
 del timer di sistema; inoltre a partire dal kernel 2.6.21, \func{nanosleep}
-può avvalersi del supporto dei timer ad alta risoluzione, ottenendo la massima
+può avvalersi del supporto dei timer ad alta risoluzione, ottenendo la massima
 precisione disponibile sull'hardware della propria macchina.
 
 
 \subsection{Un esempio elementare}
 \label{sec:sig_sigchld}
 
-Un semplice esempio per illustrare il funzionamento di un gestore di segnale è
+Un semplice esempio per illustrare il funzionamento di un gestore di segnale è
 quello della gestione di \const{SIGCHLD}. Abbiamo visto in
 sez.~\ref{sec:proc_termination} che una delle azioni eseguite dal kernel alla
-conclusione di un processo è quella di inviare questo segnale al
-padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il
+conclusione di un processo è quella di inviare questo segnale al
+padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il
   segnale si chiama \const{SIGCLD} e viene trattato in maniera speciale; in
   System V infatti se si imposta esplicitamente l'azione a \const{SIG\_IGN} il
   segnale non viene generato ed il sistema non genera \index{zombie} zombie
   (lo stato di terminazione viene scartato senza dover chiamare una
-  \func{wait}).  L'azione predefinita è sempre quella di ignorare il segnale,
+  \func{wait}).  L'azione predefinita è sempre quella di ignorare il segnale,
   ma non attiva questo comportamento. Linux, come BSD e POSIX, non supporta
   questa semantica ed usa il nome di \const{SIGCLD} come sinonimo di
   \const{SIGCHLD}.} In generale dunque, quando non interessa elaborare lo
-stato di uscita di un processo, si può completare la gestione della
+stato di uscita di un processo, si può completare la gestione della
 terminazione installando un gestore per \const{SIGCHLD} il cui unico compito
 sia quello di chiamare \func{waitpid} per completare la procedura di
 terminazione in modo da evitare la formazione di \index{zombie} zombie.
 
-In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una
+In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una
 implementazione generica di una funzione di gestione per \const{SIGCHLD}, (che
 si trova nei sorgenti allegati nel file \file{SigHand.c}); se ripetiamo i test
 di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
 \cmd{-s} (che si limita ad effettuare l'installazione di questa funzione come
-gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione
+gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione
 di \index{zombie} zombie.
 
 \begin{figure}[!htb]
@@ -1468,7 +1468,7 @@ di \index{zombie} zombie.
   \label{fig:sig_sigchld_handl}
 \end{figure}
 
-Il codice del gestore è di lettura immediata; come buona norma di
+Il codice del gestore è di lettura immediata; come buona norma di
 programmazione (si ricordi quanto accennato sez.~\ref{sec:sys_errno}) si
 comincia (\texttt{\small 6--7}) con il salvare lo stato corrente di
 \var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore
@@ -1476,25 +1476,25 @@ comincia (\texttt{\small 6--7}) con il salvare lo stato corrente di
 visto dal corso di esecuzione principale del processo, che altrimenti sarebbe
 sovrascritto dal valore restituito nella successiva chiamata di \func{waitpid}.
 
-Il compito principale del gestore è quello di ricevere lo stato di
+Il compito principale del gestore è quello di ricevere lo stato di
 terminazione del processo, cosa che viene eseguita nel ciclo in
-(\texttt{\small 9--15}).  Il ciclo è necessario a causa di una caratteristica
-fondamentale della gestione dei segnali: abbiamo già accennato come fra la
+(\texttt{\small 9--15}).  Il ciclo è necessario a causa di una caratteristica
+fondamentale della gestione dei segnali: abbiamo già accennato come fra la
 generazione di un segnale e l'esecuzione del gestore possa passare un certo
 lasso di tempo e niente ci assicura che il gestore venga eseguito prima della
 generazione di ulteriori segnali dello stesso tipo. In questo caso normalmente
 i segnali successivi vengono ``\textsl{fusi}'' col primo ed al processo ne
 viene recapitato soltanto uno.
 
-Questo può essere un caso comune proprio con \const{SIGCHLD}, qualora capiti
+Questo può essere un caso comune proprio con \const{SIGCHLD}, qualora capiti
 che molti processi figli terminino in rapida successione. Esso inoltre si
 presenta tutte le volte che un segnale viene bloccato: per quanti siano i
-segnali emessi durante il periodo di blocco, una volta che quest'ultimo sarà
-rimosso verrà recapitato un solo segnale.
+segnali emessi durante il periodo di blocco, una volta che quest'ultimo sarà
+rimosso verrà recapitato un solo segnale.
 
 Allora, nel caso della terminazione dei processi figli, se si chiamasse
 \func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un
-solo processo, anche se i processi terminati sono più di uno, e gli altri
+solo processo, anche se i processi terminati sono più di uno, e gli altri
 resterebbero in stato di \index{zombie} zombie per un tempo indefinito.
 
 Per questo occorre ripetere la chiamata di \func{waitpid} fino a che essa non
@@ -1509,15 +1509,15 @@ tutti gli stati di terminazione sono stati ricevuti.
 \section{La gestione avanzata dei segnali}
 \label{sec:sig_adv_control}
 
-Le funzioni esaminate finora fanno riferimento alle modalità più elementari
+Le funzioni esaminate finora fanno riferimento alle modalità più elementari
 della gestione dei segnali; non si sono pertanto ancora prese in
-considerazione le tematiche più complesse, collegate alle varie
+considerazione le tematiche più complesse, collegate alle varie
 \itindex{race~condition} \textit{race condition} che i segnali possono
 generare e alla natura asincrona degli stessi.
 
 Affronteremo queste problematiche in questa sezione, partendo da un esempio
 che le evidenzi, per poi prendere in esame le varie funzioni che permettono di
-risolvere i problemi più complessi connessi alla programmazione con i segnali,
+risolvere i problemi più complessi connessi alla programmazione con i segnali,
 fino a trattare le caratteristiche generali della gestione dei medesimi nella
 casistica ordinaria.
 
@@ -1525,9 +1525,9 @@ casistica ordinaria.
 \subsection{Alcune problematiche aperte}
 \label{sec:sig_example}
 
-Come accennato in sez.~\ref{sec:sig_pause_sleep} è possibile implementare
+Come accennato in sez.~\ref{sec:sig_pause_sleep} è possibile implementare
 \func{sleep} a partire dall'uso di \func{pause} e \func{alarm}. A prima vista
-questo può sembrare di implementazione immediata; ad esempio una semplice
+questo può sembrare di implementazione immediata; ad esempio una semplice
 versione di \func{sleep} potrebbe essere quella illustrata in
 fig.~\ref{fig:sig_sleep_wrong}.
 
@@ -1541,31 +1541,31 @@ fig.~\ref{fig:sig_sleep_wrong}.
   \label{fig:sig_sleep_wrong}
 \end{figure}
 
-Dato che è nostra intenzione utilizzare \const{SIGALRM} il primo passo della
-nostra implementazione sarà quello di installare il relativo gestore salvando
-il precedente (\texttt{\small 14-17}).  Si effettuerà poi una chiamata ad
+Dato che è nostra intenzione utilizzare \const{SIGALRM} il primo passo della
+nostra implementazione sarà quello di installare il relativo gestore salvando
+il precedente (\texttt{\small 14-17}).  Si effettuerà poi una chiamata ad
 \func{alarm} per specificare il tempo d'attesa per l'invio del segnale a cui
 segue la chiamata a \func{pause} per fermare il programma (\texttt{\small
   18-20}) fino alla sua ricezione.  Al ritorno di \func{pause}, causato dal
 ritorno del gestore (\texttt{\small 1-9}), si ripristina il gestore originario
 (\texttt{\small 21-22}) restituendo l'eventuale tempo rimanente
-(\texttt{\small 23-24}) che potrà essere diverso da zero qualora
+(\texttt{\small 23-24}) che potrà essere diverso da zero qualora
 l'interruzione di \func{pause} venisse causata da un altro segnale.
 
-Questo codice però, a parte il non gestire il caso in cui si è avuta una
-precedente chiamata a \func{alarm} (che si è tralasciato per brevità),
+Questo codice però, a parte il non gestire il caso in cui si è avuta una
+precedente chiamata a \func{alarm} (che si è tralasciato per brevità),
 presenta una pericolosa \itindex{race~condition} \textit{race condition}.
 Infatti, se il processo viene interrotto fra la chiamata di \func{alarm} e
-\func{pause}, può capitare (ad esempio se il sistema è molto carico) che il
-tempo di attesa scada prima dell'esecuzione di quest'ultima, cosicché essa
+\func{pause}, può capitare (ad esempio se il sistema è molto carico) che il
+tempo di attesa scada prima dell'esecuzione di quest'ultima, cosicché essa
 sarebbe eseguita dopo l'arrivo di \const{SIGALRM}. In questo caso ci si
 troverebbe di fronte ad un \itindex{deadlock} deadlock, in quanto \func{pause}
-non verrebbe mai più interrotta (se non in caso di un altro segnale).
+non verrebbe mai più interrotta (se non in caso di un altro segnale).
 
-Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
+Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
 SVr2) usando la funzione \func{longjmp} (vedi sez.~\ref{sec:proc_longjmp}) per
 uscire dal gestore; in questo modo, con una condizione sullo stato di
-uscita di quest'ultima, si può evitare la chiamata a \func{pause}, usando un
+uscita di quest'ultima, si può evitare la chiamata a \func{pause}, usando un
 codice del tipo di quello riportato in fig.~\ref{fig:sig_sleep_incomplete}.
 
 \begin{figure}[!htb]
@@ -1581,25 +1581,25 @@ codice del tipo di quello riportato in fig.~\ref{fig:sig_sleep_incomplete}.
 In questo caso il gestore (\texttt{\small 18-27}) non ritorna come in
 fig.~\ref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 25}) per
 rientrare nel corpo principale del programma; dato che in questo caso il
-valore di uscita di \func{setjmp} è 1, grazie alla condizione in
+valore di uscita di \func{setjmp} è 1, grazie alla condizione in
 (\texttt{\small 9-12}) si evita comunque che \func{pause} sia chiamata a
 vuoto.
 
 Ma anche questa implementazione comporta dei problemi; in questo caso infatti
 non viene gestita correttamente l'interazione con gli altri segnali; se
 infatti il segnale di allarme interrompe un altro gestore, l'esecuzione non
-riprenderà nel gestore in questione, ma nel ciclo principale, interrompendone
+riprenderà nel gestore in questione, ma nel ciclo principale, interrompendone
 inopportunamente l'esecuzione.  Lo stesso tipo di problemi si presenterebbero
 se si volesse usare \func{alarm} per stabilire un timeout su una qualunque
 system call bloccante.
 
-Un secondo esempio è quello in cui si usa il segnale per notificare una
-qualche forma di evento; in genere quello che si fa in questo caso è impostare
+Un secondo esempio è quello in cui si usa il segnale per notificare una
+qualche forma di evento; in genere quello che si fa in questo caso è impostare
 nel gestore un opportuno flag da controllare nel corpo principale del
 programma (con un codice del tipo di quello riportato in
-fig.~\ref{fig:sig_event_wrong}). La logica è quella di far impostare al
+fig.~\ref{fig:sig_event_wrong}). La logica è quella di far impostare al
 gestore (\texttt{\small 14-19}) una variabile globale preventivamente
-inizializzata nel programma principale, il quale potrà determinare,
+inizializzata nel programma principale, il quale potrà determinare,
 osservandone il contenuto, l'occorrenza o meno del segnale, e prendere le
 relative azioni conseguenti (\texttt{\small 6-11}).
 
@@ -1614,17 +1614,17 @@ relative azioni conseguenti (\texttt{\small 6-11}).
   \label{fig:sig_event_wrong}
 \end{figure}
 
-Questo è il tipico esempio di caso, già citato in
+Questo è il tipico esempio di caso, già citato in
 sez.~\ref{sec:proc_race_cond}, in cui si genera una \itindex{race~condition}
-\textit{race condition}; infatti, in una situazione in cui un segnale è già
-arrivato (e \var{flag} è già ad 1) se un altro segnale arriva immediatamente
+\textit{race condition}; infatti, in una situazione in cui un segnale è già
+arrivato (e \var{flag} è già ad 1) se un altro segnale arriva immediatamente
 dopo l'esecuzione del controllo (\texttt{\small 6}) ma prima della
-cancellazione del flag (\texttt{\small 7}), la sua occorrenza sarà perduta.
+cancellazione del flag (\texttt{\small 7}), la sua occorrenza sarà perduta.
 
 Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono
-delle funzioni più sofisticate di quelle finora illustrate, queste hanno la
+delle funzioni più sofisticate di quelle finora illustrate, queste hanno la
 loro origine nella semplice interfaccia dei primi sistemi Unix, ma con esse
-non è possibile gestire in maniera adeguata di tutti i possibili aspetti con
+non è possibile gestire in maniera adeguata di tutti i possibili aspetti con
 cui un processo deve reagire alla ricezione di un segnale.
 
 
@@ -1636,22 +1636,22 @@ cui un processo deve reagire alla ricezione di un segnale.
 
 Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
 originarie, nate con la semantica inaffidabile, hanno dei limiti non
-superabili; in particolare non è prevista nessuna funzione che permetta di
+superabili; in particolare non è prevista nessuna funzione che permetta di
 gestire il blocco dei segnali o di verificare lo stato dei segnali pendenti.
 Per questo motivo lo standard POSIX.1, insieme alla nuova semantica dei
 segnali ha introdotto una interfaccia di gestione completamente nuova, che
-permette di ottenere un controllo molto più dettagliato. In particolare lo
+permette di ottenere un controllo molto più dettagliato. In particolare lo
 standard ha introdotto un nuovo tipo di dato \type{sigset\_t}, che permette di
 rappresentare un \textsl{insieme di segnali} (un \textit{signal set}, come
 viene usualmente chiamato), tale tipo di dato viene usato per gestire il
 blocco dei segnali.
 
-In genere un \textsl{insieme di segnali} è rappresentato da un intero di
+In genere un \textsl{insieme di segnali} è rappresentato da un intero di
 dimensione opportuna, di solito pari al numero di bit dell'architettura della
 macchina,\footnote{nel caso dei PC questo comporta un massimo di 32 segnali
-  distinti: dato che in Linux questi sono sufficienti non c'è necessità di
-  nessuna struttura più complicata.} ciascun bit del quale è associato ad uno
-specifico segnale; in questo modo è di solito possibile implementare le
+  distinti: dato che in Linux questi sono sufficienti non c'è necessità di
+  nessuna struttura più complicata.} ciascun bit del quale è associato ad uno
+specifico segnale; in questo modo è di solito possibile implementare le
 operazioni direttamente con istruzioni elementari del processore. Lo standard
 POSIX.1 definisce cinque funzioni per la manipolazione degli insiemi di
 segnali: \funcd{sigemptyset}, \funcd{sigfillset}, \funcd{sigaddset},
@@ -1660,7 +1660,7 @@ segnali: \funcd{sigemptyset}, \funcd{sigfillset}, \funcd{sigaddset},
   \headdecl{signal.h} 
   
   \funcdecl{int sigemptyset(sigset\_t *set)} Inizializza un insieme di segnali
-  vuoto (in cui non c'è nessun segnale).
+  vuoto (in cui non c'è nessun segnale).
  
   \funcdecl{int sigfillset(sigset\_t *set)} Inizializza un insieme di segnali
   pieno (in cui ci sono tutti i segnali).
@@ -1672,17 +1672,17 @@ segnali: \funcd{sigemptyset}, \funcd{sigfillset}, \funcd{sigaddset},
   \param{signum} dall'insieme di segnali \param{set}.
   
   \funcdecl{int sigismember(const sigset\_t *set, int signum)} Controlla se il
-  segnale \param{signum} è nell'insieme di segnali \param{set}.
+  segnale \param{signum} è nell'insieme di segnali \param{set}.
   
   \bodydesc{Le prime quattro funzioni ritornano 0 in caso di successo, mentre
-    \func{sigismember} ritorna 1 se \param{signum} è in \param{set} e 0
+    \func{sigismember} ritorna 1 se \param{signum} è in \param{set} e 0
     altrimenti. In caso di errore tutte ritornano $-1$, con \var{errno}
-    impostata a \errval{EINVAL} (il solo errore possibile è che \param{signum}
+    impostata a \errval{EINVAL} (il solo errore possibile è che \param{signum}
     non sia un segnale valido).}
 \end{functions}
 
-Dato che in generale non si può fare conto sulle caratteristiche di una
-implementazione (non è detto che si disponga di un numero di bit sufficienti
+Dato che in generale non si può fare conto sulle caratteristiche di una
+implementazione (non è detto che si disponga di un numero di bit sufficienti
 per mettere tutti i segnali in un intero, o in \type{sigset\_t} possono essere
 immagazzinate ulteriori informazioni) tutte le operazioni devono essere
 comunque eseguite attraverso queste funzioni.
@@ -1702,24 +1702,24 @@ insieme.
 \subsection{La funzione \func{sigaction}}
 \label{sec:sig_sigaction}
 
-Abbiamo già accennato in sez.~\ref{sec:sig_signal} i problemi di compatibilità
+Abbiamo già accennato in sez.~\ref{sec:sig_signal} i problemi di compatibilità
 relativi all'uso di \func{signal}. Per ovviare a tutto questo lo standard
 POSIX.1 ha ridefinito completamente l'interfaccia per la gestione dei segnali,
-rendendola molto più flessibile e robusta, anche se leggermente più complessa.
+rendendola molto più flessibile e robusta, anche se leggermente più complessa.
 
-La funzione principale dell'interfaccia POSIX.1 per i segnali è
+La funzione principale dell'interfaccia POSIX.1 per i segnali è
 \funcd{sigaction}. Essa ha sostanzialmente lo stesso uso di \func{signal},
-permette cioè di specificare le modalità con cui un segnale può essere gestito
-da un processo. Il suo prototipo è:
+permette cioè di specificare le modalità con cui un segnale può essere gestito
+da un processo. Il suo prototipo è:
 \begin{prototype}{signal.h}{int sigaction(int signum, const struct sigaction
     *act, struct sigaction *oldact)} 
   
   Installa una nuova azione per il segnale \param{signum}.
   
   \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido o si è
+  \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido o si è
     cercato di installare il gestore per \const{SIGKILL} o
     \const{SIGSTOP}.
   \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
@@ -1730,24 +1730,24 @@ La funzione serve ad installare una nuova \textsl{azione} per il segnale
 \param{signum}; si parla di \textsl{azione} e non di \textsl{gestore}
 come nel caso di \func{signal}, in quanto la funzione consente di specificare
 le varie caratteristiche della risposta al segnale, non solo la funzione che
-verrà eseguita alla sua occorrenza.  Per questo lo standard raccomanda di
+verrà eseguita alla sua occorrenza.  Per questo lo standard raccomanda di
 usare sempre questa funzione al posto di \func{signal} (che in genere viene
 definita tramite essa), in quanto permette un controllo completo su tutti gli
 aspetti della gestione di un segnale, sia pure al prezzo di una maggiore
-complessità d'uso.
+complessità d'uso.
 
-Se il puntatore \param{act} non è nullo, la funzione installa la nuova azione
-da esso specificata, se \param{oldact} non è nullo il valore dell'azione
+Se il puntatore \param{act} non è nullo, la funzione installa la nuova azione
+da esso specificata, se \param{oldact} non è nullo il valore dell'azione
 corrente viene restituito indietro.  Questo permette (specificando \param{act}
 nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
 che non consente di ottenere l'azione corrente senza installarne una nuova.
 
 Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
 tramite la quale si specificano tutte le caratteristiche dell'azione associata
-ad un segnale.  Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
+ad un segnale.  Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
 definita secondo quanto riportato in fig.~\ref{fig:sig_sigaction}. Il campo
-\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
-più usato.
+\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
+più usato.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -1786,14 +1786,14 @@ tab.~\ref{tab:sig_sa_flag}.
     \textbf{Valore} & \textbf{Significato} \\
     \hline
     \hline
-    \const{SA\_NOCLDSTOP}& Se il segnale è \const{SIGCHLD} allora non deve
+    \const{SA\_NOCLDSTOP}& Se il segnale è \const{SIGCHLD} allora non deve
                            essere notificato quando il processo figlio viene
                            fermato da uno dei segnali \const{SIGSTOP},
                            \const{SIGTSTP}, \const{SIGTTIN} o 
                            \const{SIGTTOU}.\\
     \const{SA\_RESETHAND}& Ristabilisce l'azione per il segnale al valore 
-                           predefinito una volta che il gestore è stato
-                           lanciato, riproduce cioè il comportamento della
+                           predefinito una volta che il gestore è stato
+                           lanciato, riproduce cioè il comportamento della
                            semantica inaffidabile.\\  
     \const{SA\_ONESHOT}  & Nome obsoleto, sinonimo non standard di
                            \const{SA\_RESETHAND}; da evitare.\\ 
@@ -1803,7 +1803,7 @@ tab.~\ref{tab:sig_sa_flag}.
                            sez.~\ref{sec:sig_specific_features}).\\  
     \const{SA\_RESTART}  & Riavvia automaticamente le \textit{slow system
                            call} quando vengono interrotte dal suddetto
-                           segnale; riproduce cioè il comportamento standard
+                           segnale; riproduce cioè il comportamento standard
                            di BSD.\index{system~call~lente}\\ 
     \const{SA\_NODEFER}  & Evita che il segnale corrente sia bloccato durante
                            l'esecuzione del gestore.\\
@@ -1813,7 +1813,7 @@ tab.~\ref{tab:sig_sa_flag}.
                            gestore in forma estesa usando
                            \var{sa\_sigaction} al posto di
                            \var{sa\_handler}.\\
-    \const{SA\_NOCLDWAIT}& Se il segnale è \const{SIGCHLD} allora i processi
+    \const{SA\_NOCLDWAIT}& Se il segnale è \const{SIGCHLD} allora i processi
                            figli non diventano \textit{zombie} quando
                            terminano.\footnotemark \\ 
     \hline
@@ -1822,23 +1822,23 @@ tab.~\ref{tab:sig_sa_flag}.
   \label{tab:sig_sa_flag}
 \end{table}
 
-\footnotetext{questa funzionalità è stata introdotta nel kernel 2.6 e va a
+\footnotetext{questa funzionalità è stata introdotta nel kernel 2.6 e va a
   modificare il comportamento di \func{waitpid}.}
 
-Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette
-di utilizzare due forme diverse di gestore,\footnote{la possibilità è prevista
-  dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x
+Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette
+di utilizzare due forme diverse di gestore,\footnote{la possibilità è prevista
+  dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x
   con l'introduzione dei segnali \textit{real-time} (vedi
   sez.~\ref{sec:sig_real_time}); in precedenza era possibile ottenere alcune
   informazioni addizionali usando \var{sa\_handler} con un secondo parametro
-  addizionale di tipo \var{sigcontext}, che adesso è deprecato.}  da
+  addizionale di tipo \var{sigcontext}, che adesso è deprecato.}  da
 specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO},
 rispettivamente attraverso i campi \var{sa\_sigaction} o
 \var{sa\_handler},\footnote{i due campi devono essere usati in maniera
   alternativa, in certe implementazioni questi campi vengono addirittura
-  definiti come \ctyp{union}.}  Quest'ultima è quella classica usata anche con
-\func{signal}, mentre la prima permette di usare un gestore più complesso, in
-grado di ricevere informazioni più dettagliate dal sistema, attraverso la
+  definiti come \ctyp{union}.}  Quest'ultima è quella classica usata anche con
+\func{signal}, mentre la prima permette di usare un gestore più complesso, in
+grado di ricevere informazioni più dettagliate dal sistema, attraverso la
 struttura \struct{siginfo\_t}, riportata in fig.~\ref{fig:sig_siginfo_t}.
 
 Installando un gestore di tipo \var{sa\_sigaction} diventa allora possibile
@@ -1867,7 +1867,7 @@ viene sempre espresso come una costante,\footnote{le definizioni di tutti i
   valori possibili si trovano in \file{bits/siginfo.h}.} ed i valori possibili
 in questo caso sono riportati in tab.~\ref{tab:sig_si_code_generic}.
 
-Nel caso di alcuni segnali però il valore di \var{si\_code} viene usato per
+Nel caso di alcuni segnali però il valore di \var{si\_code} viene usato per
 fornire una informazione specifica relativa alle motivazioni della ricezione
 dello stesso; ad esempio i vari segnali di errore (\const{SIGILL},
 \const{SIGFPE}, \const{SIGSEGV} e \const{SIGBUS}) lo usano per fornire
@@ -1894,7 +1894,7 @@ altre informazioni specifiche.
                          messaggi POSIX (vedi
                          sez.~\ref{sec:ipc_posix_mq}).\footnotemark\\ 
     \const{SI\_ASYNCIO}& una operazione di I/O asincrono (vedi
-                         sez.~\ref{sec:file_asyncronous_access}) è stata
+                         sez.~\ref{sec:file_asyncronous_access}) è stata
                          completata.\\
     \const{SI\_SIGIO}  & segnale di \const{SIGIO} da una coda (vedi
                          sez.~\ref{sec:file_asyncronous_operation}).\\ 
@@ -1913,9 +1913,9 @@ altre informazioni specifiche.
 In questo caso il valore del campo \var{si\_code} deve essere verificato nei
 confronti delle diverse costanti previste per ciascuno di detti
 segnali;\footnote{dato che si tratta di una costante, e non di una maschera
-  binaria, i valori numerici vengono riutilizzati e ciascuno di essi avrà un
-  significato diverso a seconda del segnale a cui è associato.} l'elenco
-dettagliato dei nomi di queste costanti è riportato nelle diverse sezioni di
+  binaria, i valori numerici vengono riutilizzati e ciascuno di essi avrà un
+  significato diverso a seconda del segnale a cui è associato.} l'elenco
+dettagliato dei nomi di queste costanti è riportato nelle diverse sezioni di
 tab.~\ref{tab:sig_si_code_special} che sono state ordinate nella sequenza in
 cui si sono appena citati i rispettivi segnali.\footnote{il prefisso del nome
   indica comunque in maniera diretta il segnale a cui le costanti fanno
@@ -1957,19 +1957,19 @@ cui si sono appena citati i rispettivi segnali.\footnote{il prefisso del nome
     \const{TRAP\_BRKPT}  & breakpoint sul processo.\\
     \const{TRAP\_TRACE}  & trappola di tracciamento del processo.\\
     \hline
-    \const{CLD\_EXITED}  & il figlio è uscito.\\
-    \const{CLD\_KILLED}  & il figlio è stato terminato.\\
-    \const{CLD\_DUMPED}  & il figlio è terminato in modo anormale.\\
+    \const{CLD\_EXITED}  & il figlio è uscito.\\
+    \const{CLD\_KILLED}  & il figlio è stato terminato.\\
+    \const{CLD\_DUMPED}  & il figlio è terminato in modo anormale.\\
     \const{CLD\_TRAPPED} & un figlio tracciato ha raggiunto una trappola.\\
-    \const{CLD\_STOPPED} & il figlio è stato fermato.\\
-    \const{CLD\_CONTINUED}& il figlio è ripartito.\\
+    \const{CLD\_STOPPED} & il figlio è stato fermato.\\
+    \const{CLD\_CONTINUED}& il figlio è ripartito.\\
     \hline
     \const{POLL\_IN}   & disponibili dati in ingresso.\\
     \const{POLL\_OUT}  & spazio disponibile sul buffer di uscita.\\
     \const{POLL\_MSG}  & disponibili messaggi in ingresso.\\
     \const{POLL\_ERR}  & errore di I/O.\\
-    \const{POLL\_PRI}  & disponibili dati di alta priorità in ingresso.\\
-    \const{POLL\_HUP}  & il dispositivo è stato disconnesso.\\
+    \const{POLL\_PRI}  & disponibili dati di alta priorità in ingresso.\\
+    \const{POLL\_HUP}  & il dispositivo è stato disconnesso.\\
     \hline
   \end{tabular}
   \caption{Valori del campo \var{si\_code} della struttura \struct{sigaction}
@@ -1979,8 +1979,8 @@ cui si sono appena citati i rispettivi segnali.\footnote{il prefisso del nome
   \label{tab:sig_si_code_special}
 \end{table}
 
-Il resto della struttura \struct{siginfo\_t} è definito come \ctyp{union} ed i
-valori eventualmente presenti dipendono dal segnale, così \const{SIGCHLD} ed i
+Il resto della struttura \struct{siginfo\_t} è definito come \ctyp{union} ed i
+valori eventualmente presenti dipendono dal segnale, così \const{SIGCHLD} ed i
 segnali \textit{real-time} (vedi sez.~\ref{sec:sig_real_time}) inviati tramite
 \func{kill} avvalorano \var{si\_pid} e \var{si\_uid} coi valori corrispondenti
 al processo che ha emesso il segnale, \const{SIGCHLD} avvalora anche i campi
@@ -1988,28 +1988,28 @@ al processo che ha emesso il segnale, \const{SIGCHLD} avvalora anche i campi
 rispettivamente lo stato di uscita, l'\textit{user time} e il \textit{system
   time} (vedi sez.~\ref{sec:sys_cpu_times}) usati dal processo;
 \const{SIGILL}, \const{SIGFPE}, \const{SIGSEGV} e \const{SIGBUS} avvalorano
-\var{si\_addr} con l'indirizzo in cui è avvenuto l'errore, \const{SIGIO} (vedi
+\var{si\_addr} con l'indirizzo in cui è avvenuto l'errore, \const{SIGIO} (vedi
 sez.~\ref{sec:file_asyncronous_io}) avvalora \var{si\_fd} con il numero del
 file descriptor e \var{si\_band} per i \itindex{out-of-band} dati urgenti
 (vedi sez.~\ref{sec:TCP_urgent_data}) su un socket, il segnale inviato alla
 scadenza di un timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}) avvalora i
 campi \var{si\_timerid} e \var{si\_overrun}.
 
-Benché sia possibile usare nello stesso programma sia \func{sigaction} che
+Benché sia possibile usare nello stesso programma sia \func{sigaction} che
 \func{signal} occorre molta attenzione, in quanto le due funzioni possono
 interagire in maniera anomala. Infatti l'azione specificata con
 \struct{sigaction} contiene un maggior numero di informazioni rispetto al
 semplice indirizzo del gestore restituito da \func{signal}.  Per questo motivo
 se si usa quest'ultima per installare un gestore sostituendone uno
-precedentemente installato con \func{sigaction}, non sarà possibile effettuare
+precedentemente installato con \func{sigaction}, non sarà possibile effettuare
 un ripristino corretto dello stesso.
 
-Per questo è sempre opportuno usare \func{sigaction}, che è in grado di
-ripristinare correttamente un gestore precedente, anche se questo è stato
-installato con \func{signal}. In generale poi non è il caso di usare il valore
+Per questo è sempre opportuno usare \func{sigaction}, che è in grado di
+ripristinare correttamente un gestore precedente, anche se questo è stato
+installato con \func{signal}. In generale poi non è il caso di usare il valore
 di ritorno di \func{signal} come campo \var{sa\_handler}, o viceversa, dato
 che in certi sistemi questi possono essere diversi. In definitiva dunque, a
-meno che non si sia vincolati all'aderenza stretta allo standard ISO C, è
+meno che non si sia vincolati all'aderenza stretta allo standard ISO C, è
 sempre il caso di evitare l'uso di \func{signal} a favore di \func{sigaction}.
 
 \begin{figure}[!htb]
@@ -2023,17 +2023,17 @@ sempre il caso di evitare l'uso di \func{signal} a favore di \func{sigaction}.
   \label{fig:sig_Signal_code}
 \end{figure}
 
-Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
+Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
 che abbia le stesse caratteristiche di \func{signal}, a definire attraverso
-\func{sigaction} una funzione equivalente \func{Signal}, il cui codice è
+\func{sigaction} una funzione equivalente \func{Signal}, il cui codice è
 riportato in fig.~\ref{fig:sig_Signal_code} (il codice completo si trova nel
 file \file{SigHand.c} nei sorgenti allegati).  Si noti come, essendo la
-funzione estremamente semplice, essa è definita come
+funzione estremamente semplice, essa è definita come
 \direct{inline};\footnote{la direttiva \direct{inline} viene usata per dire al
   compilatore di trattare la funzione cui essa fa riferimento in maniera
   speciale inserendo il codice direttamente nel testo del programma.  Anche se
-  i compilatori più moderni sono in grado di effettuare da soli queste
-  manipolazioni (impostando le opportune ottimizzazioni) questa è una tecnica
+  i compilatori più moderni sono in grado di effettuare da soli queste
+  manipolazioni (impostando le opportune ottimizzazioni) questa è una tecnica
   usata per migliorare le prestazioni per le funzioni piccole ed usate di
   frequente (in particolare nel kernel, dove in certi casi le ottimizzazioni
   dal compilatore, tarate per l'uso in user space, non sono sempre adatte). In
@@ -2043,7 +2043,7 @@ funzione estremamente semplice, essa 
   Originariamente questo comportamento veniva ottenuto con delle macro, ma
   queste hanno tutta una serie di problemi di sintassi nel passaggio degli
   argomenti (si veda ad esempio \cite{PratC}) che in questo modo possono
-  essere evitati.} per semplificare ulteriormente la definizione si è poi
+  essere evitati.} per semplificare ulteriormente la definizione si è poi
 definito un apposito tipo \texttt{SigFunc}.
 
 
@@ -2056,42 +2056,42 @@ definito un apposito tipo \texttt{SigFunc}.
 Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
 permettono di bloccare temporaneamente (o di eliminare completamente,
 impostando \const{SIG\_IGN} come azione) la consegna dei segnali ad un
-processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei
+processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei
   segnali} (o \textit{signal mask}) del processo\footnote{nel caso di Linux
-  essa è mantenuta dal campo \var{blocked} della \struct{task\_struct} del
-  processo.} cioè l'insieme dei segnali la cui consegna è bloccata. Abbiamo
+  essa è mantenuta dal campo \var{blocked} della \struct{task\_struct} del
+  processo.} cioè l'insieme dei segnali la cui consegna è bloccata. Abbiamo
 accennato in sez.~\ref{sec:proc_fork} che la \textit{signal mask} viene
 ereditata dal padre alla creazione di un processo figlio, e abbiamo visto al
-paragrafo precedente che essa può essere modificata, durante l'esecuzione di
+paragrafo precedente che essa può essere modificata, durante l'esecuzione di
 un gestore, attraverso l'uso dal campo \var{sa\_mask} di \struct{sigaction}.
 
 Uno dei problemi evidenziatisi con l'esempio di fig.~\ref{fig:sig_event_wrong}
-è che in molti casi è necessario proteggere delle sezioni di codice (nel caso
+è che in molti casi è necessario proteggere delle sezioni di codice (nel caso
 in questione la sezione fra il controllo e la eventuale cancellazione del flag
 che testimoniava l'avvenuta occorrenza del segnale) in modo da essere sicuri
 che essi siano eseguite senza interruzioni.
 
-Le operazioni più semplici, come l'assegnazione o il controllo di una
-variabile (per essere sicuri si può usare il tipo \type{sig\_atomic\_t}) di
-norma sono atomiche; quando si devono eseguire operazioni più complesse si può
+Le operazioni più semplici, come l'assegnazione o il controllo di una
+variabile (per essere sicuri si può usare il tipo \type{sig\_atomic\_t}) di
+norma sono atomiche; quando si devono eseguire operazioni più complesse si può
 invece usare la funzione \funcd{sigprocmask} che permette di bloccare uno o
-più segnali; il suo prototipo è:
+più segnali; il suo prototipo è:
 \begin{prototype}{signal.h}
 {int sigprocmask(int how, const sigset\_t *set, sigset\_t *oldset)} 
   
   Cambia la \textsl{maschera dei segnali} del processo corrente.
   
   \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
+  \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
   \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
   \end{errlist}}
 \end{prototype}
 
 La funzione usa l'insieme di segnali dato all'indirizzo \param{set} per
 modificare la maschera dei segnali del processo corrente. La modifica viene
-effettuata a seconda del valore dell'argomento \param{how}, secondo le modalità
+effettuata a seconda del valore dell'argomento \param{how}, secondo le modalità
 specificate in tab.~\ref{tab:sig_procmask_how}. Qualora si specifichi un valore
 non nullo per \param{oldset} la maschera dei segnali corrente viene salvata a
 quell'indirizzo.
@@ -2104,12 +2104,12 @@ quell'indirizzo.
     \textbf{Valore} & \textbf{Significato} \\
     \hline
     \hline
-    \const{SIG\_BLOCK}   & L'insieme dei segnali bloccati è l'unione fra
+    \const{SIG\_BLOCK}   & L'insieme dei segnali bloccati è l'unione fra
                            quello specificato e quello corrente.\\
     \const{SIG\_UNBLOCK} & I segnali specificati in \param{set} sono rimossi
                            dalla maschera dei segnali, specificare la
-                           cancellazione di un segnale non bloccato è legale.\\
-    \const{SIG\_SETMASK} & La maschera dei segnali è impostata al valore
+                           cancellazione di un segnale non bloccato è legale.\\
+    \const{SIG\_SETMASK} & La maschera dei segnali è impostata al valore
                            specificato da \param{set}.\\
     \hline
   \end{tabular}
@@ -2124,30 +2124,30 @@ l'insieme di segnali voluto per poi riabilitarli alla fine della
 problemi come quelli mostrati in fig.~\ref{fig:sig_event_wrong}, proteggendo
 la sezione fra il controllo del flag e la sua cancellazione.
 
-La funzione può essere usata anche all'interno di un gestore, ad esempio
-per riabilitare la consegna del segnale che l'ha invocato, in questo caso però
+La funzione può essere usata anche all'interno di un gestore, ad esempio
+per riabilitare la consegna del segnale che l'ha invocato, in questo caso però
 occorre ricordare che qualunque modifica alla maschera dei segnali viene
 perduta alla conclusione del terminatore. 
 
-Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
+Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
 dei casi di \itindex{race~condition} \textit{race condition} restano aperte
-alcune possibilità legate all'uso di \func{pause}; il caso è simile a quello
+alcune possibilità legate all'uso di \func{pause}; il caso è simile a quello
 del problema illustrato nell'esempio di fig.~\ref{fig:sig_sleep_incomplete}, e
-cioè la possibilità che il processo riceva il segnale che si intende usare per
+cioè la possibilità che il processo riceva il segnale che si intende usare per
 uscire dallo stato di attesa invocato con \func{pause} immediatamente prima
 dell'esecuzione di quest'ultima. Per poter effettuare atomicamente la modifica
 della maschera dei segnali (di solito attivandone uno specifico) insieme alla
 sospensione del processo lo standard POSIX ha previsto la funzione
-\funcd{sigsuspend}, il cui prototipo è:
+\funcd{sigsuspend}, il cui prototipo è:
 \begin{prototype}{signal.h}
 {int sigsuspend(const sigset\_t *mask)} 
   
   Imposta la \textit{signal mask} specificata, mettendo in attesa il processo.
   
   \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
+  \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
   \item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
   \end{errlist}}
 \end{prototype}
@@ -2157,10 +2157,10 @@ l'esempio di implementazione di \code{sleep}. Abbiamo accennato in
 sez.~\ref{sec:sig_sigaction} come con \func{sigaction} sia possibile bloccare
 \const{SIGALRM} nell'installazione dei gestori degli altri segnali, per poter
 usare l'implementazione vista in fig.~\ref{fig:sig_sleep_incomplete} senza
-interferenze.  Questo però comporta una precauzione ulteriore al semplice uso
-della funzione, vediamo allora come usando la nuova interfaccia è possibile
+interferenze.  Questo però comporta una precauzione ulteriore al semplice uso
+della funzione, vediamo allora come usando la nuova interfaccia è possibile
 ottenere un'implementazione, riportata in fig.~\ref{fig:sig_sleep_ok} che non
-presenta neanche questa necessità.
+presenta neanche questa necessità.
 
 \begin{figure}[!htb]
   \footnotesize   \centering
@@ -2173,26 +2173,26 @@ presenta neanche questa necessit
 \end{figure}
  
 Per evitare i problemi di interferenza con gli altri segnali in questo caso
-non si è usato l'approccio di fig.~\ref{fig:sig_sleep_incomplete} evitando
+non si è usato l'approccio di fig.~\ref{fig:sig_sleep_incomplete} evitando
 l'uso di \func{longjmp}. Come in precedenza il gestore (\texttt{\small 27-30})
 non esegue nessuna operazione, limitandosi a ritornare per interrompere il
 programma messo in attesa.
 
 La prima parte della funzione (\texttt{\small 6-10}) provvede ad installare
 l'opportuno gestore per \const{SIGALRM}, salvando quello originario, che
-sarà ripristinato alla conclusione della stessa (\texttt{\small 23}); il passo
-successivo è quello di bloccare \const{SIGALRM} (\texttt{\small 11-14}) per
+sarà ripristinato alla conclusione della stessa (\texttt{\small 23}); il passo
+successivo è quello di bloccare \const{SIGALRM} (\texttt{\small 11-14}) per
 evitare che esso possa essere ricevuto dal processo fra l'esecuzione di
 \func{alarm} (\texttt{\small 16}) e la sospensione dello stesso. Nel fare
-questo si salva la maschera corrente dei segnali, che sarà ripristinata alla
+questo si salva la maschera corrente dei segnali, che sarà ripristinata alla
 fine (\texttt{\small 22}), e al contempo si prepara la maschera dei segnali
 \var{sleep\_mask} per riattivare \const{SIGALRM} all'esecuzione di
 \func{sigsuspend}.  
 
-In questo modo non sono più possibili \itindex{race~condition} \textit{race
+In questo modo non sono più possibili \itindex{race~condition} \textit{race
   condition} dato che \const{SIGALRM} viene disabilitato con
-\func{sigprocmask} fino alla chiamata di \func{sigsuspend}.  Questo metodo è
-assolutamente generale e può essere applicato a qualunque altra situazione in
+\func{sigprocmask} fino alla chiamata di \func{sigsuspend}.  Questo metodo è
+assolutamente generale e può essere applicato a qualunque altra situazione in
 cui si deve attendere per un segnale, i passi sono sempre i seguenti:
 \begin{enumerate*}
 \item leggere la maschera dei segnali corrente e bloccare il segnale voluto
@@ -2213,31 +2213,31 @@ dell'esecuzione di \func{sigsuspend}.
 \label{sec:sig_signal_handler}
 
 Abbiamo finora parlato dei gestori dei segnali come funzioni chiamate in
-corrispondenza della consegna di un segnale. In realtà un gestore non può
-essere una funzione qualunque, in quanto esso può essere eseguito in
+corrispondenza della consegna di un segnale. In realtà un gestore non può
+essere una funzione qualunque, in quanto esso può essere eseguito in
 corrispondenza all'interruzione in un punto qualunque del programma
-principale, cosa che ad esempio può rendere problematico chiamare all'interno
-di un gestore di segnali la stessa funzione che dal segnale è stata
+principale, cosa che ad esempio può rendere problematico chiamare all'interno
+di un gestore di segnali la stessa funzione che dal segnale è stata
 interrotta.
 
 \index{funzioni!sicure|(}
 
-Il concetto è comunque più generale e porta ad una distinzione fra quelle che
+Il concetto è comunque più generale e porta ad una distinzione fra quelle che
 POSIX chiama \textsl{funzioni insicure} (\textit{signal unsafe function}) e
-\textsl{funzioni sicure} (o più precisamente \textit{signal safe function});
+\textsl{funzioni sicure} (o più precisamente \textit{signal safe function});
 quando un segnale interrompe una funzione insicura ed il gestore chiama al suo
-interno una funzione insicura il sistema può dare luogo ad un comportamento
+interno una funzione insicura il sistema può dare luogo ad un comportamento
 indefinito, la cosa non avviene invece per le funzioni sicure.
 
 Tutto questo significa che la funzione che si usa come gestore di segnale deve
-essere programmata con molta cura per evirare questa evenienza e che non è
+essere programmata con molta cura per evirare questa evenienza e che non è
 possibile utilizzare al suo interno una qualunque funzione di sistema, se si
-vogliono evitare questi problemi si può ricorrere soltanto all'uso delle
+vogliono evitare questi problemi si può ricorrere soltanto all'uso delle
 funzioni considerate sicure.
 
 L'elenco delle funzioni considerate sicure varia a seconda della
 implementazione utilizzata e dello standard a cui si fa
-riferimento;\footnote{non è riportata una lista specifica delle funzioni
+riferimento;\footnote{non è riportata una lista specifica delle funzioni
   sicure per Linux, si suppone pertanto che siano quelle richieste dallo
   standard.}  secondo quanto riportato dallo standard POSIX 1003.1 nella
 revisione del 2003, le ``\textit{signal safe function}'' che possono essere
@@ -2306,20 +2306,20 @@ ulteriori funzioni in fig.~\ref{fig:sig_safe_functions_posix_2008}.
 \end{figure}
 
 
-Per questo motivo è opportuno mantenere al minimo indispensabile le operazioni
+Per questo motivo è opportuno mantenere al minimo indispensabile le operazioni
 effettuate all'interno di un gestore di segnali, qualora si debbano compiere
-operazioni complesse è sempre preferibile utilizzare la tecnica in cui si usa
+operazioni complesse è sempre preferibile utilizzare la tecnica in cui si usa
 il gestore per impostare il valore di una qualche variabile globale, e poi si
 eseguono le operazioni complesse nel programma verificando (con tutti gli
 accorgimenti visti in precedenza) il valore di questa variabile tutte le volte
-che si è rilevata una interruzione dovuta ad un segnale.
+che si è rilevata una interruzione dovuta ad un segnale.
 
 
-\section{Funzionalità avanzate}
+\section{Funzionalità avanzate}
 \label{sec:sig_advanced_signal}
 
 
-Tratteremo in questa ultima sezione alcune funzionalità avanzate relativa ai
+Tratteremo in questa ultima sezione alcune funzionalità avanzate relativa ai
 segnali ed in generale ai meccanismi di notifica, a partire dalla funzioni
 introdotte per la gestione dei cosiddetti ``\textsl{segnali real-time}'', alla
 gestione avanzata delle temporizzazioni e le nuove interfacce per la gestione
@@ -2331,60 +2331,60 @@ di segnali ed eventi attraverso l'uso di file descriptor.
 Lo standard POSIX.1b, nel definire una serie di nuove interfacce per i servizi
 \textit{real-time}, ha introdotto una estensione del modello classico dei
 segnali che presenta dei significativi miglioramenti,\footnote{questa
-  estensione è stata introdotta in Linux a partire dal kernel 2.1.43, e dalle
+  estensione è stata introdotta in Linux a partire dal kernel 2.1.43, e dalle
   \acr{glibc} 2.1.} in particolare sono stati superati tre limiti fondamentali
 dei segnali classici:
 \begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}}
 \item[I segnali non sono accumulati] 
-  se più segnali vengono generati prima dell'esecuzione di un gestore
-  questo sarà eseguito una sola volta, ed il processo non sarà in grado di
-  accorgersi di quante volte l'evento che ha generato il segnale è accaduto;
+  se più segnali vengono generati prima dell'esecuzione di un gestore
+  questo sarà eseguito una sola volta, ed il processo non sarà in grado di
+  accorgersi di quante volte l'evento che ha generato il segnale è accaduto;
 \item[I segnali non trasportano informazione]   
   i segnali classici non prevedono altra informazione sull'evento
   che li ha generati se non il fatto che sono stati emessi (tutta
-  l'informazione che il kernel associa ad un segnale è il suo numero);
+  l'informazione che il kernel associa ad un segnale è il suo numero);
 \item[I segnali non hanno un ordine di consegna] 
-  l'ordine in cui diversi segnali vengono consegnati è casuale e non
-  prevedibile. Non è possibile stabilire una priorità per cui la reazione a
+  l'ordine in cui diversi segnali vengono consegnati è casuale e non
+  prevedibile. Non è possibile stabilire una priorità per cui la reazione a
   certi segnali ha la precedenza rispetto ad altri.
 \end{basedescript}
 
 Per poter superare queste limitazioni lo standard POSIX.1b ha introdotto delle
 nuove caratteristiche, che sono state associate ad una nuova classe di
 segnali, che vengono chiamati \textsl{segnali real-time}, in particolare le
-funzionalità aggiunte sono:
+funzionalità aggiunte sono:
 
 \begin{enumerate}
 \item i segnali sono inseriti in una coda che permette di consegnare istanze
-  multiple dello stesso segnale qualora esso venga inviato più volte prima
-  dell'esecuzione del gestore; si assicura così che il processo riceva un
+  multiple dello stesso segnale qualora esso venga inviato più volte prima
+  dell'esecuzione del gestore; si assicura così che il processo riceva un
   segnale per ogni occorrenza dell'evento che lo genera.
-\item è stata introdotta una priorità nella consegna dei segnali: i segnali
+\item è stata introdotta una priorità nella consegna dei segnali: i segnali
   vengono consegnati in ordine a seconda del loro valore, partendo da quelli
-  con un numero minore, che pertanto hanno una priorità maggiore.
-\item è stata introdotta la possibilità di restituire dei dati al gestore,
+  con un numero minore, che pertanto hanno una priorità maggiore.
+\item è stata introdotta la possibilità di restituire dei dati al gestore,
   attraverso l'uso di un apposito campo \var{si\_value} nella struttura
   \struct{siginfo\_t}, accessibile tramite gestori di tipo
   \var{sa\_sigaction}.
 \end{enumerate}
 
-Tutte queste nuove funzionalità eccetto l'ultima, che, come illustrato in
-sez.~\ref{sec:sig_sigaction}, è disponibile anche con i segnali ordinari, si
+Tutte queste nuove funzionalità eccetto l'ultima, che, come illustrato in
+sez.~\ref{sec:sig_sigaction}, è disponibile anche con i segnali ordinari, si
 applicano solo ai nuovi segnali \textit{real-time}; questi ultimi sono
 accessibili in un intervallo di valori specificati dalle due costanti
 \const{SIGRTMIN} e \const{SIGRTMAX}, che specificano il numero minimo e
 massimo associato ad un segnale \textit{real-time}.
 
-Su Linux di solito il primo valore è 33, mentre il secondo è \code{\_NSIG-1},
-che di norma (vale a dire sulla piattaforma i386) è 64. Questo dà un totale di
+Su Linux di solito il primo valore è 33, mentre il secondo è \code{\_NSIG-1},
+che di norma (vale a dire sulla piattaforma i386) è 64. Questo dà un totale di
 32 segnali disponibili, contro gli almeno 8 richiesti da POSIX.1b. Si tenga
-presente però che i primi segnali \textit{real-time} disponibili vendono usati
+presente però che i primi segnali \textit{real-time} disponibili vendono usati
 dalle \acr{glibc} per l'implementazione dei \textit{thread} POSIX (vedi
 sez.~\ref{sec:thread_posix_intro}), ed il valore di \const{SIGRTMIN} viene
 modificato di conseguenza.\footnote{vengono usati i primi tre per la vecchia
   implementazione dei \textit{LinuxThread} ed i primi due per la nuova NTPL
   (\textit{New Thread Posix Library}), il che comporta che \const{SIGRTMIN} a
-  seconda dei casi può essere 34 o 35.}
+  seconda dei casi può essere 34 o 35.}
 
 Per questo motivo nei programmi che usano i segnali \textit{real-time} non si
 deve mai usare un valore assoluto dato che si correrebbe il rischio di
@@ -2393,11 +2393,11 @@ invece essere sempre specificato in forma relativa a \const{SIGRTMIN} (come
 \code{SIGRTMIN + n}) avendo inoltre cura di controllare di non aver mai
 superato \const{SIGRTMAX}.
 
-I segnali con un numero più basso hanno una priorità maggiore e vengono
+I segnali con un numero più basso hanno una priorità maggiore e vengono
 consegnati per primi, inoltre i segnali \textit{real-time} non possono
-interrompere l'esecuzione di un gestore di un segnale a priorità più alta; la
-loro azione predefinita è quella di terminare il programma.  I segnali
-ordinari hanno tutti la stessa priorità, che è più alta di quella di qualunque
+interrompere l'esecuzione di un gestore di un segnale a priorità più alta; la
+loro azione predefinita è quella di terminare il programma.  I segnali
+ordinari hanno tutti la stessa priorità, che è più alta di quella di qualunque
 segnale \textit{real-time}.\footnote{lo standard non definisce niente al
   riguardo ma Linux, come molte altre implementazioni, adotta questa
   politica.}
@@ -2408,13 +2408,13 @@ meccanismi di notifica come quelli per l'I/O asincrono (vedi
 sez.~\ref{sec:file_asyncronous_io}) o per le code di messaggi POSIX (vedi
 sez.~\ref{sec:ipc_posix_mq}); pertanto devono essere inviati esplicitamente.
 
-Inoltre, per poter usufruire della capacità di restituire dei dati, i relativi
+Inoltre, per poter usufruire della capacità di restituire dei dati, i relativi
 gestori devono essere installati con \func{sigaction}, specificando per
-\var{sa\_flags} la modalità \const{SA\_SIGINFO} che permette di utilizzare la
+\var{sa\_flags} la modalità \const{SA\_SIGINFO} che permette di utilizzare la
 forma estesa \var{sa\_sigaction} (vedi sez.~\ref{sec:sig_sigaction}).  In
 questo modo tutti i segnali \textit{real-time} possono restituire al gestore
 una serie di informazioni aggiuntive attraverso l'argomento
-\struct{siginfo\_t}, la cui definizione è stata già vista in
+\struct{siginfo\_t}, la cui definizione è stata già vista in
 fig.~\ref{fig:sig_siginfo_t}, nella trattazione dei gestori in forma estesa.
 
 In particolare i campi utilizzati dai segnali \textit{real-time} sono
@@ -2433,11 +2433,11 @@ per la restituzione dei dati viene usato il campo \var{si\_value}.
   \label{fig:sig_sigval}
 \end{figure}
 
-Questo è una \ctyp{union} di tipo \struct{sigval} (la sua definizione è in
-fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico,
+Questo è una \ctyp{union} di tipo \struct{sigval} (la sua definizione è in
+fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico,
 se usata nella forma \var{sival\_int}, o un indirizzo, se usata nella forma
 \var{sival\_ptr}. L'unione viene usata dai segnali \textit{real-time} e da
-vari meccanismi di notifica\footnote{un campo di tipo \struct{sigval\_t} è
+vari meccanismi di notifica\footnote{un campo di tipo \struct{sigval\_t} è
   presente anche nella struttura \struct{sigevent} (definita in
   fig.~\ref{fig:struct_sigevent}) che viene usata dai meccanismi di notifica
   come quelli per i timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}), l'I/O
@@ -2446,10 +2446,10 @@ vari meccanismi di notifica\footnote{un campo di tipo \struct{sigval\_t} 
 del segnale; in alcune definizioni essa viene identificata anche con
 l'abbreviazione \type{sigval\_t}.
 
-A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
-inviare segnali \textit{real-time}, poiché non è in grado di fornire alcun
+A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
+inviare segnali \textit{real-time}, poiché non è in grado di fornire alcun
 valore per \struct{sigval}; per questo motivo lo standard ha previsto una
-nuova funzione, \funcd{sigqueue}, il cui prototipo è:
+nuova funzione, \funcd{sigqueue}, il cui prototipo è:
 \begin{prototype}{signal.h}
   {int sigqueue(pid\_t pid, int signo, const union sigval value)}
   
@@ -2457,62 +2457,62 @@ nuova funzione, \funcd{sigqueue}, il cui prototipo 
   gestore il valore \param{value}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EAGAIN}] la coda è esaurita, ci sono già
+  \item[\errcode{EAGAIN}] la coda è esaurita, ci sono già
     \const{SIGQUEUE\_MAX} segnali in attesa si consegna.
   \item[\errcode{EPERM}] non si hanno privilegi appropriati per inviare il
     segnale al processo specificato.
   \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
-  \item[\errcode{EINVAL}] si è specificato un valore non valido per
+  \item[\errcode{EINVAL}] si è specificato un valore non valido per
     \param{signo}.
   \end{errlist}
   ed inoltre \errval{ENOMEM}.}
 \end{prototype}
 
-Il comportamento della funzione è analogo a quello di \func{kill}, ed i
+Il comportamento della funzione è analogo a quello di \func{kill}, ed i
 privilegi occorrenti ad inviare il segnale ad un determinato processo sono gli
 stessi; un valore nullo di \param{signo} permette di verificare le condizioni
 di errore senza inviare nessun segnale.
 
-Se il segnale è bloccato la funzione ritorna immediatamente, se si è
+Se il segnale è bloccato la funzione ritorna immediatamente, se si è
 installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili,
-(vale a dire che c'è posto nella coda dei segnali \textit{real-time}) esso
-viene inserito e diventa pendente; una volta consegnato riporterà nel campo
+(vale a dire che c'è posto nella coda dei segnali \textit{real-time}) esso
+viene inserito e diventa pendente; una volta consegnato riporterà nel campo
 \var{si\_code} di \struct{siginfo\_t} il valore \const{SI\_QUEUE} e il campo
-\var{si\_value} riceverà quanto inviato con \param{value}. Se invece si è
-installato un gestore nella forma classica il segnale sarà generato, ma tutte
-le caratteristiche tipiche dei segnali \textit{real-time} (priorità e coda)
+\var{si\_value} riceverà quanto inviato con \param{value}. Se invece si è
+installato un gestore nella forma classica il segnale sarà generato, ma tutte
+le caratteristiche tipiche dei segnali \textit{real-time} (priorità e coda)
 saranno perse.
 
-Secondo lo standard POSIX la profondità della coda è indicata dalla costante
+Secondo lo standard POSIX la profondità della coda è indicata dalla costante
 \const{SIGQUEUE\_MAX},\footnote{una della tante costanti di sistema definite
   dallo standard POSIX che non abbiamo riportato esplicitamente in
   sez.~\ref{sec:sys_limits}.} il suo valore minimo secondo lo standard,
-\const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux la coda ha una
+\const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux la coda ha una
 dimensione variabile; fino alla versione 2.6.7 c'era un limite massimo globale
 che poteva essere impostato come parametro del kernel in
 \procfile{/proc/sys/kernel/rtsig-max};\footnote{ed il valore predefinito era
-  pari a 1024.} a partire dal kernel 2.6.8 il valore globale è stato rimosso e
+  pari a 1024.} a partire dal kernel 2.6.8 il valore globale è stato rimosso e
 sostituito dalla risorsa \const{RLIMIT\_SIGPENDING} associata al singolo
-utente, che può essere modificata con \func{setrlimit} come illustrato in
+utente, che può essere modificata con \func{setrlimit} come illustrato in
 sez.~\ref{sec:sys_resource_limit}.
 
 Lo standard POSIX.1b definisce inoltre delle nuove funzioni che permettono di
 gestire l'attesa di segnali specifici su una coda, esse servono in particolar
 modo nel caso dei \itindex{thread} \textit{thread}, in cui si possono usare i
 segnali \textit{real-time} come meccanismi di comunicazione elementare; la
-prima di queste funzioni è \funcd{sigwait}, il cui prototipo è:
+prima di queste funzioni è \funcd{sigwait}, il cui prototipo è:
 \begin{prototype}{signal.h}
   {int sigwait(const sigset\_t *set, int *sig)}
   
   Attende che uno dei segnali specificati in \param{set} sia pendente.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EINTR}] la funzione è stata interrotta.
-  \item[\errcode{EINVAL}] si è specificato un valore non valido per
+  \item[\errcode{EINTR}] la funzione è stata interrotta.
+  \item[\errcode{EINVAL}] si è specificato un valore non valido per
     \param{set}.
   \end{errlist}
   ed inoltre \errval{EFAULT}.}
@@ -2520,18 +2520,18 @@ prima di queste funzioni 
 
 La funzione estrae dall'insieme dei segnali pendenti uno qualunque dei segnali
 specificati da \param{set}, il cui valore viene restituito in \param{sig}.  Se
-sono pendenti più segnali, viene estratto quello a priorità più alta (cioè con
-il numero più basso). Se, nel caso di segnali \textit{real-time}, c'è più di
-un segnale pendente, ne verrà estratto solo uno. Una volta estratto il segnale
-non verrà più consegnato, e se era in una coda il suo posto sarà liberato. Se
-non c'è nessun segnale pendente il processo viene bloccato fintanto che non ne
+sono pendenti più segnali, viene estratto quello a priorità più alta (cioè con
+il numero più basso). Se, nel caso di segnali \textit{real-time}, c'è più di
+un segnale pendente, ne verrà estratto solo uno. Una volta estratto il segnale
+non verrà più consegnato, e se era in una coda il suo posto sarà liberato. Se
+non c'è nessun segnale pendente il processo viene bloccato fintanto che non ne
 arriva uno.
 
 Per un funzionamento corretto la funzione richiede che alla sua chiamata i
 segnali di \param{set} siano bloccati. In caso contrario si avrebbe un
 conflitto con gli eventuali gestori: pertanto non si deve utilizzare per
 lo stesso segnale questa funzione e \func{sigaction}. Se questo non avviene il
-comportamento del sistema è indeterminato: il segnale può sia essere
+comportamento del sistema è indeterminato: il segnale può sia essere
 consegnato che essere ricevuto da \func{sigwait}, il tutto in maniera non
 prevedibile.
 
@@ -2549,15 +2549,15 @@ prevalentemente con i \itindex{thread} \textit{thread}; \funcd{sigwaitinfo} e
   \funcdecl{int sigtimedwait(const sigset\_t *set, siginfo\_t *info, const
     struct timespec *timeout)}
   
-  Analoga a \func{sigwaitinfo}, con un la possibilità di specificare un
+  Analoga a \func{sigwaitinfo}, con un la possibilità di specificare un
   timeout in \param{timeout}.
 
   
   \bodydesc{Le funzioni restituiscono 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori già visti per
+    errore, nel qual caso \var{errno} assumerà uno dei valori già visti per
     \func{sigwait}, ai quali si aggiunge, per \func{sigtimedwait}:
   \begin{errlist}
-  \item[\errcode{EAGAIN}] si è superato il timeout senza che un segnale atteso
+  \item[\errcode{EAGAIN}] si è superato il timeout senza che un segnale atteso
     fosse emesso.
   \end{errlist}
 }
@@ -2566,20 +2566,20 @@ prevalentemente con i \itindex{thread} \textit{thread}; \funcd{sigwaitinfo} e
 Entrambe le funzioni sono estensioni di \func{sigwait}. La prima permette di
 ricevere, oltre al numero del segnale, anche le informazioni ad esso associate
 tramite \param{info}; in particolare viene restituito il numero del segnale
-nel campo \var{si\_signo}, la sua causa in \var{si\_code}, e se il segnale è
+nel campo \var{si\_signo}, la sua causa in \var{si\_code}, e se il segnale è
 stato immesso sulla coda con \func{sigqueue}, il valore di ritorno ad esso
-associato viene riportato in \var{si\_value}, che altrimenti è indefinito. 
+associato viene riportato in \var{si\_value}, che altrimenti è indefinito. 
 
-La seconda è identica alla prima ma in più permette di specificare un timeout,
-scaduto il quale ritornerà con un errore. Se si specifica un puntatore nullo
-il comportamento sarà identico a \func{sigwaitinfo}, se si specifica un tempo
-di timeout nullo, e non ci sono segnali pendenti la funzione ritornerà
-immediatamente; in questo modo si può eliminare un segnale dalla coda senza
+La seconda è identica alla prima ma in più permette di specificare un timeout,
+scaduto il quale ritornerà con un errore. Se si specifica un puntatore nullo
+il comportamento sarà identico a \func{sigwaitinfo}, se si specifica un tempo
+di timeout nullo, e non ci sono segnali pendenti la funzione ritornerà
+immediatamente; in questo modo si può eliminare un segnale dalla coda senza
 dover essere bloccati qualora esso non sia presente.
 
 \itindbeg{thread} 
 
-L'uso di queste funzioni è principalmente associato alla gestione dei segnali
+L'uso di queste funzioni è principalmente associato alla gestione dei segnali
 con i \textit{thread}. In genere esse vengono chiamate dal \textit{thread}
 incaricato della gestione, che al ritorno della funzione esegue il codice che
 usualmente sarebbe messo nel gestore, per poi ripetere la chiamata per
@@ -2601,18 +2601,18 @@ sez.~\ref{sec:sys_cpu_times} che quelle per la gestione dei timer di
 sez.~\ref{sec:sig_alarm_abort} sono state a lungo limitate dalla risoluzione
 massima dei tempi dell'orologio interno del kernel, che era quella ottenibile
 dal timer di sistema che governa lo \textit{scheduler},\footnote{e quindi
-  limitate dalla frequenza dello stesso che si ricordi, come già illustrato in
-  sez.~\ref{sec:proc_hierarchy}, è data dal valore della costante
+  limitate dalla frequenza dello stesso che si ricordi, come già illustrato in
+  sez.~\ref{sec:proc_hierarchy}, è data dal valore della costante
   \texttt{HZ}.} i contatori usati per il calcolo dei tempo infatti erano
 basati sul numero di \itindex{jiffies} \textit{jiffies} che vengono
 incrementati ad ogni \textit{clock tick} del timer di sistema.\footnote{il che
   comportava anche, come accennato in sez.~\ref{sec:sig_alarm_abort} per
   \func{setitimer}, problemi per il massimo periodo di tempo copribile da
   alcuni di questi orologi, come quelli associati al \textit{process time}
-  almeno fino a quando, con il kernel 2.6.16, non è stato rimosso il limite di
+  almeno fino a quando, con il kernel 2.6.16, non è stato rimosso il limite di
   un valore a 32 bit per i \textit{jiffies}.}
 
-Nelle architetture moderne però tutti i computer sono dotati di temporizzatori
+Nelle architetture moderne però tutti i computer sono dotati di temporizzatori
 hardware che possono supportare risoluzioni molto elevate, ed in maniera del
 tutto indipendente dalla frequenza scelta per il timer di sistema che governa
 lo \textit{scheduler};\footnote{normalmente si possono ottenere precisioni
@@ -2620,25 +2620,25 @@ lo \textit{scheduler};\footnote{normalmente si possono ottenere precisioni
 questo lo standard POSIX.1-2001 ha previsto una serie di nuove funzioni
 relative a quelli che vengono chiamati ``\textsl{orologi}
 \textit{real-time}'', in grado di supportare risoluzioni fino al
-nanosecondo. Inoltre le CPU più moderne sono dotate a loro volta di contatori
+nanosecondo. Inoltre le CPU più moderne sono dotate a loro volta di contatori
 ad alta definizione che consentono una grande accuratezza nella misura del
 tempo da esse dedicato all'esecuzione di un processo.
 
-Per usare queste funzionalità ed ottenere risoluzioni temporali più accurate,
-occorre però un opportuno supporto da parte del kernel, ed i cosiddetti
-\textit{high resolution timer} che consentono di fare ciò sono stati
+Per usare queste funzionalità ed ottenere risoluzioni temporali più accurate,
+occorre però un opportuno supporto da parte del kernel, ed i cosiddetti
+\textit{high resolution timer} che consentono di fare ciò sono stati
 introdotti nel kernel ufficiale solo a partire dalla versione
 2.6.21.\footnote{deve essere stata abilitata l'opzione di compilazione
-  \texttt{CONFIG\_HIGH\_RES\_TIMERS}, erano però disponibili anche in
+  \texttt{CONFIG\_HIGH\_RES\_TIMERS}, erano però disponibili anche in
   precedenza come patch facenti parte dello sviluppo delle estensioni
   \textit{real-time} del kernel, per cui alcune distribuzioni possono avere
   questo supporto anche con versioni precedenti del kernel.} Le funzioni
-definite dallo standard POSIX per gestire orologi ad alta definizione però
-erano già presenti, essendo stata introdotte insieme ad altre funzioni per il
+definite dallo standard POSIX per gestire orologi ad alta definizione però
+erano già presenti, essendo stata introdotte insieme ad altre funzioni per il
 supporto delle estensioni \textit{real-time} con il rilascio del kernel 2.6,
 ma la risoluzione effettiva era nominale.
 
-A tutte le implementazioni che si rifanno a queste estensioni è richiesto di
+A tutte le implementazioni che si rifanno a queste estensioni è richiesto di
 disporre di una versione \textit{real-time} almeno per l'orologio generale di
 sistema, quello che mantiene il \textit{calendar time} (vedi
 sez.~\ref{sec:sys_time_base}), che in questa forma deve indicare il numero di
@@ -2649,7 +2649,7 @@ secondi e nanosecondi passati a partire dal primo gennaio 1970 (\textit{The
   hardware specializzato).}  Oltre all'orologio generale di sistema possono
 essere presenti altri tipi di orologi \textit{real-time}, ciascuno dei quali
 viene identificato da un opportuno valore di una variabile di tipo
-\type{clockid\_t}; un elenco di quelli disponibili su Linux è riportato in
+\type{clockid\_t}; un elenco di quelli disponibili su Linux è riportato in
 tab.~\ref{tab:sig_timer_clockid_types}.
 
 \begin{table}[htb]
@@ -2660,12 +2660,12 @@ tab.~\ref{tab:sig_timer_clockid_types}.
     \textbf{Valore} & \textbf{Significato} \\
     \hline
     \hline
-    \const{CLOCK\_REALTIME}     & Orologio \textit{real-time} di sistema, può
+    \const{CLOCK\_REALTIME}     & Orologio \textit{real-time} di sistema, può
                                   essere impostato solo con privilegi
                                   amministrativi.\\ 
     \const{CLOCK\_MONOTONIC}    & Orologio che indica un tempo monotono
                                   crescente (a partire da un tempo iniziale non
-                                  specificato) che non può essere modificato.\\
+                                  specificato) che non può essere modificato.\\
     \const{CLOCK\_MONOTONIC\_RAW}&Simile al precedente, ma non subisce gli
                                   aggiustamenti dovuti all'uso di NTP (viene
                                   usato per fare riferimento ad una fonte
@@ -2694,12 +2694,12 @@ tab.~\ref{tab:sig_timer_clockid_types}.
 
 % TODO, dal 2.6.39 anche CLOCK_BOOTTIME, vedi http://lwn.net/Articles/432757/
 
-Per poter utilizzare queste funzionalità le \acr{glibc} richiedono che la
+Per poter utilizzare queste funzionalità le \acr{glibc} richiedono che la
 macro \macro{\_POSIX\_C\_SOURCE} sia definita ad un valore maggiore o uguale
 di \texttt{199309L} (vedi sez.~\ref{sec:intro_gcc_glibc_std}), inoltre i
 programmi che le usano devono essere collegati con la libreria delle estensioni
 \textit{real-time} usando esplicitamente l'opzione \texttt{-lrt}. Si tenga
-presente inoltre che la disponibilità di queste funzionalità avanzate può
+presente inoltre che la disponibilità di queste funzionalità avanzate può
 essere controllato dalla definizione della macro \macro{\_POSIX\_TIMERS} ad un
 valore maggiore di 0, e che le ulteriori macro
 \macro{\_POSIX\_MONOTONIC\_CLOCK}, \macro{\_POSIX\_CPUTIME} e
@@ -2708,7 +2708,7 @@ di tipo \const{CLOCK\_MONOTONIC}, \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
 \const{CLOCK\_PROCESS\_CPUTIME\_ID}.\footnote{tutte queste macro sono definite
   in \texttt{unistd.h}, che pertanto deve essere incluso per poterle
   controllarle.} Infine se il kernel ha il supporto per gli \textit{high
-  resolution timer} un elenco degli orologi e dei timer può essere ottenuto
+  resolution timer} un elenco degli orologi e dei timer può essere ottenuto
 tramite il file \procfile{/proc/timer\_list}.
 
 Le due funzioni che ci consentono rispettivamente di modificare o leggere il
@@ -2723,14 +2723,14 @@ valore per uno degli orologi \textit{real-time} sono \funcd{clock\_settime} e
   Imposta o legge un orologio \textit{real-time}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+    errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] il valore specificato per \param{clockid} non è
-    valido o il relativo orologio \textit{real-time} non è supportato dal
+  \item[\errcode{EINVAL}] il valore specificato per \param{clockid} non è
+    valido o il relativo orologio \textit{real-time} non è supportato dal
     sistema.
   \item[\errcode{EPERM}] non si ha il permesso di impostare l'orologio
     indicato (solo per \func{clock\_settime}).
-  \item[\errcode{EFAULT}] l'indirizzo \param{tp} non è valido.
+  \item[\errcode{EFAULT}] l'indirizzo \param{tp} non è valido.
   \end{errlist}
 }
 \end{functions}
@@ -2739,28 +2739,28 @@ Entrambe le funzioni richiedono che si specifichi come primo argomento il tipo
 di orologio su cui si vuole operare con uno dei valori di
 tab.~\ref{tab:sig_timer_clockid_types} o con il risultato di una chiamata a
 \func{clock\_getcpuclockid} (che tratteremo a breve), il secondo argomento
-invece è sempre il puntatore \param{tp} ad una struttura \struct{timespec}
+invece è sempre il puntatore \param{tp} ad una struttura \struct{timespec}
 (vedi fig.~\ref{fig:sys_timespec_struct}) che deve essere stata
-precedentemente allocata; nel primo caso questa dovrà anche essere stata
+precedentemente allocata; nel primo caso questa dovrà anche essere stata
 inizializzata con il valore che si vuole impostare sull'orologio, mentre nel
-secondo verrà restituito al suo interno il valore corrente dello stesso.
+secondo verrà restituito al suo interno il valore corrente dello stesso.
 
 Si tenga presente inoltre che per eseguire un cambiamento sull'orologio
 generale di sistema \const{CLOCK\_REALTIME} occorrono i privilegi
 amministrativi;\footnote{ed in particolare la \textit{capability}
-  \const{CAP\_SYS\_TIME}.} inoltre ogni cambiamento ad esso apportato non avrà
+  \const{CAP\_SYS\_TIME}.} inoltre ogni cambiamento ad esso apportato non avrà
 nessun effetto sulle temporizzazioni effettuate in forma relativa, come quelle
-impostate sulle quantità di \textit{process time} o per un intervallo di tempo
+impostate sulle quantità di \textit{process time} o per un intervallo di tempo
 da trascorrere, ma solo su quelle che hanno richiesto una temporizzazione ad
 un istante preciso (in termini di \textit{calendar time}). Si tenga inoltre
-presente che nel caso di Linux \const{CLOCK\_REALTIME} è l'unico orologio per
-cui si può effettuare una modifica, infatti nonostante lo standard preveda la
-possibilità di modifiche anche per \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
+presente che nel caso di Linux \const{CLOCK\_REALTIME} è l'unico orologio per
+cui si può effettuare una modifica, infatti nonostante lo standard preveda la
+possibilità di modifiche anche per \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
 \const{CLOCK\_THREAD\_CPUTIME\_ID}, il kernel non le consente.
 
 Oltre alle due funzioni precedenti, lo standard POSIX prevede una terza
 funzione che consenta di ottenere la risoluzione effettiva fornita da un certo
-orologio, la funzione è \funcd{clock\_getres} ed il suo prototipo è:
+orologio, la funzione è \funcd{clock\_getres} ed il suo prototipo è:
 \begin{functions}
   \headdecl{time.h}
 
@@ -2769,54 +2769,54 @@ orologio, la funzione 
   Legge la risoluzione di un orologio \textit{real-time}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+    errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] il valore specificato per \param{clockid} non è
+  \item[\errcode{EINVAL}] il valore specificato per \param{clockid} non è
     valido.
-  \item[\errcode{EFAULT}] l'indirizzo di \param{res} non è valido.
+  \item[\errcode{EFAULT}] l'indirizzo di \param{res} non è valido.
   \end{errlist}
 }
 \end{functions}
 
 La funzione richiede come primo argomento l'indicazione dell'orologio di cui
 si vuole conoscere la risoluzione (effettuata allo stesso modo delle due
-precedenti) e questa verrà restituita in una struttura \struct{timespec}
+precedenti) e questa verrà restituita in una struttura \struct{timespec}
 all'indirizzo puntato dall'argomento \param{res}. 
 
 Come accennato il valore di questa risoluzione dipende sia dall'hardware
 disponibile che dalla implementazione delle funzioni, e costituisce il limite
-minimo di un intervallo di tempo che si può indicare. Qualunque valore si
+minimo di un intervallo di tempo che si può indicare. Qualunque valore si
 voglia utilizzare nelle funzioni di impostazione che non corrisponda ad un
-multiplo intero di questa risoluzione, sarà troncato in maniera automatica. 
+multiplo intero di questa risoluzione, sarà troncato in maniera automatica. 
 
 Si tenga presente inoltre che con l'introduzione degli \textit{high resolution
   timer} i due orologi \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
 \const{CLOCK\_THREAD\_CPUTIME\_ID} fanno riferimento ai contatori presenti in
 opportuni registri interni del processore; questo sui sistemi multiprocessore
-può avere delle ripercussioni sulla precisione delle misure di tempo che vanno
-al di là della risoluzione teorica ottenibile con \func{clock\_getres}, che
-può essere ottenuta soltanto quando si è sicuri che un processo (o un
+può avere delle ripercussioni sulla precisione delle misure di tempo che vanno
+al di là della risoluzione teorica ottenibile con \func{clock\_getres}, che
+può essere ottenuta soltanto quando si è sicuri che un processo (o un
 \textit{thread}) sia sempre stato eseguito sullo stesso processore.
 
 Con i sistemi multiprocessore infatti ogni singola CPU ha i suoi registri
-interni, e se ciascuna di esse utilizza una base di tempo diversa (se cioè il
+interni, e se ciascuna di esse utilizza una base di tempo diversa (se cioè il
 segnale di temporizzazione inviato ai processori non ha una sola provenienza)
-in genere ciascuna di queste potrà avere delle frequenze leggermente diverse,
+in genere ciascuna di queste potrà avere delle frequenze leggermente diverse,
 e si otterranno pertanto dei valori dei contatori scorrelati fra loro, senza
-nessuna possibilità di sincronizzazione.
+nessuna possibilità di sincronizzazione.
 
-Il problema si presenta, in forma più lieve, anche se la base di tempo è la
+Il problema si presenta, in forma più lieve, anche se la base di tempo è la
 stessa, dato che un sistema multiprocessore non avvia mai tutte le CPU allo
-stesso istante, si potrà così avere di nuovo una differenza fra i contatori,
-soggetta però soltanto ad uno sfasamento costante. Per questo caso il kernel
+stesso istante, si potrà così avere di nuovo una differenza fra i contatori,
+soggetta però soltanto ad uno sfasamento costante. Per questo caso il kernel
 per alcune architetture ha del codice che consente di ridurre al minimo la
-differenza, ma non può essere comunque garantito che questa si annulli (anche
+differenza, ma non può essere comunque garantito che questa si annulli (anche
 se in genere risulta molto piccola e trascurabile nella gran parte dei casi).
 
 Per poter gestire questo tipo di problematiche lo standard ha previsto una
 apposita funzione che sia in grado di ottenere l'identificativo dell'orologio
-associato al \textit{process time} di un processo, la funzione è
-\funcd{clock\_getcpuclockid} ed il suo prototipo è:
+associato al \textit{process time} di un processo, la funzione è
+\funcd{clock\_getcpuclockid} ed il suo prototipo è:
 \begin{functions}
   \headdecl{time.h}
 
@@ -2825,10 +2825,10 @@ associato al \textit{process time} di un processo, la funzione 
   Ottiene l'identificatore dell'orologio di CPU usato da un processo.
   
   \bodydesc{La funzione restituisce 0 in caso di successo o un numero positivo
-    in caso di errore, nel qual caso \var{errno} assumerà uno dei seguenti
+    in caso di errore, nel qual caso \var{errno} assumerà uno dei seguenti
     valori:
   \begin{errlist}
-  \item[\errcode{ENOSYS}] non c'è il supporto per ottenere l'orologio relativo
+  \item[\errcode{ENOSYS}] non c'è il supporto per ottenere l'orologio relativo
     al \textit{process time} di un altro processo, e \param{pid} non
     corrisponde al processo corrente.
   \item[\errcode{EPERM}] il chiamante non ha il permesso di accedere alle
@@ -2841,15 +2841,15 @@ associato al \textit{process time} di un processo, la funzione 
 
 La funzione ritorna l'identificativo di un orologio di sistema associato ad un
 processo indicato tramite l'argomento \param{pid}. Un utente normale, posto
-che il kernel sia sufficientemente recente da supportare questa funzionalità,
-può accedere soltanto ai dati relativi ai propri processi.
+che il kernel sia sufficientemente recente da supportare questa funzionalità,
+può accedere soltanto ai dati relativi ai propri processi.
 
 Del tutto analoga a \func{clock\_getcpuclockid}, ma da utilizzare per ottenere
-l'orologio associato ad un \textit{thread} invece che a un processo, è
+l'orologio associato ad un \textit{thread} invece che a un processo, è
 \funcd{pthread\_getcpuclockid},\footnote{per poter usare la funzione, come per
   qualunque funzione che faccia riferimento ai \textit{thread}, occorre
   effettuare il collegamento alla relativa libreria di gestione compilando il
-  programma con \texttt{-lpthread}.} il cui prototipo è:
+  programma con \texttt{-lpthread}.} il cui prototipo è:
 \begin{functions}
   \headdecl{pthread.h}
   \headdecl{time.h}
@@ -2860,10 +2860,10 @@ l'orologio associato ad un \textit{thread} invece che a un processo, 
   \textit{thread}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo o un numero positivo
-    in caso di errore, nel qual caso \var{errno} assumerà uno dei seguenti
+    in caso di errore, nel qual caso \var{errno} assumerà uno dei seguenti
     valori:
   \begin{errlist}
-  \item[\errcode{ENOENT}] la funzione non è supportata dal sistema.
+  \item[\errcode{ENOENT}] la funzione non è supportata dal sistema.
   \item[\errcode{ESRCH}] non esiste il \textit{thread} identificato
     da \param{thread}.
   \end{errlist}
@@ -2873,20 +2873,20 @@ l'orologio associato ad un \textit{thread} invece che a un processo, 
 
 % TODO, dal 2.6.39 aggiunta clock_adjtime 
 
-Con l'introduzione degli orologi ad alta risoluzione è divenuto possibile
-ottenere anche una gestione più avanzata degli allarmi; abbiamo già visto in
+Con l'introduzione degli orologi ad alta risoluzione è divenuto possibile
+ottenere anche una gestione più avanzata degli allarmi; abbiamo già visto in
 sez.~\ref{sec:sig_alarm_abort} come l'interfaccia di \func{setitimer} derivata
 da BSD presenti delle serie limitazioni,\footnote{in particolare la
-  possibilità di perdere un segnale sotto carico.} tanto che nello standard
+  possibilità di perdere un segnale sotto carico.} tanto che nello standard
 POSIX.1-2008 questa viene marcata come obsoleta, e ne viene fortemente
 consigliata la sostituzione con nuova interfaccia definita dallo standard
 POSIX.1-2001 che va sotto il nome di \textit{Posix Timer API}. Questa
-interfaccia è stata introdotta a partire dal kernel 2.6, anche se il supporto
-di varie funzionalità è stato aggiunto solo in un secondo tempo.
+interfaccia è stata introdotta a partire dal kernel 2.6, anche se il supporto
+di varie funzionalità è stato aggiunto solo in un secondo tempo.
 
-Una delle principali differenze della nuova interfaccia è che un processo può
+Una delle principali differenze della nuova interfaccia è che un processo può
 utilizzare un numero arbitrario di timer; questi vengono creati (ma non
-avviati) tramite la funzione \funcd{timer\_create}, il cui prototipo è:
+avviati) tramite la funzione \funcd{timer\_create}, il cui prototipo è:
 \begin{functions}
   \headdecl{signal.h}
   \headdecl{time.h}
@@ -2897,13 +2897,13 @@ avviati) tramite la funzione \funcd{timer\_create}, il cui prototipo 
   Crea un nuovo timer Posix.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+    errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
   \begin{errlist}
   \item[\errcode{EAGAIN}] fallimento nel tentativo di allocare le strutture
     dei timer.
   \item[\errcode{EINVAL}] uno dei valori specificati per \param{clockid} o per
     i campi \var{sigev\_notify}, \var{sigev\_signo} o
-    \var{sigev\_notify\_thread\_id} di \param{evp} non è valido.
+    \var{sigev\_notify\_thread\_id} di \param{evp} non è valido.
   \item[\errcode{ENOMEM}] errore di allocazione della memoria.
   \end{errlist}
 }
@@ -2911,14 +2911,14 @@ avviati) tramite la funzione \funcd{timer\_create}, il cui prototipo 
 
 La funzione richiede tre argomenti: il primo argomento serve ad indicare quale
 tipo di orologio si vuole utilizzare e prende uno dei valori di
-tab.~\ref{tab:sig_timer_clockid_types},\footnote{di detti valori però non è
+tab.~\ref{tab:sig_timer_clockid_types},\footnote{di detti valori però non è
   previsto l'uso di \const{CLOCK\_MONOTONIC\_RAW} mentre
   \const{CLOCK\_PROCESS\_CPUTIME\_ID} e \const{CLOCK\_THREAD\_CPUTIME\_ID}
-  sono disponibili solo a partire dal kernel 2.6.12.} si può così fare
+  sono disponibili solo a partire dal kernel 2.6.12.} si può così fare
 riferimento sia ad un tempo assoluto che al tempo utilizzato dal processo (o
 \textit{thread}) stesso. 
 
-Il secondo argomento richiede una trattazione più dettagliata, in quanto
+Il secondo argomento richiede una trattazione più dettagliata, in quanto
 introduce una struttura di uso generale, \struct{sigevent}, che viene
 utilizzata anche da altre funzioni, come quelle per l'I/O asincrono (vedi
 sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi POSIX (vedi
@@ -2932,21 +2932,21 @@ meccanismo di notifica.
   \end{minipage} 
   \normalsize 
   \caption{La struttura \structd{sigevent}, usata per specificare in maniera
-    generica diverse modalità di notifica degli eventi.}
+    generica diverse modalità di notifica degli eventi.}
   \label{fig:struct_sigevent}
 \end{figure}
 
-La struttura \struct{sigevent} (accessibile includendo \texttt{time.h}) è
+La struttura \struct{sigevent} (accessibile includendo \texttt{time.h}) è
 riportata in fig.~\ref{fig:struct_sigevent};\footnote{la definizione effettiva
-  dipende dall'implementazione, quella mostrata è la versione descritta nella
-  pagina di manuale di \func{timer\_create}.} il campo \var{sigev\_notify} è il
-più importante essendo quello che indica le modalità della notifica, gli altri
-dipendono dal valore che si è specificato per \var{sigev\_notify}, si sono
+  dipende dall'implementazione, quella mostrata è la versione descritta nella
+  pagina di manuale di \func{timer\_create}.} il campo \var{sigev\_notify} è il
+più importante essendo quello che indica le modalità della notifica, gli altri
+dipendono dal valore che si è specificato per \var{sigev\_notify}, si sono
 riportati in tab.~\ref{tab:sigevent_sigev_notify}. La scelta del meccanismo di
 notifica viene fatta impostando uno dei valori di
 tab.~\ref{tab:sigevent_sigev_notify} per \var{sigev\_notify}, e fornendo gli
 eventuali ulteriori argomenti necessari a secondo della scelta
-effettuata. Diventa così possibile indicare l'uso di un segnale o l'esecuzione
+effettuata. Diventa così possibile indicare l'uso di un segnale o l'esecuzione
 (nel caso di uso dei \textit{thread}) di una funzione di modifica in un
 \textit{thread} dedicato.
 
@@ -2962,25 +2962,25 @@ effettuata. Diventa cos
     \const{SIGEV\_SIGNAL}  & La notifica viene effettuata inviando al processo
                              chiamante il segnale specificato dal campo
                              \var{sigev\_signo}; se il gestore di questo
-                             segnale è stato installato con
-                             \const{SA\_SIGINFO} gli verrà restituito il
+                             segnale è stato installato con
+                             \const{SA\_SIGINFO} gli verrà restituito il
                              valore specificato con \var{sigev\_value} (una
                              \ctyp{union} \texttt{sigval}, la cui definizione
-                             è in fig.~\ref{fig:sig_sigval}) come valore del
+                             è in fig.~\ref{fig:sig_sigval}) come valore del
                              campo \var{si\_value} di \struct{siginfo\_t}.\\
     \const{SIGEV\_THREAD}  & La notifica viene effettuata creando un nuovo
                              \itindex{thread} \textit{thread} che esegue la
                              funzione di notifica specificata da
                              \var{sigev\_notify\_function} con argomento
-                             \var{sigev\_value}. Se questo è diverso da
+                             \var{sigev\_value}. Se questo è diverso da
                              \val{NULL}, il \textit{thread} viene creato con
                              gli attributi specificati da
                              \var{sigev\_notify\_attribute}.\footnotemark\\
     \const{SIGEV\_THREAD\_ID}& Invia la notifica come segnale (con le stesse
-                             modalità di \const{SIGEV\_SIGNAL}) che però viene
+                             modalità di \const{SIGEV\_SIGNAL}) che però viene
                              recapitato al \textit{thread} indicato dal campo
-                             \var{sigev\_notify\_thread\_id}. Questa modalità
-                             è una estensione specifica di Linux, creata come
+                             \var{sigev\_notify\_thread\_id}. Questa modalità
+                             è una estensione specifica di Linux, creata come
                              supporto per le librerie di gestione dei
                              \textit{thread}, pertanto non deve essere usata
                              da codice normale.\\
@@ -2991,25 +2991,25 @@ effettuata. Diventa cos
   \label{tab:sigevent_sigev_notify}
 \end{table}
 
-\footnotetext{nel caso dei \textit{timer} questa funzionalità è considerata un
+\footnotetext{nel caso dei \textit{timer} questa funzionalità è considerata un
   esempio di pessima implementazione di una interfaccia, richiesta dallo
-  standard POSIX, ma da evitare totalmente, a causa della possibilità di
-  creare disservizi generando una gran quantità di processi, tanto che ne è
+  standard POSIX, ma da evitare totalmente, a causa della possibilità di
+  creare disservizi generando una gran quantità di processi, tanto che ne è
   stata richiesta addirittura la rimozione.}
 
-Nel caso di \func{timer\_create} occorrerà passare alla funzione come secondo
-argomento l'indirizzo di una di queste strutture per indicare le modalità con
+Nel caso di \func{timer\_create} occorrerà passare alla funzione come secondo
+argomento l'indirizzo di una di queste strutture per indicare le modalità con
 cui si vuole essere notificati della scadenza del timer, se non si specifica
-nulla (passando un valore \val{NULL}) verrà inviato il segnale
-\const{SIGALRM} al processo corrente, o per essere più precisi verrà
+nulla (passando un valore \val{NULL}) verrà inviato il segnale
+\const{SIGALRM} al processo corrente, o per essere più precisi verrà
 utilizzato un valore equivalente all'aver specificato \const{SIGEV\_SIGNAL}
 per \var{sigev\_notify}, \const{SIGALRM} per \var{sigev\_signo} e
 l'identificatore del timer come valore per \var{sigev\_value.sival\_int}.
 
 Il terzo argomento deve essere l'indirizzo di una variabile di tipo
-\type{timer\_t} dove sarà scritto l'identificativo associato al timer appena
+\type{timer\_t} dove sarà scritto l'identificativo associato al timer appena
 creato, da usare in tutte le successive funzioni di gestione. Una volta creato
-questo identificativo resterà univoco all'interno del processo stesso fintanto
+questo identificativo resterà univoco all'interno del processo stesso fintanto
 che il timer non viene cancellato.
 
 Si tenga presente che eventuali POSIX timer creati da un processo non vengono
@@ -3019,13 +3019,13 @@ nella esecuzione di un programma diverso attraverso una delle funzioni
 segnale \textit{real-time} per ciascun timer che viene creato con
 \func{timer\_create}; dato che ciascuno di essi richiede un posto nella coda
 dei segnali \textit{real-time}, il numero massimo di timer utilizzabili da un
-processo è limitato dalle dimensioni di detta coda, ed anche, qualora questo
+processo è limitato dalle dimensioni di detta coda, ed anche, qualora questo
 sia stato impostato, dal limite \const{RLIMIT\_SIGPENDING}.
 
 Una volta creato il timer \func{timer\_create} ed ottenuto il relativo
-identificatore, si può attivare o disattivare un allarme (in gergo
+identificatore, si può attivare o disattivare un allarme (in gergo
 \textsl{armare} o \textsl{disarmare} il timer) con la funzione
-\funcd{timer\_settime}, il cui prototipo è:
+\funcd{timer\_settime}, il cui prototipo è:
 \begin{functions}
   \headdecl{signal.h}
   \headdecl{time.h}
@@ -3036,12 +3036,12 @@ identificatore, si pu
   Arma o disarma il timer POSIX.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+    errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] all'interno di \param{new\_value.value} si è
+  \item[\errcode{EINVAL}] all'interno di \param{new\_value.value} si è
     specificato un tempo negativo o un numero di nanosecondi maggiore di
     999999999.
-  \item[\errcode{EFAULT}] si è specificato un indirizzo non valido
+  \item[\errcode{EFAULT}] si è specificato un indirizzo non valido
     per \param{new\_value} o \param{old\_value}.
   \end{errlist}
 }
@@ -3049,9 +3049,9 @@ identificatore, si pu
 
 La funzione richiede che si indichi la scadenza del timer con
 l'argomento \param{new\_value}, che deve essere specificato come puntatore ad
-una struttura di tipo \struct{itimerspec}, la cui definizione è riportata in
-fig.~\ref{fig:struct_itimerspec}; se il puntatore \param{old\_value} è diverso
-da \val{NULL} il valore corrente della scadenza verrà restituito in una
+una struttura di tipo \struct{itimerspec}, la cui definizione è riportata in
+fig.~\ref{fig:struct_itimerspec}; se il puntatore \param{old\_value} è diverso
+da \val{NULL} il valore corrente della scadenza verrà restituito in una
 analoga struttura, ovviamente in entrambi i casi le strutture devono essere
 state allocate.
 
@@ -3068,55 +3068,55 @@ state allocate.
 
 Ciascuno dei due campi di \struct{itimerspec} indica un tempo, da specificare
 con una precisione fino al nanosecondo tramite una struttura \struct{timespec}
-(la cui definizione è riportata fig.~\ref{fig:sys_timespec_struct}). Il campo
+(la cui definizione è riportata fig.~\ref{fig:sys_timespec_struct}). Il campo
 \var{it\_value} indica la prima scadenza dell'allarme. Di default, quando il
-valore di \param{flags} è nullo, questo valore viene considerato come un
-intervallo relativo al tempo corrente,\footnote{il primo allarme scatterà cioè
+valore di \param{flags} è nullo, questo valore viene considerato come un
+intervallo relativo al tempo corrente,\footnote{il primo allarme scatterà cioè
   dopo il numero di secondi e nanosecondi indicati da questo campo.} se invece
 si usa per \param{flags} il valore \const{TIMER\_ABSTIME},\footnote{al momento
-  questo è l'unico valore valido per \param{flags}.} \var{it\_value} viene
+  questo è l'unico valore valido per \param{flags}.} \var{it\_value} viene
 considerato come un valore assoluto rispetto al valore usato dall'orologio a
-cui è associato il timer.\footnote{quindi a seconda dei casi lo si potrà
+cui è associato il timer.\footnote{quindi a seconda dei casi lo si potrà
   indicare o come un tempo assoluto, quando si opera rispetto all'orologio di
   sistema (nel qual caso il valore deve essere in secondi e nanosecondi dalla
   \textit{epoch}) o come numero di secondi o nanosecondi rispetto alla
   partenza di un orologio di CPU, quando si opera su uno di questi.}  Infine
 un valore nullo di \var{it\_value}\footnote{per nullo si intende con valori
-  nulli per entrambi i i campi \var{tv\_sec} e \var{tv\_nsec}.} può essere
+  nulli per entrambi i i campi \var{tv\_sec} e \var{tv\_nsec}.} può essere
 utilizzato, indipendentemente dal tipo di orologio utilizzato, per disarmare
 l'allarme.
 
 Il campo \var{it\_interval} di \struct{itimerspec} viene invece utilizzato per
-impostare un allarme periodico.  Se il suo valore è nullo (se cioè sono nulli
-tutti e due i valori di detta struttura \struct{timespec}) l'allarme scatterà
+impostare un allarme periodico.  Se il suo valore è nullo (se cioè sono nulli
+tutti e due i valori di detta struttura \struct{timespec}) l'allarme scatterà
 una sola volta secondo quando indicato con \var{it\_value}, altrimenti il
-valore specificato verrà preso come l'estensione del periodo di ripetizione
-della generazione dell'allarme, che proseguirà indefinitamente fintanto che
+valore specificato verrà preso come l'estensione del periodo di ripetizione
+della generazione dell'allarme, che proseguirà indefinitamente fintanto che
 non si disarmi il timer.
 
-Se il timer era già stato armato la funzione sovrascrive la precedente
-impostazione, se invece si indica come prima scadenza un tempo già passato,
-l'allarme verrà notificato immediatamente e al contempo verrà incrementato il
+Se il timer era già stato armato la funzione sovrascrive la precedente
+impostazione, se invece si indica come prima scadenza un tempo già passato,
+l'allarme verrà notificato immediatamente e al contempo verrà incrementato il
 contatore dei superamenti. Questo contatore serve a fornire una indicazione al
 programma che riceve l'allarme su un eventuale numero di scadenze che sono
 passate prima della ricezione della notifica dell'allarme. 
 
-É infatti possibile, qualunque sia il meccanismo di notifica scelto, che
-quest'ultima venga ricevuta dopo che il timer è scaduto più di una
+É infatti possibile, qualunque sia il meccanismo di notifica scelto, che
+quest'ultima venga ricevuta dopo che il timer è scaduto più di una
 volta.\footnote{specialmente se si imposta un timer con una ripetizione a
   frequenza elevata.} Nel caso dell'uso di un segnale infatti il sistema mette
 in coda un solo segnale per timer,\footnote{questo indipendentemente che si
   tratti di un segnale ordinario o \textit{real-time}; per questi ultimi
-  sarebbe anche possibile inviare un segnale per ogni scadenza, questo però
+  sarebbe anche possibile inviare un segnale per ogni scadenza, questo però
   non viene fatto per evitare il rischio, tutt'altro che remoto, di riempire
-  la coda.}  e se il sistema è sotto carico o se il segnale è bloccato, prima
-della sua ricezione può passare un intervallo di tempo sufficientemente lungo
-ad avere scadenze multiple, e lo stesso può accadere anche se si usa un
+  la coda.}  e se il sistema è sotto carico o se il segnale è bloccato, prima
+della sua ricezione può passare un intervallo di tempo sufficientemente lungo
+ad avere scadenze multiple, e lo stesso può accadere anche se si usa un
 \textit{thread} di notifica. 
 
-Per questo motivo il gestore del segnale o il \textit{thread} di notifica può
-ottenere una indicazione di quante volte il timer è scaduto dall'invio della
-notifica utilizzando la funzione \funcd{timer\_getoverrun}, il cui prototipo è:
+Per questo motivo il gestore del segnale o il \textit{thread} di notifica può
+ottenere una indicazione di quante volte il timer è scaduto dall'invio della
+notifica utilizzando la funzione \funcd{timer\_getoverrun}, il cui prototipo è:
 \begin{functions}
   \headdecl{time.h}
 
@@ -3125,7 +3125,7 @@ notifica utilizzando la funzione \funcd{timer\_getoverrun}, il cui prototipo 
   Ottiene il numero di scadenze di un timer POSIX.
   
   \bodydesc{La funzione restituisce il numero di scadenze di un timer in caso
-    di successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà
+    di successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà
     il valore:
   \begin{errlist}
   \item[\errcode{EINVAL}] \param{timerid} non indica un timer valido.
@@ -3133,14 +3133,14 @@ notifica utilizzando la funzione \funcd{timer\_getoverrun}, il cui prototipo 
 }
 \end{functions}
 
-La funzione ritorna il numero delle scadenze avvenute, che può anche essere
+La funzione ritorna il numero delle scadenze avvenute, che può anche essere
 nullo se non ve ne sono state. Come estensione specifica di Linux,\footnote{in
-  realtà lo standard POSIX.1-2001 prevede gli \textit{overrun} solo per i
+  realtà lo standard POSIX.1-2001 prevede gli \textit{overrun} solo per i
   segnali e non ne parla affatto in riferimento ai \textit{thread}.}  quando
-si usa un segnale come meccanismo di notifica, si può ottenere direttamente
+si usa un segnale come meccanismo di notifica, si può ottenere direttamente
 questo valore nel campo \var{si\_overrun} della struttura \struct{siginfo\_t}
 (illustrata in fig.~\ref{fig:sig_siginfo_t}) restituita al gestore del segnale
-installato con \func{sigaction}; in questo modo non è più necessario eseguire
+installato con \func{sigaction}; in questo modo non è più necessario eseguire
 successivamente una chiamata a questa funzione per ottenere il numero delle
 scadenze. Al gestore del segnale viene anche restituito, come ulteriore
 informazione, l'identificativo del timer, in questo caso nel campo
@@ -3148,7 +3148,7 @@ informazione, l'identificativo del timer, in questo caso nel campo
 
 Qualora si voglia rileggere lo stato corrente di un timer, ed ottenere il
 tempo mancante ad una sua eventuale scadenza, si deve utilizzare la funzione
-\funcd{timer\_gettime}, il cui prototipo è:
+\funcd{timer\_gettime}, il cui prototipo è:
 \begin{functions}
   \headdecl{time.h}
 
@@ -3158,10 +3158,10 @@ tempo mancante ad una sua eventuale scadenza, si deve utilizzare la funzione
   Legge lo stato di un timer POSIX.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+    errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
   \begin{errlist}
   \item[\errcode{EINVAL}] \param{timerid} non indica un timer valido.
-  \item[\errcode{EFAULT}] si è specificato un indirizzo non valido
+  \item[\errcode{EFAULT}] si è specificato un indirizzo non valido
     per \param{curr\_value}.
   \end{errlist}
 }
@@ -3172,7 +3172,7 @@ da \param{curr\_value} il tempo restante alla prossima scadenza nel campo
 \var{it\_value}. Questo tempo viene sempre indicato in forma relativa, anche
 nei casi in cui il timer era stato precedentemente impostato con
 \const{TIMER\_ABSTIME} indicando un tempo assoluto.  Il ritorno di un valore
-nullo nel campo \var{it\_value} significa che il timer è disarmato o è
+nullo nel campo \var{it\_value} significa che il timer è disarmato o è
 definitivamente scaduto. 
 
 Nel campo \var{it\_interval} di \param{curr\_value} viene invece restituito,
@@ -3181,11 +3181,11 @@ questo caso il ritorno di un valore nullo significa che il timer non era stato
 impostato per una ripetizione e doveva operare, come suol dirsi, a colpo
 singolo (in gergo \textit{one shot}).
 
-Infine, quando un timer non viene più utilizzato, lo si può cancellare,
+Infine, quando un timer non viene più utilizzato, lo si può cancellare,
 rimuovendolo dal sistema e recuperando le relative risorse, effettuando in
 sostanza l'operazione inversa rispetto a \funcd{timer\_create}. Per questo
 compito lo standard prevede una apposita funzione \funcd{timer\_delete}, il
-cui prototipo è:
+cui prototipo è:
 \begin{functions}
   \headdecl{time.h}
 
@@ -3194,7 +3194,7 @@ cui prototipo 
   Cancella un timer POSIX.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+    errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] \param{timerid} non indica un timer valido.
     \end{errlist}
@@ -3204,17 +3204,17 @@ cui prototipo 
 La funzione elimina il timer identificato da \param{timerid}, disarmandolo se
 questo era stato attivato. Nel caso, poco probabile ma comunque possibile, che
 un timer venga cancellato prima della ricezione del segnale pendente per la
-notifica di una scadenza, il comportamento del sistema è indefinito.
+notifica di una scadenza, il comportamento del sistema è indefinito.
 
 \subsection{Ulteriori funzioni di gestione}
 \label{sec:sig_specific_features}
 
 In questo ultimo paragrafo esamineremo le rimanenti funzioni di gestione dei
-segnali non descritte finora, relative agli aspetti meno utilizzati e più
+segnali non descritte finora, relative agli aspetti meno utilizzati e più
 ``\textsl{esoterici}'' della interfaccia.
 
-La prima di queste funzioni è \funcd{sigpending}, anch'essa introdotta dallo
-standard POSIX.1; il suo prototipo è:
+La prima di queste funzioni è \funcd{sigpending}, anch'essa introdotta dallo
+standard POSIX.1; il suo prototipo è:
 \begin{prototype}{signal.h}
 {int sigpending(sigset\_t *set)} 
   
@@ -3225,19 +3225,19 @@ Scrive in \param{set} l'insieme dei segnali pendenti.
 \end{prototype}
 
 La funzione permette di ricavare quali sono i segnali pendenti per il processo
-in corso, cioè i segnali che sono stati inviati dal kernel ma non sono stati
+in corso, cioè i segnali che sono stati inviati dal kernel ma non sono stati
 ancora ricevuti dal processo in quanto bloccati. Non esiste una funzione
-equivalente nella vecchia interfaccia, ma essa è tutto sommato poco utile,
-dato che essa può solo assicurare che un segnale è stato inviato, dato che
+equivalente nella vecchia interfaccia, ma essa è tutto sommato poco utile,
+dato che essa può solo assicurare che un segnale è stato inviato, dato che
 escluderne l'avvenuto invio al momento della chiamata non significa nulla
 rispetto a quanto potrebbe essere in un qualunque momento successivo.
 
-Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità
-di usare uno \itindex{stack} \textit{stack} alternativo per i segnali; è cioè
+Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità
+di usare uno \itindex{stack} \textit{stack} alternativo per i segnali; è cioè
 possibile fare usare al sistema un altro \itindex{stack} \textit{stack}
 (invece di quello relativo al processo, vedi sez.~\ref{sec:proc_mem_layout})
 solo durante l'esecuzione di un gestore.  L'uso di uno \textit{stack}
-alternativo è del tutto trasparente ai gestori, occorre però seguire una certa
+alternativo è del tutto trasparente ai gestori, occorre però seguire una certa
 procedura:
 \begin{enumerate*}
 \item allocare un'area di memoria di dimensione sufficiente da usare come
@@ -3253,36 +3253,36 @@ procedura:
 In genere il primo passo viene effettuato allocando un'opportuna area di
 memoria con \code{malloc}; in \file{signal.h} sono definite due costanti,
 \const{SIGSTKSZ} e \const{MINSIGSTKSZ}, che possono essere utilizzate per
-allocare una quantità di spazio opportuna, in modo da evitare overflow. La
-prima delle due è la dimensione canonica per uno \itindex{stack}
-\textit{stack} di segnali e di norma è sufficiente per tutti gli usi normali.
+allocare una quantità di spazio opportuna, in modo da evitare overflow. La
+prima delle due è la dimensione canonica per uno \itindex{stack}
+\textit{stack} di segnali e di norma è sufficiente per tutti gli usi normali.
 
-La seconda è lo spazio che occorre al sistema per essere in grado di lanciare
+La seconda è lo spazio che occorre al sistema per essere in grado di lanciare
 il gestore e la dimensione di uno \textit{stack} alternativo deve essere
-sempre maggiore di questo valore. Quando si conosce esattamente quanto è lo
-spazio necessario al gestore gli si può aggiungere questo valore per allocare
+sempre maggiore di questo valore. Quando si conosce esattamente quanto è lo
+spazio necessario al gestore gli si può aggiungere questo valore per allocare
 uno \itindex{stack} \textit{stack} di dimensione sufficiente.
 
 Come accennato, per poter essere usato, lo \itindex{stack} \textit{stack} per
 i segnali deve essere indicato al sistema attraverso la funzione
-\funcd{sigaltstack}; il suo prototipo è:
+\funcd{sigaltstack}; il suo prototipo è:
 \begin{prototype}{signal.h}
 {int sigaltstack(const stack\_t *ss, stack\_t *oss)}
   
 Installa un nuovo \textit{stack} per i segnali.
   
   \bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
 
   \begin{errlist}
   \item[\errcode{ENOMEM}] la dimensione specificata per il nuovo
-    \textit{stack} è minore di \const{MINSIGSTKSZ}.
-  \item[\errcode{EPERM}] uno degli indirizzi non è valido.
-  \item[\errcode{EFAULT}] si è cercato di cambiare lo \textit{stack}
-    alternativo mentre questo è attivo (cioè il processo è in esecuzione su di
+    \textit{stack} è minore di \const{MINSIGSTKSZ}.
+  \item[\errcode{EPERM}] uno degli indirizzi non è valido.
+  \item[\errcode{EFAULT}] si è cercato di cambiare lo \textit{stack}
+    alternativo mentre questo è attivo (cioè il processo è in esecuzione su di
     esso).
-  \item[\errcode{EINVAL}] \param{ss} non è nullo e \var{ss\_flags} contiene un
-  valore diverso da zero che non è \const{SS\_DISABLE}.
+  \item[\errcode{EINVAL}] \param{ss} non è nullo e \var{ss\_flags} contiene un
+  valore diverso da zero che non è \const{SS\_DISABLE}.
   \end{errlist}}
 \end{prototype}
 
@@ -3311,11 +3311,11 @@ allocata, mentre \var{ss\_flags} deve essere nullo.  Se invece si vuole
 disabilitare uno \textit{stack} occorre indicare \const{SS\_DISABLE} come
 valore di \var{ss\_flags} e gli altri valori saranno ignorati.
 
-Se \param{oss} non è nullo verrà restituito dalla funzione indirizzo e
+Se \param{oss} non è nullo verrà restituito dalla funzione indirizzo e
 dimensione dello \itindex{stack} \textit{stack} corrente nei relativi campi,
-mentre \var{ss\_flags} potrà assumere il valore \const{SS\_ONSTACK} se il
-processo è in esecuzione sullo \textit{stack} alternativo (nel qual caso non è
-possibile cambiarlo) e \const{SS\_DISABLE} se questo non è abilitato.
+mentre \var{ss\_flags} potrà assumere il valore \const{SS\_ONSTACK} se il
+processo è in esecuzione sullo \textit{stack} alternativo (nel qual caso non è
+possibile cambiarlo) e \const{SS\_DISABLE} se questo non è abilitato.
 
 In genere si installa uno \itindex{stack} \textit{stack} alternativo per i
 segnali quando si teme di avere problemi di esaurimento dello \textit{stack}
@@ -3329,13 +3329,13 @@ Si tenga presente che le funzioni chiamate durante l'esecuzione sullo
 \textit{stack} alternativo continueranno ad usare quest'ultimo, che, al
 contrario di quanto avviene per lo \itindex{stack} \textit{stack} ordinario
 dei processi, non si accresce automaticamente (ed infatti eccederne le
-dimensioni può portare a conseguenze imprevedibili).  Si ricordi infine che
+dimensioni può portare a conseguenze imprevedibili).  Si ricordi infine che
 una chiamata ad una funzione della famiglia \func{exec} cancella ogni
 \textit{stack} alternativo.
 
 Abbiamo visto in fig.~\ref{fig:sig_sleep_incomplete} come si possa usare
 \func{longjmp} per uscire da un gestore rientrando direttamente nel corpo
-del programma; sappiamo però che nell'esecuzione di un gestore il segnale
+del programma; sappiamo però che nell'esecuzione di un gestore il segnale
 che l'ha invocato viene bloccato, e abbiamo detto che possiamo ulteriormente
 modificarlo con \func{sigprocmask}. 
 
@@ -3350,7 +3350,7 @@ Lo standard POSIX.1 non specifica questo comportamento per \func{setjmp} e
 caratteristiche si sono abilitate con le macro viste in
 sez.~\ref{sec:intro_gcc_glibc_std}.
 
-Lo standard POSIX però prevede anche la presenza di altre due funzioni
+Lo standard POSIX però prevede anche la presenza di altre due funzioni
 \funcd{sigsetjmp} e \funcd{siglongjmp}, che permettono di decidere quale dei
 due comportamenti il programma deve assumere; i loro prototipi sono:
 \begin{functions}
@@ -3369,15 +3369,15 @@ due comportamenti il programma deve assumere; i loro prototipi sono:
 
 Le due funzioni prendono come primo argomento la variabile su cui viene
 salvato il contesto dello \itindex{stack} \textit{stack} per permettere il
-\index{salto~non-locale} salto non-locale; nel caso specifico essa è di tipo
+\index{salto~non-locale} salto non-locale; nel caso specifico essa è di tipo
 \type{sigjmp\_buf}, e non \type{jmp\_buf} come per le analoghe di
 sez.~\ref{sec:proc_longjmp} in quanto in questo caso viene salvata anche la
 maschera dei segnali.
 
 Nel caso di \func{sigsetjmp}, se si specifica un valore di \param{savesigs}
-diverso da zero la maschera dei valori sarà salvata in \param{env} e
+diverso da zero la maschera dei valori sarà salvata in \param{env} e
 ripristinata in un successivo \func{siglongjmp}; quest'ultima funzione, a
-parte l'uso di \type{sigjmp\_buf} per \param{env}, è assolutamente identica a
+parte l'uso di \type{sigjmp\_buf} per \param{env}, è assolutamente identica a
 \func{longjmp}.
 
 
diff --git a/sockadv.tex b/sockadv.tex
index e8accfe..81ce591 100644
--- a/sockadv.tex
+++ b/sockadv.tex
@@ -13,7 +13,7 @@
 \label{cha:advanced_socket}
 
 
-Esamineremo in questo capitolo le funzionalità più evolute della gestione dei
+Esamineremo in questo capitolo le funzionalità più evolute della gestione dei
 socket, le funzioni avanzate, la gestione dei dati urgenti e
 \textit{out-of-band} e dei messaggi ancillari, come l'uso come l'uso del I/O
 multiplexing (vedi sez.~\ref{sec:file_multiplexing}) con i socket.
@@ -22,8 +22,8 @@ multiplexing (vedi sez.~\ref{sec:file_multiplexing}) con i socket.
 \section{Le funzioni di I/O avanzate}
 \label{sec:sock_advanced_IO}
 
-Tratteremo in questa sezione le funzioni di I/O più avanzate che permettono di
-controllare le funzionalità specifiche della comunicazione dei dati che sono
+Tratteremo in questa sezione le funzioni di I/O più avanzate che permettono di
+controllare le funzionalità specifiche della comunicazione dei dati che sono
 disponibili con i vari tipi di socket.
 
 
@@ -40,10 +40,10 @@ socket in forma semplificata. Se infatti si devono semplicemente ...
 \subsection{I messaggi ancillari}
 \label{sec:net_ancillary_data}
 
-Quanto è stata attivata l'opzione \const{IP\_RECVERR} il kernel attiva per il
+Quanto è stata attivata l'opzione \const{IP\_RECVERR} il kernel attiva per il
 socket una speciale coda su cui vengono inviati tutti gli errori riscontrati.
 Questi possono essere riletti usando il flag \const{MSG\_ERRQUEUE}, nel qual
-caso sarà passato come messaggio ancillare una struttura di tipo
+caso sarà passato come messaggio ancillare una struttura di tipo
 \struct{sock\_extended\_err} illustrata in
 fig.~\ref{fig:sock_extended_err_struct}.
 
@@ -67,38 +67,38 @@ fig.~\ref{fig:sock_extended_err_struct}.
 
 \itindbeg{out-of-band} 
 
-Una caratteristica particolare dei socket TCP è quella che consente di inviare
+Una caratteristica particolare dei socket TCP è quella che consente di inviare
 all'altro capo della comunicazione una sorta di messaggio privilegiato, che si
 richiede che sia trattato il prima possibile. Si fa riferimento a questa
-funzionalità come all'invio dei cosiddetti \textsl{dati urgenti} (o
+funzionalità come all'invio dei cosiddetti \textsl{dati urgenti} (o
 \textit{urgent data}); talvolta essi chiamati anche dati \textit{out-of-band}
-poiché, come vedremo più avanti, possono essere letti anche al di fuori del
+poiché, come vedremo più avanti, possono essere letti anche al di fuori del
 flusso di dati normale.
 
-Come già accennato in sez.~\ref{sec:file_multiplexing} la presenza di dati
+Come già accennato in sez.~\ref{sec:file_multiplexing} la presenza di dati
 urgenti viene rilevata in maniera specifica sia di \func{select} (con il
 \itindex{file~descriptor~set} \textit{file descriptor set} \param{exceptfds})
 che da \func{poll} (con la condizione \const{POLLRDBAND}).
 
 
-Le modalità di lettura dei dati urgenti sono due, la prima e più comune
+Le modalità di lettura dei dati urgenti sono due, la prima e più comune
 prevede l'uso di \func{recvmsg} con 
 
 
 % TODO aggiungere pezzo di codice per inviare dati urgenti all'echo server
 
-La seconda modalità di lettura prevede invece l'uso dell'opzione dei socket
+La seconda modalità di lettura prevede invece l'uso dell'opzione dei socket
 \const{SO\_OOBINLINE} (vedi sez.~\ref{sec:sock_generic_options}) che consente
 di ricevere i dati urgenti direttamente nel flusso dei dati del socket; in tal
-caso però si pone il problema di come distinguere i dati normali da quelli
-urgenti. Come già accennato in sez.~\ref{sec:sock_ioctl_IP} a questo scopo si
-può usare \func{ioctl} con l'operazione \const{SIOCATMARK}, che consente di
-sapere se si è arrivati o meno all'\textit{urgent mark}. 
+caso però si pone il problema di come distinguere i dati normali da quelli
+urgenti. Come già accennato in sez.~\ref{sec:sock_ioctl_IP} a questo scopo si
+può usare \func{ioctl} con l'operazione \const{SIOCATMARK}, che consente di
+sapere se si è arrivati o meno all'\textit{urgent mark}. 
 
 La procedura allora prevede che, una volta che si sia rilevata la presenza di
 dati urgenti, si ripeta la lettura ordinaria dal socket fintanto che
 \const{SIOCATMARK} non restituisce un valore diverso da zero; la successiva
-lettura restituirà i dati urgenti.
+lettura restituirà i dati urgenti.
 
 
 \itindend{out-of-band} 
@@ -107,7 +107,7 @@ lettura restituir
 \section{L'uso dell'I/O non bloccante}
 \label{sec:sock_noblok_IO}
 
-Tratteremo in questa sezione le modalità avanzate che permettono di utilizzare
+Tratteremo in questa sezione le modalità avanzate che permettono di utilizzare
 i socket con una comunicazione non bloccante, in modo da 
 
 
@@ -120,7 +120,7 @@ i socket con una comunicazione non bloccante, in modo da
 Abbiamo visto in sez.~\ref{sec:sock_ipv4_options} come di possa usare  
 \func{setsockopt} con l'opzione \const{IP\_OPTIONS} per impostare le opzioni  
 IP associate per i pacchetti associati ad un socket.  Vedremo qui il
-significato di tali opzioni e le modalità con cui esse possono essere
+significato di tali opzioni e le modalità con cui esse possono essere
 utilizzate ed impostate.
 
 % LocalWords:  socket of multiplexing sez sendmsg recvmsg RECVERR kernel MSG
diff --git a/sockctrl.tex b/sockctrl.tex
index 09d0250..9e09813 100644
--- a/sockctrl.tex
+++ b/sockctrl.tex
@@ -12,9 +12,9 @@
 \chapter{La gestione dei socket}
 \label{cha:sock_generic_management}
 
-Esamineremo in questo capitolo una serie di funzionalità aggiuntive relative
+Esamineremo in questo capitolo una serie di funzionalità aggiuntive relative
 alla gestione dei socket, come la gestione della risoluzione di nomi e
-indirizzi, le impostazioni delle varie proprietà ed opzioni relative ai
+indirizzi, le impostazioni delle varie proprietà ed opzioni relative ai
 socket, e le funzioni di controllo che permettono di modificarne il
 comportamento.
 
@@ -23,27 +23,27 @@ comportamento.
 \label{sec:sock_name_resolution}
 
 Negli esempi dei capitoli precedenti abbiamo sempre identificato le singole
-macchine attraverso indirizzi numerici, sfruttando al più le funzioni di
+macchine attraverso indirizzi numerici, sfruttando al più le funzioni di
 conversione elementare illustrate in sez.~\ref{sec:sock_addr_func} che
 permettono di passare da un indirizzo espresso in forma \textit{dotted
   decimal} ad un numero. Vedremo in questa sezione le funzioni utilizzate per
 poter utilizzare dei nomi simbolici al posto dei valori numerici, e viceversa
 quelle che permettono di ottenere i nomi simbolici associati ad indirizzi,
-porte o altre proprietà del sistema.
+porte o altre proprietà del sistema.
 
 
 \subsection{La struttura del \textit{resolver}}
 \label{sec:sock_resolver}
 
 \itindbeg{resolver}
-La risoluzione dei nomi è associata tradizionalmente al servizio del
+La risoluzione dei nomi è associata tradizionalmente al servizio del
 \textit{Domain Name Service} che permette di identificare le macchine su
 internet invece che per numero IP attraverso il relativo \textsl{nome a
   dominio}.\footnote{non staremo ad entrare nei dettagli della definizione di
-  cosa è un nome a dominio, dandolo per noto, una introduzione alla
+  cosa è un nome a dominio, dandolo per noto, una introduzione alla
   problematica si trova in \cite{AGL} (cap.~9) mentre per una trattazione
-  approfondita di tutte le problematiche relative al DNS si può fare
-  riferimento a \cite{DNSbind}.} In realtà per DNS si intendono spesso i
+  approfondita di tutte le problematiche relative al DNS si può fare
+  riferimento a \cite{DNSbind}.} In realtà per DNS si intendono spesso i
 server che forniscono su internet questo servizio, mentre nel nostro caso
 affronteremo la problematica dal lato client, di un qualunque programma che
 necessita di compiere questa operazione.
@@ -55,63 +55,63 @@ necessita di compiere questa operazione.
   \label{fig:sock_resolver_schema}
 \end{figure}
 
-Inoltre quella fra nomi a dominio e indirizzi IP non è l'unica corrispondenza
+Inoltre quella fra nomi a dominio e indirizzi IP non è l'unica corrispondenza
 possibile fra nomi simbolici e valori numerici, come abbiamo visto anche in
 sez.~\ref{sec:sys_user_group} per le corrispondenze fra nomi di utenti e
-gruppi e relativi identificatori numerici; per quanto riguarda però tutti i
+gruppi e relativi identificatori numerici; per quanto riguarda però tutti i
 nomi associati a identificativi o servizi relativi alla rete il servizio di
-risoluzione è gestito in maniera unificata da un insieme di funzioni fornite
+risoluzione è gestito in maniera unificata da un insieme di funzioni fornite
 con le librerie del C, detto appunto \textit{resolver}.
 
-Lo schema di funzionamento del \textit{resolver} è illustrato in
+Lo schema di funzionamento del \textit{resolver} è illustrato in
 fig.~\ref{fig:sock_resolver_schema}; in sostanza i programmi hanno a
 disposizione un insieme di funzioni di libreria con cui chiamano il
-\textit{resolver}, indicate con le frecce nere. Ricevuta la richiesta è
+\textit{resolver}, indicate con le frecce nere. Ricevuta la richiesta è
 quest'ultimo che, sulla base della sua configurazione, esegue le operazioni
 necessarie a fornire la risposta, che possono essere la lettura delle
 informazioni mantenute nei relativi dei file statici presenti sulla macchina,
 una interrogazione ad un DNS (che a sua volta, per il funzionamento del
-protocollo, può interrogarne altri) o la richiesta ad altri server per i quali
+protocollo, può interrogarne altri) o la richiesta ad altri server per i quali
 sia fornito il supporto, come LDAP.\footnote{la sigla LDAP fa riferimento ad
   un protocollo, il \textit{Lightweight Directory Access Protocol}, che
   prevede un meccanismo per la gestione di \textsl{elenchi} di informazioni
-  via rete; il contenuto di un elenco può essere assolutamente generico, e
-  questo permette il mantenimento dei più vari tipi di informazioni su una
+  via rete; il contenuto di un elenco può essere assolutamente generico, e
+  questo permette il mantenimento dei più vari tipi di informazioni su una
   infrastruttura di questo tipo.}
 
-La configurazione del \textit{resolver} attiene più alla amministrazione di
-sistema che alla programmazione, ciò non di meno, prima di trattare le varie
+La configurazione del \textit{resolver} attiene più alla amministrazione di
+sistema che alla programmazione, ciò non di meno, prima di trattare le varie
 funzioni di librerie utilizzate dai programmi, vale la pena fare una
 panoramica generale.  Originariamente la configurazione del \textit{resolver}
 riguardava esclusivamente le questioni relative alla gestione dei nomi a
 dominio, e prevedeva solo l'utilizzo del DNS e del file statico
 \conffile{/etc/hosts}.
 
-Per questo aspetto il file di configurazione principale del sistema è
+Per questo aspetto il file di configurazione principale del sistema è
 \conffile{/etc/resolv.conf} che contiene in sostanza l'elenco degli indirizzi
 IP dei server DNS da contattare; a questo si affianca il file
-\conffile{/etc/host.conf} il cui scopo principale è indicare l'ordine in cui
+\conffile{/etc/host.conf} il cui scopo principale è indicare l'ordine in cui
 eseguire la risoluzione dei nomi (se usare prima i valori di
 \conffile{/etc/hosts} o quelli del DNS). Tralasciamo i dettagli relativi alle
 varie direttive che possono essere usate in questi file, che si trovano nelle
 rispettive pagine di manuale.
 
-Con il tempo però è divenuto possibile fornire diversi sostituti per
+Con il tempo però è divenuto possibile fornire diversi sostituti per
 l'utilizzo delle associazione statiche in \conffile{/etc/hosts}, inoltre oltre
 alla risoluzione dei nomi a dominio ci sono anche altri nomi da risolvere,
 come quelli che possono essere associati ad una rete (invece che ad una
 singola macchina) o ai gruppi di macchine definiti dal servizio
-NIS,\footnote{il \textit{Network Information Service} è un servizio, creato da
+NIS,\footnote{il \textit{Network Information Service} è un servizio, creato da
   Sun, e poi diffuso su tutte le piattaforme unix-like, che permette di
   raggruppare all'interno di una rete (in quelli che appunto vengono chiamati
   \textit{netgroup}) varie macchine, centralizzando i servizi di definizione
-  di utenti e gruppi e di autenticazione, oggi è sempre più spesso sostituito
+  di utenti e gruppi e di autenticazione, oggi è sempre più spesso sostituito
   da LDAP.} o come quelli dei protocolli e dei servizi che sono mantenuti nei
 file statici \conffile{/etc/protocols} e \conffile{/etc/services}.  Molte di
-queste informazioni non si trovano su un DNS, ma in una rete locale può essere
+queste informazioni non si trovano su un DNS, ma in una rete locale può essere
 molto utile centralizzare il mantenimento di alcune di esse su opportuni
 server.  Inoltre l'uso di diversi supporti possibili per le stesse
-informazioni (ad esempio il nome delle macchine può essere mantenuto sia
+informazioni (ad esempio il nome delle macchine può essere mantenuto sia
 tramite \conffile{/etc/hosts}, che con il DNS, che con NIS) comporta il
 problema dell'ordine in cui questi vengono interrogati.\footnote{con le
   implementazioni classiche i vari supporti erano introdotti modificando
@@ -121,15 +121,15 @@ problema dell'ordine in cui questi vengono interrogati.\footnote{con le
 
 \itindbeg{Name~Service~Switch}
 Per risolvere questa serie di problemi la risoluzione dei nomi a dominio
-eseguirà dal \textit{resolver} è stata inclusa all'interno di un meccanismo
+eseguirà dal \textit{resolver} è stata inclusa all'interno di un meccanismo
 generico per la risoluzione di corrispondenze fra nomi ed informazioni ad essi
-associate chiamato \textit{Name Service Switch}\footnote{il sistema è stato
+associate chiamato \textit{Name Service Switch}\footnote{il sistema è stato
   introdotto la prima volta nelle librerie standard di Solaris, le \acr{glibc}
   hanno ripreso lo stesso schema, si tenga presente che questo sistema non
   esiste per altre librerie standard come le \acr{libc5} o le \acr{uclib}.}
 cui abbiamo accennato anche in sez.~\ref{sec:sys_user_group} per quanto
 riguarda la gestione dei dati associati a utenti e gruppi.  Il \textit{Name
-  Service Switch} (cui spesso si fa riferimento con l'acronimo NSS) è un
+  Service Switch} (cui spesso si fa riferimento con l'acronimo NSS) è un
 sistema di librerie dinamiche che permette di definire in maniera generica sia
 i supporti su cui mantenere i dati di corrispondenza fra nomi e valori
 numerici, sia l'ordine in cui effettuare le ricerche sui vari supporti
@@ -146,10 +146,10 @@ tab.~\ref{tab:sys_NSS_classes}.
     \hline
     \hline
     \texttt{passwd}   & Corrispondenze fra nome dell'utente e relative
-                        proprietà (\acr{uid}, gruppo principale, ecc.).\\  
+                        proprietà (\acr{uid}, gruppo principale, ecc.).\\  
     \texttt{shadow}   & Corrispondenze fra username e password dell'utente
                         (e altre informazioni relative alle password).\\  
-    \texttt{group}    & Corrispondenze fra nome del gruppo e proprietà dello 
+    \texttt{group}    & Corrispondenze fra nome del gruppo e proprietà dello 
                         stesso.\\  
     \texttt{aliases}  & Alias per la posta elettronica.\\ 
     \texttt{ethers}   & Corrispondenze fra numero IP e MAC address della
@@ -176,7 +176,7 @@ tab.~\ref{tab:sys_NSS_classes}.
 
 % TODO rivedere meglio la tabella
 
-Il sistema del \textit{Name Service Switch} è controllato dal contenuto del
+Il sistema del \textit{Name Service Switch} è controllato dal contenuto del
 file \conffile{/etc/nsswitch.conf}; questo contiene una riga\footnote{seguendo
   una convezione comune per i file di configurazione le righe vuote vengono
   ignorate e tutto quello che segue un carattere ``\texttt{\#}'' viene
@@ -186,19 +186,19 @@ carattere ``\texttt{:}'' e prosegue con la lista dei \textsl{servizi} su cui
 le relative informazioni sono raggiungibili, scritti nell'ordine in cui si
 vuole siano interrogati.
 
-Ogni servizio è specificato a sua volta da un nome, come \texttt{file},
+Ogni servizio è specificato a sua volta da un nome, come \texttt{file},
 \texttt{dns}, \texttt{db}, ecc.  che identifica la libreria dinamica che
-realizza l'interfaccia con esso. Per ciascun servizio se \texttt{NAME} è il
-nome utilizzato dentro \conffile{/etc/nsswitch.conf}, dovrà essere presente
+realizza l'interfaccia con esso. Per ciascun servizio se \texttt{NAME} è il
+nome utilizzato dentro \conffile{/etc/nsswitch.conf}, dovrà essere presente
 (usualmente in \file{/lib}) una libreria \texttt{libnss\_NAME} che ne
 implementa le funzioni.
 
-In ogni caso, qualunque sia la modalità con cui ricevono i dati o il supporto
-su cui vengono mantenuti, e che si usino o meno funzionalità aggiuntive
+In ogni caso, qualunque sia la modalità con cui ricevono i dati o il supporto
+su cui vengono mantenuti, e che si usino o meno funzionalità aggiuntive
 fornire dal sistema del \textit{Name Service Switch}, dal punto di vista di un
 programma che deve effettuare la risoluzione di un nome a dominio, tutto
 quello che conta sono le funzioni classiche che il \textit{resolver} mette a
-disposizione,\footnote{è cura della implementazione fattane nelle \acr{glibc}
+disposizione,\footnote{è cura della implementazione fattane nelle \acr{glibc}
   tenere conto della presenza del \textit{Name Service Switch}.} e sono queste
 quelle che tratteremo nelle sezioni successive.
 \itindend{Name~Service~Switch}
@@ -208,16 +208,16 @@ quelle che tratteremo nelle sezioni successive.
 \label{sec:sock_resolver_functions}
 
 Prima di trattare le funzioni usate normalmente nella risoluzione dei nomi a
-dominio conviene trattare in maniera più dettagliata il meccanismo principale
-da esse utilizzato e cioè quello del servizio DNS. Come accennato questo,
-benché in teoria sia solo uno dei possibili supporti su cui mantenere le
+dominio conviene trattare in maniera più dettagliata il meccanismo principale
+da esse utilizzato e cioè quello del servizio DNS. Come accennato questo,
+benché in teoria sia solo uno dei possibili supporti su cui mantenere le
 informazioni, in pratica costituisce il meccanismo principale con cui vengono
 risolti i nomi a dominio.  Per questo motivo esistono una serie di funzioni di
 libreria che servono specificamente ad eseguire delle interrogazioni verso un
 server DNS, funzioni che poi vengono utilizzate per realizzare le funzioni
 generiche di libreria usate anche dal sistema del \textit{resolver}.
 
-Il sistema del DNS è in sostanza di un database distribuito organizzato in
+Il sistema del DNS è in sostanza di un database distribuito organizzato in
 maniera gerarchica, i dati vengono mantenuti in tanti server distinti ciascuno
 dei quali si occupa della risoluzione del proprio \textsl{dominio}; i nomi a
 dominio sono organizzati in una struttura ad albero analoga a quella
@@ -225,35 +225,35 @@ dell'albero dei file, con domini di primo livello (come i \texttt{.org}),
 secondo livello (come \texttt{.truelite.it}), ecc.  In questo caso le
 separazioni sono fra i vari livelli sono definite dal carattere ``\texttt{.}''
 ed i nomi devono essere risolti da destra verso sinistra.\footnote{per chi si
-  stia chiedendo quale sia la radice di questo albero, cioè l'equivalente di
-  ``\texttt{/}'', la risposta è il dominio speciale ``\texttt{.}'', che in
+  stia chiedendo quale sia la radice di questo albero, cioè l'equivalente di
+  ``\texttt{/}'', la risposta è il dominio speciale ``\texttt{.}'', che in
   genere non viene mai scritto esplicitamente, ma che, come chiunque abbia
-  configurato un server DNS sa bene, esiste ed è gestito dai cosiddetti
+  configurato un server DNS sa bene, esiste ed è gestito dai cosiddetti
   \textit{root DNS} che risolvono i domini di primo livello.} Il meccanismo
 funziona con il criterio della \textsl{delegazione}, un server responsabile
-per un dominio di primo livello può delegare la risoluzione degli indirizzi
+per un dominio di primo livello può delegare la risoluzione degli indirizzi
 per un suo dominio di secondo livello ad un altro server, il quale a sua volta
-potrà delegare la risoluzione di un eventuale sotto-dominio di terzo livello ad
+potrà delegare la risoluzione di un eventuale sotto-dominio di terzo livello ad
 un altro server ancora.
 
-In realtà un server DNS è in grado di fare altro rispetto alla risoluzione di
+In realtà un server DNS è in grado di fare altro rispetto alla risoluzione di
 un nome a dominio in un indirizzo IP; ciascuna voce nel database viene
-chiamata \textit{resource record}, e può contenere diverse informazioni. In
+chiamata \textit{resource record}, e può contenere diverse informazioni. In
 genere i \textit{resource record} vengono classificati per la \textsl{classe
   di indirizzi} cui i dati contenuti fanno riferimento, e per il \textsl{tipo}
 di questi ultimi.\footnote{ritroveremo classi di indirizzi e tipi di record
-  più avanti in tab.~\ref{tab:DNS_address_class} e
+  più avanti in tab.~\ref{tab:DNS_address_class} e
   tab.~\ref{tab:DNS_record_type}.}  Oggigiorno i dati mantenuti nei server DNS
 sono quasi esclusivamente relativi ad indirizzi internet, per cui in pratica
 viene utilizzata soltanto una classe di indirizzi; invece le corrispondenze
 fra un nome a dominio ed un indirizzo IP sono solo uno fra i vari tipi di
 informazione che un server DNS fornisce normalmente.
 
-L'esistenza di vari tipi di informazioni è un altro dei motivi per cui il
+L'esistenza di vari tipi di informazioni è un altro dei motivi per cui il
 \textit{resolver} prevede, rispetto a quelle relative alla semplice
 risoluzione dei nomi, un insieme di funzioni specifiche dedicate
-all'interrogazione di un server DNS; la prima di queste funzioni è
-\funcd{res\_init}, il cui prototipo è:
+all'interrogazione di un server DNS; la prima di queste funzioni è
+\funcd{res\_init}, il cui prototipo è:
 \begin{functions}
   \headdecl{netinet/in.h} \headdecl{arpa/nameser.h} \headdecl{resolv.h}
   \funcdecl{int res\_init(void)}
@@ -264,19 +264,19 @@ Inizializza il sistema del \textit{resolver}.
   errore.}
 \end{functions}
 
-La funzione legge il contenuto dei file di configurazione (i già citati
+La funzione legge il contenuto dei file di configurazione (i già citati
 \file{resolv.conf} e \file{host.conf}) per impostare il dominio di default,
 gli indirizzi dei server DNS da contattare e l'ordine delle ricerche; se non
-sono specificati server verrà utilizzato l'indirizzo locale, e se non è
-definito un dominio di default sarà usato quello associato con l'indirizzo
-locale (ma questo può essere sovrascritto con l'uso della variabile di
-ambiente \texttt{LOCALDOMAIN}). In genere non è necessario eseguire questa
+sono specificati server verrà utilizzato l'indirizzo locale, e se non è
+definito un dominio di default sarà usato quello associato con l'indirizzo
+locale (ma questo può essere sovrascritto con l'uso della variabile di
+ambiente \texttt{LOCALDOMAIN}). In genere non è necessario eseguire questa
 funzione direttamente in quanto viene automaticamente chiamata la prima volta
 che si esegue una delle altre.
 
 Le impostazioni e lo stato del \textit{resolver} vengono mantenuti in una
 serie di variabili raggruppate nei campi di una apposita struttura \var{\_res}
-usata da tutte queste funzioni. Essa viene definita in \file{resolv.h} ed è
+usata da tutte queste funzioni. Essa viene definita in \file{resolv.h} ed è
 utilizzata internamente alle funzioni essendo definita come variabile globale;
 questo consente anche di accedervi direttamente all'interno di un qualunque
 programma, una volta che la sia opportunamente dichiarata come:
@@ -284,8 +284,8 @@ programma, una volta che la sia opportunamente dichiarata come:
 
 Tutti i campi della struttura sono ad uso interno, e vengono usualmente
 inizializzati da \func{res\_init} in base al contenuto dei file di
-configurazione e ad una serie di valori di default. L'unico campo che può
-essere utile modificare è \var{\_res.options}, una maschera binaria che
+configurazione e ad una serie di valori di default. L'unico campo che può
+essere utile modificare è \var{\_res.options}, una maschera binaria che
 contiene una serie di bit di opzione che permettono di controllare il
 comportamento del \textit{resolver}. 
 
@@ -297,7 +297,7 @@ comportamento del \textit{resolver}.
     \textbf{Costante} & \textbf{Significato} \\
     \hline
     \hline
-    \const{RES\_INIT}       & Viene attivato se è stata chiamata
+    \const{RES\_INIT}       & Viene attivato se è stata chiamata
                               \func{res\_init}. \\
     \const{RES\_DEBUG}      & Stampa dei messaggi di debug.\\
     \const{RES\_AAONLY}     & Accetta solo risposte autoritative.\\
@@ -311,7 +311,7 @@ comportamento del \textit{resolver}.
                               eseguire una interrogazione ricorsiva.\\
     \const{RES\_DEFNAMES}   & Se attivo \func{res\_search} aggiunge il nome
                               del dominio di default ai nomi singoli (che non
-                              contengono cioè un ``\texttt{.}'').\\
+                              contengono cioè un ``\texttt{.}'').\\
     \const{RES\_STAYOPEN}   & Usato con \const{RES\_USEVC} per mantenere
                               aperte le connessioni TCP fra interrogazioni
                               diverse. \\
@@ -340,37 +340,37 @@ comportamento del \textit{resolver}.
   \label{tab:resolver_option}
 \end{table}
 
-Per utilizzare questa funzionalità per modificare le impostazioni direttamente
-da programma occorrerà impostare un opportuno valore per questo campo ed
+Per utilizzare questa funzionalità per modificare le impostazioni direttamente
+da programma occorrerà impostare un opportuno valore per questo campo ed
 invocare esplicitamente \func{res\_init}, dopo di che le altre funzioni
 prenderanno le nuove impostazioni. Le costanti che definiscono i vari bit di
 questo campo, ed il relativo significato sono illustrate in
 tab.~\ref{tab:resolver_option}; trattandosi di una maschera binaria un valore
 deve essere espresso con un opportuno OR aritmetico di dette costanti; ad
 esempio il valore di default delle opzioni, espresso dalla costante
-\const{RES\_DEFAULT}, è definito come:
+\const{RES\_DEFAULT}, è definito come:
 \includecodesnip{listati/resolv_option_def.c}
 
-Non tratteremo il significato degli altri campi non essendovi necessità di
+Non tratteremo il significato degli altri campi non essendovi necessità di
 modificarli direttamente; gran parte di essi sono infatti impostati dal
-contenuto dei file di configurazione, mentre le funzionalità controllate da
+contenuto dei file di configurazione, mentre le funzionalità controllate da
 alcuni di esse possono essere modificate con l'uso delle opportune variabili
 di ambiente come abbiamo visto per \texttt{LOCALDOMAIN}. In particolare con
 \texttt{RES\_RETRY} si soprassiede il valore del campo \var{retry} che
 controlla quante volte viene ripetuto il tentativo di connettersi ad un server
-DNS prima di dichiarare fallimento; il valore di default è 4, un valore nullo
+DNS prima di dichiarare fallimento; il valore di default è 4, un valore nullo
 significa bloccare l'uso del DNS. Infine con \texttt{RES\_TIMEOUT} si
 soprassiede il valore del campo \var{retrans},\footnote{preimpostato al valore
-  della omonima costante \const{RES\_TIMEOUT} di \file{resolv.h}.} che è il
+  della omonima costante \const{RES\_TIMEOUT} di \file{resolv.h}.} che è il
 valore preso come base (in numero di secondi) per definire la scadenza di una
 richiesta, ciascun tentativo di richiesta fallito viene ripetuto raddoppiando
 il tempo di scadenza per il numero massimo di volte stabilito da
 \texttt{RES\_RETRY}.
 
-La funzione di interrogazione principale è \funcd{res\_query}, che serve ad
+La funzione di interrogazione principale è \funcd{res\_query}, che serve ad
 eseguire una richiesta ad un server DNS per un nome a dominio
 \textsl{completamente specificato} (quello che si chiama FQDN, \textit{Fully
-  Qualified Domain Name}); il suo prototipo è:
+  Qualified Domain Name}); il suo prototipo è:
 
 \begin{functions}
 \headdecl{netinet/in.h}
@@ -390,15 +390,15 @@ La funzione esegue una interrogazione ad un server DNS relativa al nome da
 risolvere passato nella stringa indirizzata da \param{dname}, inoltre deve
 essere specificata la classe di indirizzi in cui eseguire la ricerca con
 \param{class}, ed il tipo di \textit{resource record} che si vuole ottenere
-con \param{type}. Il risultato della ricerca verrà scritto nel buffer di
-lunghezza \param{anslen} puntato da \param{answer} che si sarà opportunamente
+con \param{type}. Il risultato della ricerca verrà scritto nel buffer di
+lunghezza \param{anslen} puntato da \param{answer} che si sarà opportunamente
 allocato in precedenza.
 
 
 Una seconda funzione di ricerca, analoga a \func{res\_query}, che prende gli
-stessi argomenti, ma che esegue l'interrogazione con le funzionalità
+stessi argomenti, ma che esegue l'interrogazione con le funzionalità
 addizionali previste dalle due opzioni \const{RES\_DEFNAMES} e
-\const{RES\_DNSRCH}, è \funcd{res\_search}, il cui prototipo è:
+\const{RES\_DNSRCH}, è \funcd{res\_search}, il cui prototipo è:
 \begin{functions}
 \headdecl{netinet/in.h}
 \headdecl{arpa/nameser.h}
@@ -416,19 +416,19 @@ addizionali previste dalle due opzioni \const{RES\_DEFNAMES} e
 In sostanza la funzione ripete una serie di chiamate a \func{res\_query}
 aggiungendo al nome contenuto nella stringa \param{dname} il dominio di
 default da cercare, fermandosi non appena trova un risultato.  Il risultato di
-entrambe le funzioni viene scritto nel formato opportuno (che sarà diverso a
-seconda del tipo di record richiesto) nel buffer di ritorno; sarà compito del
+entrambe le funzioni viene scritto nel formato opportuno (che sarà diverso a
+seconda del tipo di record richiesto) nel buffer di ritorno; sarà compito del
 programma (o di altre funzioni) estrarre i relativi dati, esistono una serie
 di funzioni interne usate per la scansione di questi dati, per chi fosse
-interessato una trattazione dettagliata è riportata nel quattordicesimo
+interessato una trattazione dettagliata è riportata nel quattordicesimo
 capitolo di \cite{DNSbind}.
 
 Le classi di indirizzi supportate da un server DNS sono tre, ma di queste in
 pratica oggi viene utilizzata soltanto quella degli indirizzi internet; le
 costanti che identificano dette classi, da usare come valore per l'argomento
 \param{class} delle precedenti funzioni, sono riportate in
-tab.~\ref{tab:DNS_address_class}.\footnote{esisteva in realtà anche una classe
-  \const{C\_CSNET} per la omonima rete, ma è stata dichiarata obsoleta.}
+tab.~\ref{tab:DNS_address_class}.\footnote{esisteva in realtà anche una classe
+  \const{C\_CSNET} per la omonima rete, ma è stata dichiarata obsoleta.}
 
 \begin{table}[htb]
   \centering
@@ -456,15 +456,15 @@ diverse, ed a ciascuna di essa corrisponde un diverso tipo di \textit{resource
   record}. L'elenco delle costanti\footnote{ripreso dai file di dichiarazione
   \file{arpa/nameser.h} e \file{arpa/nameser\_compat.h}.} che definiscono i
 valori che si possono usare per l'argomento \param{type} per specificare il
-tipo di \textit{resource record} da richiedere è riportato in
+tipo di \textit{resource record} da richiedere è riportato in
 tab.~\ref{tab:DNS_record_type}; le costanti (tolto il \texttt{T\_} iniziale)
 hanno gli stessi nomi usati per identificare i record nei file di zona di
-BIND,\footnote{BIND, acronimo di \textit{Berkley Internet Name Domain}, è una
+BIND,\footnote{BIND, acronimo di \textit{Berkley Internet Name Domain}, è una
   implementazione di un server DNS, ed, essendo utilizzata nella stragrande
   maggioranza dei casi, fa da riferimento; i dati relativi ad un certo
-  dominio (cioè i suoi \textit{resource record} vengono mantenuti in quelli
+  dominio (cioè i suoi \textit{resource record} vengono mantenuti in quelli
   che sono usualmente chiamati \textsl{file di zona}, e in essi ciascun tipo
-  di dominio è identificato da un nome che è appunto identico a quello delle
+  di dominio è identificato da un nome che è appunto identico a quello delle
   costanti di tab.~\ref{tab:DNS_record_type} senza il \texttt{T\_} iniziale.}
 e che normalmente sono anche usati come nomi per indicare i record.
 
@@ -481,7 +481,7 @@ e che normalmente sono anche usati come nomi per indicare i record.
     \const{T\_MD}    & Destinazione per la posta elettronica.\\
     \const{T\_MF}    & Redistributore per la posta elettronica.\\
     \const{T\_CNAME} & Nome canonico.\\
-    \const{T\_SOA}   & Inizio di una zona di autorità.\\
+    \const{T\_SOA}   & Inizio di una zona di autorità.\\
     \const{T\_MB}    & Nome a dominio di una casella di posta.\\
     \const{T\_MG}    & Nome di un membro di un gruppo di posta.\\
     \const{T\_MR}    & Nome di un cambiamento di nome per la posta.\\
@@ -513,7 +513,7 @@ e che normalmente sono anche usati come nomi per indicare i record.
     \const{T\_NAPTR} & Puntatore ad una \textit{naming authority}.\\
     \const{T\_TSIG}  & Firma di transazione.\\
     \const{T\_IXFR}  & Trasferimento di zona incrementale.\\
-    \const{T\_AXFR}  & Trasferimento di zona di autorità.\\
+    \const{T\_AXFR}  & Trasferimento di zona di autorità.\\
     \const{T\_MAILB} & Trasferimento di record di caselle di posta.\\
     \const{T\_MAILA} & Trasferimento di record di server di posta.\\
     \const{T\_ANY}   & Valore generico.\\
@@ -525,49 +525,49 @@ e che normalmente sono anche usati come nomi per indicare i record.
 \end{table}
 
 
-L'elenco di tab.~\ref{tab:DNS_record_type} è quello di \textsl{tutti} i
+L'elenco di tab.~\ref{tab:DNS_record_type} è quello di \textsl{tutti} i
 \textit{resource record} definiti, con una breve descrizione del relativo
-significato.  Di tutti questi però viene impiegato correntemente solo un
+significato.  Di tutti questi però viene impiegato correntemente solo un
 piccolo sottoinsieme, alcuni sono obsoleti ed altri fanno riferimento a dati
 applicativi che non ci interessano non avendo nulla a che fare con la
 risoluzione degli indirizzi IP, pertanto non entreremo nei dettagli del
 significato di tutti i \textit{resource record}, ma solo di quelli usati dalle
 funzioni del \textit{resolver}. Questi sono sostanzialmente i seguenti (per
-indicarli si è usata la notazione dei file di zona di BIND):
+indicarli si è usata la notazione dei file di zona di BIND):
 \begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
 \item[\texttt{A}] viene usato per indicare la corrispondenza fra un nome a
   dominio ed un indirizzo IPv4; ad esempio la corrispondenza fra
   \texttt{dodds.truelite.it} e l'indirizzo IP \texttt{62.48.34.25}.
 \item[\texttt{AAAA}] viene usato per indicare la corrispondenza fra un nome a
-  dominio ed un indirizzo IPv6; è chiamato in questo modo dato che la
-  dimensione di un indirizzo IPv6 è quattro volte quella di un indirizzo IPv4.
+  dominio ed un indirizzo IPv6; è chiamato in questo modo dato che la
+  dimensione di un indirizzo IPv6 è quattro volte quella di un indirizzo IPv4.
 \item[\texttt{PTR}] per fornire la corrispondenza inversa fra un indirizzo IP
   ed un nome a dominio ad esso associato si utilizza questo tipo di record (il
   cui nome sta per \textit{pointer}).
-\item[\texttt{CNAME}] qualora si abbiamo più nomi che corrispondono allo
+\item[\texttt{CNAME}] qualora si abbiamo più nomi che corrispondono allo
   stesso indirizzo (come ad esempio \texttt{www.truelite.it} e
   \texttt{sources.truelite.it}, che fanno entrambi riferimento alla stessa
-  macchina (nel caso \texttt{dodds.truelite.it}) si può usare questo tipo di
+  macchina (nel caso \texttt{dodds.truelite.it}) si può usare questo tipo di
   record per creare degli \textit{alias} in modo da associare un qualunque
-  altro nome al \textsl{nome canonico} della macchina (si chiama così quello
+  altro nome al \textsl{nome canonico} della macchina (si chiama così quello
   associato al record \texttt{A}).
 \end{basedescript}
 
 Come accennato in caso di successo le due funzioni di richiesta restituiscono
 il risultato della interrogazione al server, in caso di insuccesso l'errore
 invece viene segnalato da un valore di ritorno pari a -1, ma in questo caso,
-non può essere utilizzata la variabile \var{errno} per riportare un codice di
+non può essere utilizzata la variabile \var{errno} per riportare un codice di
 errore, in quanto questo viene impostato per ciascuna delle chiamate al
-sistema utilizzate dalle funzioni del \textit{resolver}, non avrà alcun
-significato nell'indicare quale parte del procedimento di risoluzione è
+sistema utilizzate dalle funzioni del \textit{resolver}, non avrà alcun
+significato nell'indicare quale parte del procedimento di risoluzione è
 fallita.
 
-Per questo motivo è stata definita una variabile di errore separata,
+Per questo motivo è stata definita una variabile di errore separata,
 \var{h\_errno}, che viene utilizzata dalle funzioni del \textit{resolver} per
 indicare quale problema ha causato il fallimento della risoluzione del nome.
-Ad essa si può accedere una volta che la si dichiara con:
+Ad essa si può accedere una volta che la si dichiara con:
 \includecodesnip{listati/herrno.c} 
-ed i valori che può assumere, con il relativo significato, sono riportati in
+ed i valori che può assumere, con il relativo significato, sono riportati in
 tab.~\ref{tab:h_errno_values}.
 
 \begin{table}[!htb]
@@ -578,16 +578,16 @@ tab.~\ref{tab:h_errno_values}.
     \textbf{Costante} & \textbf{Significato} \\
     \hline
     \hline
-    \const{HOST\_NOT\_FOUND} & L'indirizzo richiesto non è valido e la
-                               macchina indicata è sconosciuta.\\
-    \const{NO\_ADDRESS}      & Il nome a dominio richiesto è valido, ma non ha
+    \const{HOST\_NOT\_FOUND} & L'indirizzo richiesto non è valido e la
+                               macchina indicata è sconosciuta.\\
+    \const{NO\_ADDRESS}      & Il nome a dominio richiesto è valido, ma non ha
                                un indirizzo associato ad esso
-                               (alternativamente può essere indicato come 
+                               (alternativamente può essere indicato come 
                                \const{NO\_DATA}).\\
-    \const{NO\_RECOVERY}     & Si è avuto un errore non recuperabile
+    \const{NO\_RECOVERY}     & Si è avuto un errore non recuperabile
                                nell'interrogazione di un server DNS.\\
-    \const{TRY\_AGAIN}       & Si è avuto un errore temporaneo
-                               nell'interrogazione di un server DNS, si può
+    \const{TRY\_AGAIN}       & Si è avuto un errore temporaneo
+                               nell'interrogazione di un server DNS, si può
                                ritentare l'interrogazione in un secondo
                                tempo.\\
     \hline
@@ -598,8 +598,8 @@ tab.~\ref{tab:h_errno_values}.
 
 Insieme alla nuova variabile vengono definite anche due nuove funzioni per
 stampare l'errore a video, analoghe a quelle di sez.~\ref{sec:sys_strerror}
-per \var{errno}, ma che usano il valore di \var{h\_errno}; la prima è
-\funcd{herror} ed il suo prototipo è:
+per \var{errno}, ma che usano il valore di \var{h\_errno}; la prima è
+\funcd{herror} ed il suo prototipo è:
 \begin{functions}
 \headdecl{netdb.h}
 \funcdecl{void herror(const char *string)}
@@ -607,10 +607,10 @@ per \var{errno}, ma che usano il valore di \var{h\_errno}; la prima 
 Stampa un errore di risoluzione.
 \end{functions}
 
-La funzione è l'analoga di \func{perror} e stampa sullo standard error un
+La funzione è l'analoga di \func{perror} e stampa sullo standard error un
 messaggio di errore corrispondente al valore corrente di \var{h\_errno}, a cui
 viene anteposta la stringa \param{string} passata come argomento.  La seconda
-funzione è \funcd{hstrerror} ed il suo prototipo è:
+funzione è \funcd{hstrerror} ed il suo prototipo è:
 \begin{functions}
 \headdecl{netdb.h}
 \funcdecl{const char *hstrerror(int err)}
@@ -618,7 +618,7 @@ funzione 
 Restituisce una stringa corrispondente ad un errore di risoluzione.
 \end{functions}
 \noindent che, come  l'analoga \func{strerror}, restituisce una stringa con un
-messaggio di errore già formattato, corrispondente al codice passato come
+messaggio di errore già formattato, corrispondente al codice passato come
 argomento (che si presume sia dato da \var{h\_errno}).
 
 \itindend{resolver}
@@ -627,12 +627,12 @@ argomento (che si presume sia dato da \var{h\_errno}).
 \subsection{La risoluzione dei nomi a dominio}
 \label{sec:sock_name_services}
 
-La principale funzionalità del \itindex{resolver} \textit{resolver} resta
+La principale funzionalità del \itindex{resolver} \textit{resolver} resta
 quella di risolvere i nomi a dominio in indirizzi IP, per cui non ci
 dedicheremo oltre alle funzioni di richiesta generica ed esamineremo invece le
-funzioni a questo dedicate. La prima funzione è \funcd{gethostbyname} il cui
-scopo è ottenere l'indirizzo di una stazione noto il suo nome a dominio, il
-suo prototipo è:
+funzioni a questo dedicate. La prima funzione è \funcd{gethostbyname} il cui
+scopo è ottenere l'indirizzo di una stazione noto il suo nome a dominio, il
+suo prototipo è:
 \begin{prototype}{netdb.h}
 {struct hostent *gethostbyname(const char *name)}
 
@@ -646,7 +646,7 @@ Determina l'indirizzo associato al nome a dominio \param{name}.
 La funzione prende come argomento una stringa \param{name} contenente il nome
 a dominio che si vuole risolvere, in caso di successo i dati ad esso relativi
 vengono memorizzati in una opportuna struttura \struct{hostent} la cui
-definizione è riportata in fig.~\ref{fig:sock_hostent_struct}. 
+definizione è riportata in fig.~\ref{fig:sock_hostent_struct}. 
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -659,43 +659,43 @@ definizione 
 \end{figure}
 
 Quando un programma chiama \func{gethostbyname} e questa usa il DNS per
-effettuare la risoluzione del nome, è con i valori contenuti nei relativi
+effettuare la risoluzione del nome, è con i valori contenuti nei relativi
 record che vengono riempite le varie parti della struttura \struct{hostent}.
 Il primo campo della struttura, \var{h\_name} contiene sempre il \textsl{nome
-  canonico}, che nel caso del DNS è appunto il nome associato ad un record
-\texttt{A}. Il secondo campo della struttura, \var{h\_aliases}, invece è un
+  canonico}, che nel caso del DNS è appunto il nome associato ad un record
+\texttt{A}. Il secondo campo della struttura, \var{h\_aliases}, invece è un
 puntatore ad vettore di puntatori, terminato da un puntatore nullo. Ciascun
 puntatore del vettore punta ad una stringa contenente uno degli altri
 possibili nomi associati allo stesso \textsl{nome canonico} (quelli che nel
 DNS vengono inseriti come record di tipo \texttt{CNAME}).
 
 Il terzo campo della struttura, \var{h\_addrtype}, indica il tipo di indirizzo
-che è stato restituito, e può assumere soltanto i valori \const{AF\_INET} o
+che è stato restituito, e può assumere soltanto i valori \const{AF\_INET} o
 \const{AF\_INET6}, mentre il quarto campo, \var{h\_length}, indica la
 lunghezza dell'indirizzo stesso in byte. 
 
-Infine il campo \var{h\_addr\_list} è il puntatore ad un vettore di puntatori
-ai singoli indirizzi; il vettore è terminato da un puntatore nullo.  Inoltre,
+Infine il campo \var{h\_addr\_list} è il puntatore ad un vettore di puntatori
+ai singoli indirizzi; il vettore è terminato da un puntatore nullo.  Inoltre,
 come illustrato in fig.~\ref{fig:sock_hostent_struct}, viene definito il campo
-\var{h\_addr} come sinonimo di \code{h\_addr\_list[0]}, cioè un riferimento
+\var{h\_addr} come sinonimo di \code{h\_addr\_list[0]}, cioè un riferimento
 diretto al primo indirizzo della lista.
 
 Oltre ai normali nomi a dominio la funzione accetta come argomento
 \param{name} anche indirizzi numerici, in formato dotted decimal per IPv4 o
 con la notazione illustrata in sez.~\ref{sec:IP_ipv6_notation} per IPv6. In
-tal caso \func{gethostbyname} non eseguirà nessuna interrogazione remota, ma
-si limiterà a copiare la stringa nel campo \var{h\_name} ed a creare la
+tal caso \func{gethostbyname} non eseguirà nessuna interrogazione remota, ma
+si limiterà a copiare la stringa nel campo \var{h\_name} ed a creare la
 corrispondente struttura \var{in\_addr} da indirizzare con
 \code{h\_addr\_list[0]}.
 
 Con l'uso di \func{gethostbyname} normalmente si ottengono solo gli indirizzi
-IPv4, se si vogliono ottenere degli indirizzi IPv6 occorrerà prima impostare
+IPv4, se si vogliono ottenere degli indirizzi IPv6 occorrerà prima impostare
 l'opzione \const{RES\_USE\_INET6} nel campo \texttt{\_res.options} e poi
 chiamare \func{res\_init} (vedi sez.~\ref{sec:sock_resolver_functions}) per
 modificare le opzioni del \itindex{resolver} \textit{resolver}; dato che
-questo non è molto comodo è stata definita\footnote{questa è una estensione
+questo non è molto comodo è stata definita\footnote{questa è una estensione
   fornita dalle \acr{glibc}, disponibile anche in altri sistemi unix-like.}
-un'altra funzione, \funcd{gethostbyname2}, il cui prototipo è:
+un'altra funzione, \funcd{gethostbyname2}, il cui prototipo è:
 \begin{functions}
   \headdecl{netdb.h} 
   \headdecl{sys/socket.h}
@@ -711,9 +711,9 @@ Determina l'indirizzo di tipo \param{af} associato al nome a dominio
 
 In questo caso la funzione prende un secondo argomento \param{af} che indica
 (i soli valori consentiti sono \const{AF\_INET} o \const{AF\_INET6}, per
-questo è necessario l'uso di \texttt{sys/socket.h}) la famiglia di indirizzi
-che dovrà essere utilizzata nei risultati restituiti dalla funzione. Per tutto
-il resto la funzione è identica a \func{gethostbyname}, ed identici sono i
+questo è necessario l'uso di \texttt{sys/socket.h}) la famiglia di indirizzi
+che dovrà essere utilizzata nei risultati restituiti dalla funzione. Per tutto
+il resto la funzione è identica a \func{gethostbyname}, ed identici sono i
 suoi risultati.
 
 \begin{figure}[!htb]
@@ -727,12 +727,12 @@ suoi risultati.
 \end{figure}
 
 Vediamo allora un primo esempio dell'uso delle funzioni di risoluzione, in
-fig.~\ref{fig:mygethost_example} è riportato un estratto del codice di un
+fig.~\ref{fig:mygethost_example} è riportato un estratto del codice di un
 programma che esegue una semplice interrogazione al
 \itindex{resolver} \textit{resolver} usando \func{gethostbyname} e poi ne
 stampa a video i risultati. Al solito il sorgente completo, che comprende il
 trattamento delle opzioni ed una funzione per stampare un messaggio di aiuto,
-è nel file \texttt{mygethost.c} dei sorgenti allegati alla guida.
+è nel file \texttt{mygethost.c} dei sorgenti allegati alla guida.
 
 Il programma richiede un solo argomento che specifichi il nome da cercare,
 senza il quale (\texttt{\small 15--18}) esce con un errore. Dopo di che
@@ -741,58 +741,58 @@ risultato nel puntatore \var{data}. Questo (\texttt{\small 21--24}) viene
 controllato per rilevare eventuali errori, nel qual caso il programma esce
 dopo aver stampato un messaggio con \func{herror}. 
 
-Se invece la risoluzione è andata a buon fine si inizia (\texttt{\small 25})
+Se invece la risoluzione è andata a buon fine si inizia (\texttt{\small 25})
 con lo stampare il nome canonico, dopo di che (\texttt{\small 26--30}) si
 stampano eventuali altri nomi. Per questo prima (\texttt{\small 26}) si prende
 il puntatore alla cima della lista che contiene i nomi e poi (\texttt{\small
-  27--30}) si esegue un ciclo che sarà ripetuto fin tanto che nella lista si
+  27--30}) si esegue un ciclo che sarà ripetuto fin tanto che nella lista si
 troveranno dei puntatori validi\footnote{si ricordi che la lista viene
   terminata da un puntatore nullo.} per le stringhe dei nomi; prima
-(\texttt{\small 28}) si stamperà la stringa e poi (\texttt{\small 29}) si
-provvederà ad incrementare il puntatore per passare al successivo elemento
+(\texttt{\small 28}) si stamperà la stringa e poi (\texttt{\small 29}) si
+provvederà ad incrementare il puntatore per passare al successivo elemento
 della lista.
 
-Una volta stampati i nomi si passerà a stampare gli indirizzi, il primo passo
-(\texttt{\small 31--38}) è allora quello di riconoscere il tipo di indirizzo
-sulla base del valore del campo \var{h\_addrtype}, stampandolo a video. Si è
+Una volta stampati i nomi si passerà a stampare gli indirizzi, il primo passo
+(\texttt{\small 31--38}) è allora quello di riconoscere il tipo di indirizzo
+sulla base del valore del campo \var{h\_addrtype}, stampandolo a video. Si è
 anche previsto di stampare un errore nel caso (che non dovrebbe mai accadere)
 di un indirizzo non valido.
 
 Infine (\texttt{\small 39--44}) si stamperanno i valori degli indirizzi, di
-nuovo (\texttt{\small 39}) si inizializzerà un puntatore alla cima della lista
-e si eseguirà un ciclo fintanto che questo punterà ad indirizzi validi in
+nuovo (\texttt{\small 39}) si inizializzerà un puntatore alla cima della lista
+e si eseguirà un ciclo fintanto che questo punterà ad indirizzi validi in
 maniera analoga a quanto fatto in precedenza per i nomi a dominio. Si noti
 come, essendo il campo \var{h\_addr\_list} un puntatore ad strutture di
 indirizzi generiche, questo sia ancora di tipo \texttt{char **} e si possa
 riutilizzare lo stesso puntatore usato per i nomi.
 
-Per ciascun indirizzo valido si provvederà (\texttt{\small 41}) ad una
+Per ciascun indirizzo valido si provvederà (\texttt{\small 41}) ad una
 conversione con la funzione \func{inet\_ntop} (vedi
 sez.~\ref{sec:sock_addr_func}) passandole gli opportuni argomenti, questa
-restituirà la stringa da stampare (\texttt{\small 42}) con il valore
-dell'indirizzo in \var{buffer}, che si è avuto la cura di dichiarare
+restituirà la stringa da stampare (\texttt{\small 42}) con il valore
+dell'indirizzo in \var{buffer}, che si è avuto la cura di dichiarare
 inizialmente (\texttt{\small 10}) con dimensioni adeguate; dato che la
-funzione è in grado di tenere conto automaticamente del tipo di indirizzo non
+funzione è in grado di tenere conto automaticamente del tipo di indirizzo non
 ci sono precauzioni particolari da prendere.\footnote{volendo essere pignoli
-  si dovrebbe controllarne lo stato di uscita, lo si è tralasciato per non
+  si dovrebbe controllarne lo stato di uscita, lo si è tralasciato per non
   appesantire il codice, dato che in caso di indirizzi non validi si sarebbe
   avuto un errore con \func{gethostbyname}, ma si ricordi che la sicurezza non
-  è mai troppa.}
+  è mai troppa.}
 
 Le funzioni illustrate finora hanno un difetto: utilizzando una area di
 memoria interna per allocare i contenuti della struttura \struct{hostent} non
 possono essere\index{funzioni!rientranti} rientranti. Questo comporta anche
 che in due successive chiamate i dati potranno essere sovrascritti. Si tenga
-presente poi che copiare il contenuto della sola struttura non è sufficiente
+presente poi che copiare il contenuto della sola struttura non è sufficiente
 per salvare tutti i dati, in quanto questa contiene puntatori ad altri dati,
 che pure possono essere sovrascritti; per questo motivo, se si vuole salvare
-il risultato di una chiamata, occorrerà eseguire quella che si chiama una
-\itindex{deep~copy} \textit{deep copy}.\footnote{si chiama così quella tecnica
+il risultato di una chiamata, occorrerà eseguire quella che si chiama una
+\itindex{deep~copy} \textit{deep copy}.\footnote{si chiama così quella tecnica
   per cui, quando si deve copiare il contenuto di una struttura complessa (con
   puntatori che puntano ad altri dati, che a loro volta possono essere
   puntatori ad altri dati) si deve copiare non solo il contenuto della
   struttura, ma eseguire una scansione per risolvere anche tutti i puntatori
-  contenuti in essa (e così via se vi sono altre sotto-strutture con altri
+  contenuti in essa (e così via se vi sono altre sotto-strutture con altri
   puntatori) e copiare anche i dati da questi referenziati.}
 
 Per ovviare a questi problemi nelle \acr{glibc} sono definite anche delle
@@ -819,9 +819,9 @@ pertanto avremo le due funzioni \funcd{gethostbyname\_r} e
 Gli argomenti \param{name} (e \param{af} per \func{gethostbyname2\_r}) hanno
 lo stesso significato visto in precedenza. Tutti gli altri argomenti hanno lo
 stesso significato per entrambe le funzioni. Per evitare l'uso di variabili
-globali si dovrà allocare preventivamente una struttura \struct{hostent} in
+globali si dovrà allocare preventivamente una struttura \struct{hostent} in
 cui ricevere il risultato, passandone l'indirizzo alla funzione nell'argomento
-\param{ret}.  Inoltre, dato che \struct{hostent} contiene dei puntatori, dovrà
+\param{ret}.  Inoltre, dato che \struct{hostent} contiene dei puntatori, dovrà
 essere allocato anche un buffer in cui le funzioni possano scrivere tutti i
 dati del risultato dell'interrogazione da questi puntati; l'indirizzo e la
 lunghezza di questo buffer devono essere indicati con gli argomenti
@@ -829,28 +829,28 @@ lunghezza di questo buffer devono essere indicati con gli argomenti
 
 Gli ultimi due argomenti vengono utilizzati per avere indietro i risultati
 come \itindex{value~result~argument} \textit{value result argument}, si deve
-specificare l'indirizzo della variabile su cui la funzione dovrà salvare il
-codice di errore con \param{h\_errnop} e quello su cui dovrà salvare il
-puntatore che si userà per accedere i dati con \param{result}.
+specificare l'indirizzo della variabile su cui la funzione dovrà salvare il
+codice di errore con \param{h\_errnop} e quello su cui dovrà salvare il
+puntatore che si userà per accedere i dati con \param{result}.
 
 In caso di successo entrambe le funzioni restituiscono un valore nullo,
 altrimenti restituiscono un codice di errore negativo e all'indirizzo puntato
-da \param{result} sarà salvato un puntatore nullo, mentre a quello puntato da
-\param{h\_errnop} sarà salvato il valore del codice di errore, dato che per
-essere \index{funzioni!rientranti} rientrante la funzione non può la variabile
+da \param{result} sarà salvato un puntatore nullo, mentre a quello puntato da
+\param{h\_errnop} sarà salvato il valore del codice di errore, dato che per
+essere \index{funzioni!rientranti} rientrante la funzione non può la variabile
 globale \var{h\_errno}. In questo caso il codice di errore, oltre ai valori di
-tab.~\ref{tab:h_errno_values}, può avere anche quello di \errcode{ERANGE}
+tab.~\ref{tab:h_errno_values}, può avere anche quello di \errcode{ERANGE}
 qualora il buffer allocato su \param{buf} non sia sufficiente a contenere i
-dati, in tal caso si dovrà semplicemente ripetere l'esecuzione della funzione
+dati, in tal caso si dovrà semplicemente ripetere l'esecuzione della funzione
 con un buffer di dimensione maggiore.
 
-Una delle caratteristiche delle interrogazioni al servizio DNS è che queste
+Una delle caratteristiche delle interrogazioni al servizio DNS è che queste
 sono normalmente eseguite con il protocollo UDP, ci sono casi in cui si
 preferisce che vengano usate connessioni permanenti con il protocollo TCP. Per
 ottenere questo\footnote{si potrebbero impostare direttamente le opzioni di
   \var{\_\_res.options}, ma queste funzioni permettono di semplificare la
-  procedura.} sono previste delle funzioni apposite; la prima è
-\funcd{sethostent}, il cui prototipo è:
+  procedura.} sono previste delle funzioni apposite; la prima è
+\funcd{sethostent}, il cui prototipo è:
 \begin{prototype}{netdb.h}
 {void sethostent(int stayopen)}
 
@@ -861,10 +861,10 @@ Richiede l'uso di connessioni per le interrogazioni ad un server DNS.
 
 La funzione permette di richiedere l'uso di connessioni TCP per la richiesta
 dei dati, e che queste restino aperte per successive richieste. Il valore
-dell'argomento \param{stayopen} indica se attivare questa funzionalità, un
+dell'argomento \param{stayopen} indica se attivare questa funzionalità, un
 valore pari a 1 (o diverso da zero), che indica una condizione vera in C,
-attiva la funzionalità.  Come si attiva l'uso delle connessioni TCP lo si può
-disattivare con la funzione \funcd{endhostent}; il suo prototipo è:
+attiva la funzionalità.  Come si attiva l'uso delle connessioni TCP lo si può
+disattivare con la funzione \funcd{endhostent}; il suo prototipo è:
 \begin{prototype}{netdb.h}
 {void endhostent(void)}
 
@@ -872,13 +872,13 @@ Disattiva l'uso di connessioni per le interrogazioni ad un server DNS.
 
 \bodydesc{La funzione non restituisce nulla.}
 \end{prototype}
-\noindent e come si può vedere la funzione è estremamente semplice, non
+\noindent e come si può vedere la funzione è estremamente semplice, non
 richiedendo nessun argomento.
 
 
-Infine si può richiedere la risoluzione inversa di un indirizzo IP od IPv6,
-per ottenerne il nome a dominio ad esso associato, per fare questo si può
-usare la funzione \funcd{gethostbyaddr}, il cui prototipo è:
+Infine si può richiedere la risoluzione inversa di un indirizzo IP od IPv6,
+per ottenerne il nome a dominio ad esso associato, per fare questo si può
+usare la funzione \funcd{gethostbyaddr}, il cui prototipo è:
 \begin{functions}
   \headdecl{netdb.h} 
   \headdecl{sys/socket.h} 
@@ -890,19 +890,19 @@ usare la funzione \funcd{gethostbyaddr}, il cui prototipo 
     \struct{hostent} in caso di successo ed \const{NULL} in caso di errore.}
 \end{functions}
 
-In questo caso l'argomento \param{addr} dovrà essere il puntatore ad una
+In questo caso l'argomento \param{addr} dovrà essere il puntatore ad una
 appropriata struttura contenente il valore dell'indirizzo IP (o IPv6) che si
-vuole risolvere. L'uso del tipo \texttt{char *} per questo argomento è
-storico, il dato dovrà essere fornito in una struttura
+vuole risolvere. L'uso del tipo \texttt{char *} per questo argomento è
+storico, il dato dovrà essere fornito in una struttura
 \struct{in\_addr}\footnote{si ricordi che, come illustrato in
-  fig.~\ref{fig:sock_sa_ipv4_struct}, questo in realtà corrisponde ad un
+  fig.~\ref{fig:sock_sa_ipv4_struct}, questo in realtà corrisponde ad un
   numero intero, da esprimere comunque in \textit{network order}, non
-  altrettanto avviene però per \struct{in6\_addr}, pertanto è sempre opportuno
+  altrettanto avviene però per \struct{in6\_addr}, pertanto è sempre opportuno
   inizializzare questi indirizzi con \func{inet\_pton} (vedi
   sez.~\ref{sec:sock_conv_func_gen}).}  per un indirizzo IPv4 ed una struttura
-\struct{in6\_addr} per un indirizzo IPv6, mentre in \param{len} se ne dovrà
+\struct{in6\_addr} per un indirizzo IPv6, mentre in \param{len} se ne dovrà
 specificare la dimensione (rispettivamente 4 o 16), infine l'argomento
-\param{type} indica il tipo di indirizzo e dovrà essere o \const{AF\_INET} o
+\param{type} indica il tipo di indirizzo e dovrà essere o \const{AF\_INET} o
 \const{AF\_INET6}.
 
 La funzione restituisce, in caso di successo, un puntatore ad una struttura
@@ -910,14 +910,14 @@ La funzione restituisce, in caso di successo, un puntatore ad una struttura
 richiedendo al DNS un record di tipo \texttt{PTR} corrispondente all'indirizzo
 specificato. In caso di errore al solito viene usata la variabile
 \var{h\_errno} per restituire un opportuno codice. In questo caso l'unico
-campo del risultato che interessa è \var{h\_name} che conterrà il nome a
+campo del risultato che interessa è \var{h\_name} che conterrà il nome a
 dominio, la funziona comunque inizializza anche il primo campo della lista
 \var{h\_addr\_list} col valore dell'indirizzo passato come argomento.
 
 Per risolvere il problema dell'uso da parte delle due funzioni
-\func{gethostbyname} e \func{gethostbyaddr} di memoria statica che può essere
-sovrascritta fra due chiamate successive, e per avere sempre la possibilità di
-indicare esplicitamente il tipo di indirizzi voluto (cosa che non è possibile
+\func{gethostbyname} e \func{gethostbyaddr} di memoria statica che può essere
+sovrascritta fra due chiamate successive, e per avere sempre la possibilità di
+indicare esplicitamente il tipo di indirizzi voluto (cosa che non è possibile
 con \func{gethostbyname}), vennero introdotte due nuove funzioni di
 risoluzione,\footnote{le funzioni sono presenti nelle \acr{glibc} versione
   2.1.96, ma essendo considerate deprecate (vedi
@@ -943,7 +943,7 @@ cui prototipi sono:
 \end{functions}
 
 Entrambe le funzioni supportano esplicitamente la scelta di una famiglia di
-indirizzi con l'argomento \param{af} (che può assumere i valori
+indirizzi con l'argomento \param{af} (che può assumere i valori
 \const{AF\_INET} o \const{AF\_INET6}), e restituiscono un codice di errore
 (con valori identici a quelli precedentemente illustrati in
 tab.~\ref{tab:h_errno_values}) nella variabile puntata da \param{error\_num}.
@@ -976,8 +976,8 @@ tab.~\ref{tab:sock_getipnodebyname_flags}.
                             saranno rimappati in IPv6.\\
     \const{AI\_ADDRCONFIG}& Richiede che una richiesta IPv4 o IPv6 venga
                             eseguita solo se almeno una interfaccia del
-                            sistema è associata ad un indirizzo di tale tipo.\\
-    \const{AI\_DEFAULT}   & Il valore di default, è equivalente alla
+                            sistema è associata ad un indirizzo di tale tipo.\\
+    \const{AI\_DEFAULT}   & Il valore di default, è equivalente alla
                             combinazione di \const{AI\_ADDRCONFIG} e di
                             \const{AI\_V4MAPPED}.\\  
     \hline
@@ -992,10 +992,10 @@ che contiene i risultati della ricerca, che viene allocata dinamicamente
 insieme a tutto lo spazio necessario a contenere i dati in essa referenziati;
 per questo motivo queste funzioni non soffrono dei problemi dovuti all'uso di
 una sezione statica di memoria presenti con le precedenti \func{gethostbyname}
-e \func{gethostbyaddr}.  L'uso di una allocazione dinamica però comporta anche
-la necessità di disallocare esplicitamente la memoria occupata dai risultati
-una volta che questi non siano più necessari; a tale scopo viene fornita la
-funzione \funcd{freehostent}, il cui prototipo è:
+e \func{gethostbyaddr}.  L'uso di una allocazione dinamica però comporta anche
+la necessità di disallocare esplicitamente la memoria occupata dai risultati
+una volta che questi non siano più necessari; a tale scopo viene fornita la
+funzione \funcd{freehostent}, il cui prototipo è:
 \begin{functions}
   \headdecl{netdb.h} 
   \headdecl{sys/types.h} 
@@ -1022,11 +1022,11 @@ servizio) per ciascuna delle informazioni di rete mantenute dal
 \itindex{Name~Service~Switch} \textit{Name Service Switch} che permettono
 rispettivamente di trovare una corrispondenza cercando per nome o per numero.
 
-L'elenco di queste funzioni è riportato nelle colonne finali di
+L'elenco di queste funzioni è riportato nelle colonne finali di
 tab.~\ref{tab:name_resolution_functions}, dove le si sono suddivise rispetto
 al tipo di informazione che forniscono (riportato in prima colonna). Nella
-tabella si è anche riportato il file su cui vengono ordinariamente mantenute
-queste informazioni, che però può essere sostituito da un qualunque supporto
+tabella si è anche riportato il file su cui vengono ordinariamente mantenute
+queste informazioni, che però può essere sostituito da un qualunque supporto
 interno al \itindex{Name~Service~Switch} \textit{Name Service Switch} (anche
 se usualmente questo avviene solo per la risoluzione degli indirizzi).
 Ciascuna funzione fa riferimento ad una sua apposita struttura che contiene i
@@ -1058,13 +1058,13 @@ relativi dati, riportata in terza colonna.
 
 Delle funzioni di tab.~\ref{tab:name_resolution_functions} abbiamo trattato
 finora soltanto quelle relative alla risoluzione dei nomi, dato che sono le
-più usate, e prevedono praticamente da sempre la necessità di rivolgersi ad
-una entità esterna; per le altre invece, estensioni fornite dal
+più usate, e prevedono praticamente da sempre la necessità di rivolgersi ad
+una entità esterna; per le altre invece, estensioni fornite dal
 \itindex{Name~Service~Switch} NSS a parte, si fa sempre riferimento ai dati
 mantenuti nei rispettivi file.
 
-Dopo la risoluzione dei nomi a dominio una delle ricerche più comuni è quella
-sui nomi dei servizi di rete più comuni (cioè \texttt{http}, \texttt{smtp},
+Dopo la risoluzione dei nomi a dominio una delle ricerche più comuni è quella
+sui nomi dei servizi di rete più comuni (cioè \texttt{http}, \texttt{smtp},
 ecc.) da associare alle rispettive porte. Le due funzioni da utilizzare per
 questo sono \funcd{getservbyname} e \funcd{getservbyaddr}, che permettono
 rispettivamente di ottenere il numero di porta associato ad un servizio dato
@@ -1085,14 +1085,14 @@ che indica il protocollo per il quale si intende effettuare la
 ricerca,\footnote{le informazioni mantenute in \conffile{/etc/services}
   infatti sono relative sia alle porte usate su UDP che su TCP, occorre quindi
   specificare a quale dei due protocolli si fa riferimento.} che nel caso si
-IP può avere come valori possibili solo \texttt{udp} o
+IP può avere come valori possibili solo \texttt{udp} o
 \texttt{tcp};\footnote{in teoria si potrebbe avere un qualunque protocollo fra
   quelli citati in \conffile{/etc/protocols}, posto che lo stesso supporti il
   concetto di \textsl{porta}, in pratica questi due sono gli unici presenti.}
-se si specifica un puntatore nullo la ricerca sarà eseguita su un protocollo
+se si specifica un puntatore nullo la ricerca sarà eseguita su un protocollo
 qualsiasi.
 
-Il primo argomento è il nome del servizio per \func{getservbyname},
+Il primo argomento è il nome del servizio per \func{getservbyname},
 specificato tramite la stringa \param{name}, mentre \func{getservbyport}
 richiede il numero di porta in \param{port}. Entrambe le funzioni eseguono una
 ricerca sul file \conffile{/etc/services}\footnote{il
@@ -1103,7 +1103,7 @@ specificati; se la risoluzione ha successo viene restituito un puntatore ad
 una apposita struttura \struct{servent} contenente tutti i risultati,
 altrimenti viene restituito un puntatore nullo.  Si tenga presente che anche
 in questo caso i dati vengono mantenuti in una area di memoria statica e che
-quindi la funzione non è \index{funzioni!rientranti} rientrante.
+quindi la funzione non è \index{funzioni!rientranti} rientrante.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -1115,16 +1115,16 @@ quindi la funzione non 
   \label{fig:sock_servent_struct}
 \end{figure}
 
-La definizione della struttura \struct{servent} è riportata in
+La definizione della struttura \struct{servent} è riportata in
 fig.~\ref{fig:sock_servent_struct}, il primo campo, \var{s\_name} contiene
-sempre il nome canonico del servizio, mentre \var{s\_aliases} è un puntatore
+sempre il nome canonico del servizio, mentre \var{s\_aliases} è un puntatore
 ad un vettore di stringhe contenenti gli eventuali nomi alternativi
 utilizzabili per identificare lo stesso servizio. Infine \var{s\_port}
 contiene il numero di porta e \var{s\_proto} il nome del protocollo.
 
 Come riportato in tab.~\ref{tab:name_resolution_functions} ci sono analoghe
 funzioni per la risoluzione del nome dei protocolli e delle reti; non staremo
-a descriverle nei dettagli, in quanto il loro uso è molto limitato, esse
+a descriverle nei dettagli, in quanto il loro uso è molto limitato, esse
 comunque utilizzano una loro struttura dedicata del tutto analoga alle
 precedenti: tutti i dettagli relativi al loro funzionamento possono essere
 trovati nelle rispettive pagine di manuale.
@@ -1155,16 +1155,16 @@ dei servizi avremo allora le tre funzioni \funcd{setservent},
 \end{functions}
 
 La prima funzione, \func{getservent}, legge una singola voce a partire dalla
-posizione corrente in \conffile{/etc/services}, pertanto si può eseguire una
-lettura sequenziale dello stesso invocandola più volte. Se il file non è
-aperto provvede automaticamente ad aprirlo, nel qual caso leggerà la prima
+posizione corrente in \conffile{/etc/services}, pertanto si può eseguire una
+lettura sequenziale dello stesso invocandola più volte. Se il file non è
+aperto provvede automaticamente ad aprirlo, nel qual caso leggerà la prima
 voce. La seconda funzione, \func{setservent}, permette di aprire il file
-\conffile{/etc/services} per una successiva lettura, ma se il file è già stato
+\conffile{/etc/services} per una successiva lettura, ma se il file è già stato
 aperto riporta la posizione di lettura alla prima voce del file, in questo
-modo si può far ricominciare da capo una lettura sequenziale. L'argomento
-\param{stayopen}, se diverso da zero, fa sì che il file resti aperto anche fra
+modo si può far ricominciare da capo una lettura sequenziale. L'argomento
+\param{stayopen}, se diverso da zero, fa sì che il file resti aperto anche fra
 diverse chiamate a \func{getservbyname} e \func{getservbyaddr}.\footnote{di
-  default dopo una chiamata a queste funzioni il file viene chiuso, cosicché
+  default dopo una chiamata a queste funzioni il file viene chiuso, cosicché
   una successiva chiamata a \func{getservent} riparte dall'inizio.}  La terza
 funzione, \funcd{endservent}, provvede semplicemente a chiudere il file.
 
@@ -1205,9 +1205,9 @@ rimandando alle rispettive pagine di manuale.
 \label{sec:sock_advanced_name_services}
 
 Quelle illustrate nella sezione precedente sono le funzioni classiche per la
-risoluzione di nomi ed indirizzi IP, ma abbiamo già visto come esse soffrano
+risoluzione di nomi ed indirizzi IP, ma abbiamo già visto come esse soffrano
 di vari inconvenienti come il fatto che usano informazioni statiche, e non
-prevedono la possibilità di avere diverse classi di indirizzi. Anche se sono
+prevedono la possibilità di avere diverse classi di indirizzi. Anche se sono
 state create delle estensioni o metodi diversi che permettono di risolvere
 alcuni di questi inconvenienti,\footnote{rimane ad esempio il problema
   generico che si deve sapere in anticipo quale tipo di indirizzi IP (IPv4 o
@@ -1219,16 +1219,16 @@ problema della risoluzione del nome che identifica la macchina, ma anche
 quello del servizio a cui ci si vuole rivolgere.  Per questo motivo con lo
 standard POSIX 1003.1-2001 sono state indicate come deprecate le varie
 funzioni \func{gethostbyaddr}, \func{gethostbyname}, \var{getipnodebyname} e
-\var{getipnodebyaddr} ed è stata introdotta una interfaccia completamente
+\var{getipnodebyaddr} ed è stata introdotta una interfaccia completamente
 nuova.
 
-La prima funzione di questa interfaccia è \funcd{getaddrinfo},\footnote{la
-  funzione è definita, insieme a \func{getnameinfo} che vedremo più avanti,
+La prima funzione di questa interfaccia è \funcd{getaddrinfo},\footnote{la
+  funzione è definita, insieme a \func{getnameinfo} che vedremo più avanti,
   nell'\href{http://www.ietf.org/rfc/rfc2553.txt}{RFC~2553}.} che combina le
-funzionalità delle precedenti \func{getipnodebyname}, \func{getipnodebyaddr},
+funzionalità delle precedenti \func{getipnodebyname}, \func{getipnodebyaddr},
 \func{getservbyname} e \func{getservbyport}, consentendo di ottenere
 contemporaneamente sia la risoluzione di un indirizzo simbolico che del nome
-di un servizio; il suo prototipo è:
+di un servizio; il suo prototipo è:
 \begin{functions}
   \headdecl{netdb.h} 
   \headdecl{sys/socket.h} 
@@ -1245,29 +1245,29 @@ di un servizio; il suo prototipo 
 
 La funzione prende come primo argomento il nome della macchina che si vuole
 risolvere, specificato tramite la stringa \param{node}. Questo argomento,
-oltre ad un comune nome a dominio, può indicare anche un indirizzo numerico in
+oltre ad un comune nome a dominio, può indicare anche un indirizzo numerico in
 forma \textit{dotted-decimal} per IPv4 o in formato esadecimale per IPv6.  Si
-può anche specificare il nome di una rete invece che di una singola macchina.
+può anche specificare il nome di una rete invece che di una singola macchina.
 Il secondo argomento, \param{service}, specifica invece il nome del servizio
-che si intende risolvere. Per uno dei due argomenti si può anche usare il
-valore \const{NULL}, nel qual caso la risoluzione verrà effettuata soltanto
+che si intende risolvere. Per uno dei due argomenti si può anche usare il
+valore \const{NULL}, nel qual caso la risoluzione verrà effettuata soltanto
 sulla base del valore dell'altro.
 
 Il terzo argomento, \param{hints}, deve essere invece un puntatore ad una
 struttura \struct{addrinfo} usata per dare dei \textsl{suggerimenti} al
 procedimento di risoluzione riguardo al protocollo o del tipo di socket che si
-intenderà utilizzare; \func{getaddrinfo} infatti permette di effettuare
+intenderà utilizzare; \func{getaddrinfo} infatti permette di effettuare
 ricerche generiche sugli indirizzi, usando sia IPv4 che IPv6, e richiedere
 risoluzioni sui nomi dei servizi indipendentemente dal protocollo (ad esempio
 TCP o UDP) che questi possono utilizzare.
 
 Come ultimo argomento in \param{res} deve essere passato un puntatore ad una
-variabile (di tipo puntatore ad una struttura \struct{addrinfo}) che verrà
+variabile (di tipo puntatore ad una struttura \struct{addrinfo}) che verrà
 utilizzata dalla funzione per riportare (come \itindex{value~result~argument}
-\textit{value result argument}) i propri risultati. La funzione infatti è
+\textit{value result argument}) i propri risultati. La funzione infatti è
 \index{funzioni!rientranti} rientrante, ed alloca autonomamente tutta la
 memoria necessaria in cui verranno riportati i risultati della risoluzione.
-La funzione scriverà all'indirizzo puntato da \param{res} il puntatore
+La funzione scriverà all'indirizzo puntato da \param{res} il puntatore
 iniziale ad una \itindex{linked~list} \textit{linked list} di strutture di
 tipo \struct{addrinfo} contenenti tutte le informazioni ottenute.
 
@@ -1282,15 +1282,15 @@ tipo \struct{addrinfo} contenenti tutte le informazioni ottenute.
 \end{figure}
 
 Come illustrato la struttura \struct{addrinfo}, la cui definizione\footnote{la
-  definizione è ripresa direttamente dal file \texttt{netdb.h} in questa
+  definizione è ripresa direttamente dal file \texttt{netdb.h} in questa
   struttura viene dichiarata, la pagina di manuale riporta \type{size\_t} come
   tipo di dato per il campo \var{ai\_addrlen}, qui viene usata quanto previsto
   dallo standard POSIX, in cui viene utilizzato \type{socklen\_t}; i due tipi
-  di dati sono comunque equivalenti.} è riportata in
+  di dati sono comunque equivalenti.} è riportata in
 fig.~\ref{fig:sock_addrinfo_struct}, viene usata sia in ingresso, per passare
 dei valori di controllo alla funzione, che in uscita, per ricevere i
-risultati. Il primo campo, \var{ai\_flags}, è una maschera binaria di bit che
-permettono di controllare le varie modalità di risoluzione degli indirizzi,
+risultati. Il primo campo, \var{ai\_flags}, è una maschera binaria di bit che
+permettono di controllare le varie modalità di risoluzione degli indirizzi,
 che viene usato soltanto in ingresso. I tre campi successivi \var{ai\_family},
 \var{ai\_socktype}, e \var{ai\_protocol} contengono rispettivamente la
 famiglia di indirizzi, il tipo di socket e il protocollo, in ingresso vengono
@@ -1300,16 +1300,16 @@ contenuto nella struttura.
 
 Tutti i campi seguenti vengono usati soltanto in uscita; il campo
 \var{ai\_addrlen} indica la dimensione della struttura degli indirizzi
-ottenuta come risultato, il cui contenuto sarà memorizzato nella struttura
+ottenuta come risultato, il cui contenuto sarà memorizzato nella struttura
 \struct{sockaddr} posta all'indirizzo puntato dal campo \var{ai\_addr}. Il
-campo \var{ai\_canonname} è un puntatore alla stringa contenente il nome
-canonico della macchina, ed infine, quando la funzione restituisce più di un
-risultato, \var{ai\_next} è un puntatore alla successiva struttura
+campo \var{ai\_canonname} è un puntatore alla stringa contenente il nome
+canonico della macchina, ed infine, quando la funzione restituisce più di un
+risultato, \var{ai\_next} è un puntatore alla successiva struttura
 \struct{addrinfo} della lista.
 
-Ovviamente non è necessario dare dei suggerimenti in ingresso, ed usando
+Ovviamente non è necessario dare dei suggerimenti in ingresso, ed usando
 \const{NULL} come valore per l'argomento \param{hints} si possono compiere
-ricerche generiche.  Se però si specifica un valore non nullo questo deve
+ricerche generiche.  Se però si specifica un valore non nullo questo deve
 puntare ad una struttura \struct{addrinfo} precedentemente allocata nella
 quale siano stati opportunamente impostati i valori dei campi
 \var{ai\_family}, \var{ai\_socktype}, \var{ai\_protocol} ed \var{ai\_flags}.
@@ -1318,12 +1318,12 @@ I due campi \var{ai\_family} e \var{ai\_socktype} prendono gli stessi valori
 degli analoghi argomenti della funzione \func{socket}; in particolare per
 \var{ai\_family} si possono usare i valori di tab.~\ref{tab:net_pf_names} ma
 sono presi in considerazione solo \const{PF\_INET} e \const{PF\_INET6}, mentre
-se non si vuole specificare nessuna famiglia di indirizzi si può usare il
+se non si vuole specificare nessuna famiglia di indirizzi si può usare il
 valore \const{PF\_UNSPEC}.  Allo stesso modo per \var{ai\_socktype} si possono
 usare i valori illustrati in sez.~\ref{sec:sock_type} per indicare per quale
 tipo di socket si vuole risolvere il servizio indicato, anche se i soli
 significativi sono \const{SOCK\_STREAM} e \const{SOCK\_DGRAM}; in questo caso,
-se non si vuole effettuare nessuna risoluzione specifica, si potrà usare un
+se non si vuole effettuare nessuna risoluzione specifica, si potrà usare un
 valore nullo.
 
 Il campo \var{ai\_protocol} permette invece di effettuare la selezione dei
@@ -1343,25 +1343,25 @@ nella selezione.
     \hline
     \const{AI\_PASSIVE}    & Viene utilizzato per ottenere un indirizzo in
                              formato adatto per una successiva chiamata a
-                             \func{bind}. Se specificato quando si è usato 
+                             \func{bind}. Se specificato quando si è usato 
                              \const{NULL} come valore per \param{node} gli
                              indirizzi restituiti saranno inizializzati al
                              valore generico (\const{INADDR\_ANY} per IPv4 e
                              \const{IN6ADDR\_ANY\_INIT} per IPv6), altrimenti
-                             verrà usato l'indirizzo dell'interfaccia di
-                             \textit{loopback}. Se invece non è impostato gli
+                             verrà usato l'indirizzo dell'interfaccia di
+                             \textit{loopback}. Se invece non è impostato gli
                              indirizzi verranno restituiti in formato adatto ad
                              una chiamata a \func{connect} o \func{sendto}.\\
     \const{AI\_CANONNAME}  & Richiede la restituzione del nome canonico della
-                             macchina, che verrà salvato in una stringa il cui
-                             indirizzo sarà restituito nel campo
+                             macchina, che verrà salvato in una stringa il cui
+                             indirizzo sarà restituito nel campo
                              \var{ai\_canonname} della prima struttura
                              \struct{addrinfo} dei risultati. Se il nome
-                             canonico non è disponibile al suo posto
+                             canonico non è disponibile al suo posto
                              viene restituita una copia di \param{node}. \\ 
     \const{AI\_NUMERICHOST}& Se impostato il nome della macchina specificato
                              con \param{node} deve essere espresso in forma
-                             numerica, altrimenti sarà restituito un errore
+                             numerica, altrimenti sarà restituito un errore
                              \const{EAI\_NONAME} (vedi
                              tab.~\ref{tab:addrinfo_error_code}), in questo
                              modo si evita ogni chiamata alle funzioni di
@@ -1380,11 +1380,11 @@ nella selezione.
 \end{table}
 
 
-Infine l'ultimo campo è \var{ai\_flags}; che deve essere impostato come una
+Infine l'ultimo campo è \var{ai\_flags}; che deve essere impostato come una
 maschera binaria; i bit di questa variabile infatti vengono usati per dare
 delle indicazioni sul tipo di risoluzione voluta, ed hanno valori analoghi a
 quelli visti in sez.~\ref{sec:sock_name_services} per \func{getipnodebyname};
-il valore di \var{ai\_flags} può essere impostata con un OR aritmetico delle
+il valore di \var{ai\_flags} può essere impostata con un OR aritmetico delle
 costanti di tab.~\ref{tab:ai_flags_values}, ciascuna delle quali identifica un
 bit della maschera.
 
@@ -1392,9 +1392,9 @@ La funzione restituisce un valore nullo in caso di successo, o un codice in
 caso di errore. I valori usati come codice di errore sono riportati in
 tab.~\ref{tab:addrinfo_error_code}; dato che la funzione utilizza altre
 funzioni e chiamate al sistema per ottenere il suo risultato in generale il
-valore di \var{errno} non è significativo, eccetto il caso in cui si sia
+valore di \var{errno} non è significativo, eccetto il caso in cui si sia
 ricevuto un errore di \const{EAI\_SYSTEM}, nel qual caso l'errore
-corrispondente è riportato tramite \var{errno}.
+corrispondente è riportato tramite \var{errno}.
 
 \begin{table}[!htb]
   \centering
@@ -1404,35 +1404,35 @@ corrispondente 
     \textbf{Costante} & \textbf{Significato} \\
     \hline
     \hline
-    \const{EAI\_FAMILY}  & La famiglia di indirizzi richiesta non è
+    \const{EAI\_FAMILY}  & La famiglia di indirizzi richiesta non è
                            supportata. \\ 
-    \const{EAI\_SOCKTYPE}& Il tipo di socket richiesto non è supportato. \\
+    \const{EAI\_SOCKTYPE}& Il tipo di socket richiesto non è supportato. \\
     \const{EAI\_BADFLAGS}& Il campo \var{ai\_flags} contiene dei valori non
                            validi. \\
     \const{EAI\_NONAME}  & Il nome a dominio o il servizio non sono noti,
                            viene usato questo errore anche quando si specifica
                            il valore \const{NULL} per entrambi gli argomenti
                            \param{node} e \param{service}. \\
-    \const{EAI\_SERVICE} & Il servizio richiesto non è disponibile per il tipo
-                           di socket richiesto, anche se può esistere per
+    \const{EAI\_SERVICE} & Il servizio richiesto non è disponibile per il tipo
+                           di socket richiesto, anche se può esistere per
                            altri tipi di socket. \\
     \const{EAI\_ADDRFAMILY}& La rete richiesta non ha nessun indirizzo di rete
                            per la famiglia di indirizzi specificata. \\
     \const{EAI\_NODATA}  & La macchina specificata esiste, ma non ha nessun
                            indirizzo di rete definito. \\
-    \const{EAI\_MEMORY}  & È stato impossibile allocare la memoria necessaria
+    \const{EAI\_MEMORY}  & È stato impossibile allocare la memoria necessaria
                            alle operazioni. \\
     \const{EAI\_FAIL}    & Il DNS ha restituito un errore di risoluzione  
                            permanente. \\
     \const{EAI\_AGAIN}   & Il DNS ha restituito un errore di risoluzione  
-                           temporaneo, si può ritentare in seguito. \\
-    \const{EAI\_SYSTEM}  & C'è stato un errore di sistema, si può controllare
+                           temporaneo, si può ritentare in seguito. \\
+    \const{EAI\_SYSTEM}  & C'è stato un errore di sistema, si può controllare
                            \var{errno} per i dettagli. \\
 %    \hline
 % TODO estensioni GNU, trovarne la documentazione
 %    \const{EAI\_INPROGRESS}& Richiesta in corso. \\
-%    \const{EAI\_CANCELED}& La richiesta è stata cancellata.\\
-%    \const{EAI\_NOTCANCELED}& La richiesta non è stata cancellata. \\
+%    \const{EAI\_CANCELED}& La richiesta è stata cancellata.\\
+%    \const{EAI\_NOTCANCELED}& La richiesta non è stata cancellata. \\
 %    \const{EAI\_ALLDONE} & Tutte le richieste sono complete. \\
 %    \const{EAI\_INTR}    & Richiesta interrotta. \\
     \hline
@@ -1442,10 +1442,10 @@ corrispondente 
   \label{tab:addrinfo_error_code}
 \end{table}
 
-Come per i codici di errore di \func{gethostbyname} anche in questo caso è
+Come per i codici di errore di \func{gethostbyname} anche in questo caso è
 fornita una apposita funzione, analoga di \func{strerror}, che consente di
 utilizzarli direttamente per stampare a video un messaggio esplicativo; la
-funzione è \func{gai\_strerror} ed il suo prototipo è:
+funzione è \func{gai\_strerror} ed il suo prototipo è:
 \begin{functions}
   \headdecl{netdb.h} 
 
@@ -1459,18 +1459,18 @@ funzione 
 
 La funzione restituisce un puntatore alla stringa contenente il messaggio
 corrispondente dal codice di errore \param{errcode} ottenuto come valore di
-ritorno di \func{getaddrinfo}.  La stringa è allocata staticamente, ma essendo
+ritorno di \func{getaddrinfo}.  La stringa è allocata staticamente, ma essendo
 costante, ed accessibile in sola lettura, questo non comporta nessun problema
 di rientranza della funzione.
 
-Dato che ad un certo nome a dominio possono corrispondere più indirizzi IP
-(sia IPv4 che IPv6), e che un certo servizio può essere fornito su protocolli
+Dato che ad un certo nome a dominio possono corrispondere più indirizzi IP
+(sia IPv4 che IPv6), e che un certo servizio può essere fornito su protocolli
 e tipi di socket diversi, in generale, a meno di non aver eseguito una
-selezione specifica attraverso l'uso di \param{hints}, si otterrà una diversa
-struttura \struct{addrinfo} per ciascuna possibilità.  Ad esempio se si
+selezione specifica attraverso l'uso di \param{hints}, si otterrà una diversa
+struttura \struct{addrinfo} per ciascuna possibilità.  Ad esempio se si
 richiede la risoluzione del servizio \textit{echo} per l'indirizzo
 \texttt{www.truelite.it}, e si imposta \const{AI\_CANONNAME} per avere anche
-la risoluzione del nome canonico, si avrà come risposta della funzione la
+la risoluzione del nome canonico, si avrà come risposta della funzione la
 lista illustrata in fig.~\ref{fig:sock_addrinfo_list}.
 
 \begin{figure}[!htb]
@@ -1483,11 +1483,11 @@ lista illustrata in fig.~\ref{fig:sock_addrinfo_list}.
 
 Come primo esempio di uso di \func{getaddrinfo} vediamo un programma
 elementare di interrogazione del \itindex{resolver} \textit{resolver} basato
-questa funzione, il cui corpo principale è riportato in
+questa funzione, il cui corpo principale è riportato in
 fig.~\ref{fig:mygetaddr_example}. Il codice completo del programma, compresa
-la gestione delle opzioni in cui è gestita l'eventuale inizializzazione
+la gestione delle opzioni in cui è gestita l'eventuale inizializzazione
 dell'argomento \var{hints} per restringere le ricerche su protocolli, tipi di
-socket o famiglie di indirizzi, è disponibile nel file \texttt{mygetaddr.c}
+socket o famiglie di indirizzi, è disponibile nel file \texttt{mygetaddr.c}
 dei sorgenti allegati alla guida.
 
 \begin{figure}[!htb]
@@ -1508,53 +1508,53 @@ successivo controllo (\texttt{\small 8--11}) del suo corretto funzionamento,
 senza il quale si esce immediatamente stampando il relativo codice di errore.
 
 Se la funzione ha restituito un valore nullo il programma prosegue
-inizializzando (\texttt{\small 12}) il puntatore \var{ptr} che sarà usato nel
+inizializzando (\texttt{\small 12}) il puntatore \var{ptr} che sarà usato nel
 successivo ciclo (\texttt{\small 14--35}) di scansione della lista delle
 strutture \struct{addrinfo} restituite dalla funzione. Prima di eseguire
 questa scansione (\texttt{\small 12}) viene stampato il valore del nome
-canonico che è presente solo nella prima struttura.
+canonico che è presente solo nella prima struttura.
 
 La scansione viene ripetuta (\texttt{\small 14}) fintanto che si ha un
-puntatore valido. La selezione principale è fatta sul campo \var{ai\_family},
+puntatore valido. La selezione principale è fatta sul campo \var{ai\_family},
 che stabilisce a quale famiglia di indirizzi fa riferimento la struttura in
-esame. Le possibilità sono due, un indirizzo IPv4 o IPv6, se nessuna delle due
+esame. Le possibilità sono due, un indirizzo IPv4 o IPv6, se nessuna delle due
 si verifica si provvede (\texttt{\small 27--30}) a stampare un messaggio di
-errore ed uscire.\footnote{questa eventualità non dovrebbe mai verificarsi,
+errore ed uscire.\footnote{questa eventualità non dovrebbe mai verificarsi,
   almeno fintanto che la funzione \func{getaddrinfo} lavora correttamente.}
 
 Per ciascuno delle due possibili famiglie di indirizzi si estraggono le
 informazioni che poi verranno stampate alla fine del ciclo (\texttt{\small
-  31--34}). Il primo caso esaminato (\texttt{\small 15--21}) è quello degli
+  31--34}). Il primo caso esaminato (\texttt{\small 15--21}) è quello degli
 indirizzi IPv4, nel qual caso prima se ne stampa l'identificazione
 (\texttt{\small 16}) poi si provvede a ricavare la struttura degli indirizzi
 (\texttt{\small 17}) indirizzata dal campo \var{ai\_addr}, eseguendo un
 opportuno casting del puntatore per poter estrarre da questa la porta
-(\texttt{\small 18}) e poi l'indirizzo (\texttt{\small 19}) che verrà
+(\texttt{\small 18}) e poi l'indirizzo (\texttt{\small 19}) che verrà
 convertito con una chiamata ad \func{inet\_ntop}.
 
 La stessa operazione (\texttt{\small 21--27}) viene ripetuta per gli indirizzi
 IPv6, usando la rispettiva struttura degli indirizzi. Si noti anche come in
 entrambi i casi per la chiamata a \func{inet\_ntop} si sia dovuto passare il
 puntatore al campo contenente l'indirizzo IP nella struttura puntata dal campo
-\var{ai\_addr}.\footnote{il meccanismo è complesso a causa del fatto che al
-  contrario di IPv4, in cui l'indirizzo IP può essere espresso con un semplice
+\var{ai\_addr}.\footnote{il meccanismo è complesso a causa del fatto che al
+  contrario di IPv4, in cui l'indirizzo IP può essere espresso con un semplice
   numero intero, in IPv6 questo deve essere necessariamente fornito come
   struttura, e pertanto anche se nella struttura puntata da \var{ai\_addr}
   sono presenti direttamente i valori finali, per l'uso con \func{inet\_ntop}
   occorre comunque passare un puntatore agli stessi (ed il costrutto
-  \code{\&addr6->sin6\_addr} è corretto in quanto l'operatore \texttt{->} ha
+  \code{\&addr6->sin6\_addr} è corretto in quanto l'operatore \texttt{->} ha
   on questo caso precedenza su \texttt{\&}).}
 
 Una volta estratte dalla struttura \struct{addrinfo} tutte le informazioni
 relative alla risoluzione richiesta e stampati i relativi valori, l'ultimo
-passo (\texttt{\small 34}) è di estrarre da \var{ai\_next} l'indirizzo della
+passo (\texttt{\small 34}) è di estrarre da \var{ai\_next} l'indirizzo della
 eventuale successiva struttura presente nella lista e ripetere il ciclo, fin
-tanto che, completata la scansione, questo avrà un valore nullo e si potrà
+tanto che, completata la scansione, questo avrà un valore nullo e si potrà
 terminare (\texttt{\small 36}) il programma.
 
 Si tenga presente che \func{getaddrinfo} non garantisce nessun particolare
 ordinamento della lista delle strutture \struct{addrinfo} restituite, anche se
-usualmente i vari indirizzi IP (se ne è presente più di uno) sono forniti
+usualmente i vari indirizzi IP (se ne è presente più di uno) sono forniti
 nello stesso ordine in cui vengono inviati dal server DNS. In particolare
 nulla garantisce che vengano forniti prima i dati relativi ai servizi di un
 determinato protocollo o tipo di socket, se ne sono presenti di diversi.  Se
@@ -1574,9 +1574,9 @@ IPv4 address:
 %$
 
 Una volta estratti i risultati dalla \itindex{linked~list} \textit{linked list}
-puntata da \param{res} se questa non viene più utilizzata si dovrà avere cura
+puntata da \param{res} se questa non viene più utilizzata si dovrà avere cura
 di disallocare opportunamente tutta la memoria, per questo viene fornita
-l'apposita funzione \funcd{freeaddrinfo}, il cui prototipo è:
+l'apposita funzione \funcd{freeaddrinfo}, il cui prototipo è:
 \begin{functions}
   \headdecl{netdb.h} 
 
@@ -1597,14 +1597,14 @@ Si tenga presente infine che se si copiano i risultati da una delle strutture
 \struct{addrinfo} restituite nella lista indicizzata da \param{res}, occorre
 avere cura di eseguire una \itindex{deep~copy} \textit{deep copy} in cui
 si copiano anche tutti i dati presenti agli indirizzi contenuti nella
-struttura \struct{addrinfo}, perché una volta disallocati i dati con
-\func{freeaddrinfo} questi non sarebbero più disponibili. 
+struttura \struct{addrinfo}, perché una volta disallocati i dati con
+\func{freeaddrinfo} questi non sarebbero più disponibili. 
 
 Anche la nuova interfaccia definita da POSIX prevede una nuova funzione per
 eseguire la risoluzione inversa e determinare nomi di servizi e di dominio
 dati i rispettivi valori numerici. La funzione che sostituisce le varie
-\func{gethostbyname}, \func{getipnodebyname} e \func{getservname} è
-\funcd{getnameinfo}, ed il suo prototipo è:
+\func{gethostbyname}, \func{getipnodebyname} e \func{getservname} è
+\funcd{getnameinfo}, ed il suo prototipo è:
 \begin{functions}
   \headdecl{sys/socket.h}
   \headdecl{netdb.h}
@@ -1619,21 +1619,21 @@ dati i rispettivi valori numerici. La funzione che sostituisce le varie
     errore diverso da zero altrimenti.}
 \end{functions}
 
-La principale caratteristica di \func{getnameinfo} è che la funzione è in
+La principale caratteristica di \func{getnameinfo} è che la funzione è in
 grado di eseguire una risoluzione inversa in maniera indipendente dal
-protocollo; il suo primo argomento \param{sa} infatti è il puntatore ad una
-struttura degli indirizzi generica, che può contenere sia indirizzi IPv4 che
+protocollo; il suo primo argomento \param{sa} infatti è il puntatore ad una
+struttura degli indirizzi generica, che può contenere sia indirizzi IPv4 che
 IPv6, la cui dimensione deve comunque essere specificata con l'argomento
 \param{salen}. 
 
 I risultati della funzione saranno restituiti nelle due stringhe puntate da
 \param{host} e \param{serv}, che dovranno essere state precedentemente
 allocate per una lunghezza massima che deve essere specificata con gli altri
-due argomenti \param{hostlen} e \param{servlen}. Si può, quando non si è
+due argomenti \param{hostlen} e \param{servlen}. Si può, quando non si è
 interessati ad uno dei due, passare il valore \const{NULL} come argomento,
-così che la corrispondente informazione non verrà richiesta. Infine l'ultimo
-argomento \param{flags} è una maschera binaria i cui bit consentono di
-impostare le modalità con cui viene eseguita la ricerca, e deve essere
+così che la corrispondente informazione non verrà richiesta. Infine l'ultimo
+argomento \param{flags} è una maschera binaria i cui bit consentono di
+impostare le modalità con cui viene eseguita la ricerca, e deve essere
 specificato attraverso l'OR aritmetico dei valori illustrati in
 tab.~\ref{tab:getnameinfo_flags}.
 
@@ -1650,9 +1650,9 @@ tab.~\ref{tab:getnameinfo_flags}.
                              nome completo (FQDN).\\
     \const{NI\_NUMERICHOST}& Richiede che venga restituita la forma numerica
                              dell'indirizzo (questo succede sempre se il nome
-                             non può essere ottenuto).\\ 
+                             non può essere ottenuto).\\ 
     \const{NI\_NAMEREQD}   & Richiede la restituzione di un errore se il nome
-                             non può essere risolto.\\
+                             non può essere risolto.\\
     \const{NI\_NUMERICSERV}& Richiede che il servizio venga restituito in
                              forma numerica (attraverso il numero di porta).\\
     \const{NI\_DGRAM}      & Richiede che venga restituito il nome del
@@ -1680,18 +1680,18 @@ tab.~\ref{tab:addrinfo_error_code}.
 A questo punto possiamo fornire degli esempi di utilizzo della nuova
 interfaccia, adottandola per le precedenti implementazioni del client e del
 server per il servizio \textit{echo}; dato che l'uso delle funzioni appena
-illustrate (in particolare di \func{getaddrinfo}) è piuttosto complesso,
+illustrate (in particolare di \func{getaddrinfo}) è piuttosto complesso,
 essendo necessaria anche una impostazione diretta dei campi dell'argomento
 \param{hints}, provvederemo una interfaccia semplificata per i due casi visti
 finora, quello in cui si specifica nel client un indirizzo remoto per la
 connessione al server, e quello in cui si specifica nel server un indirizzo
 locale su cui porsi in ascolto.
 
-La prima funzione della nostra interfaccia semplificata è \func{sockconn} che
+La prima funzione della nostra interfaccia semplificata è \func{sockconn} che
 permette di ottenere un socket, connesso all'indirizzo ed al servizio
-specificati. Il corpo della funzione è riportato in
-fig.~\ref{fig:sockconn_code}, il codice completo è nel file \file{SockUtil.c}
-dei sorgenti allegati alla guida, che contiene varie funzioni di utilità per
+specificati. Il corpo della funzione è riportato in
+fig.~\ref{fig:sockconn_code}, il codice completo è nel file \file{SockUtil.c}
+dei sorgenti allegati alla guida, che contiene varie funzioni di utilità per
 l'uso dei socket.
 
 \begin{figure}[!htb]
@@ -1706,15 +1706,15 @@ l'uso dei socket.
 
 La funzione prende quattro argomenti, i primi due sono le stringhe che
 indicano il nome della macchina a cui collegarsi ed il relativo servizio su
-cui sarà effettuata la risoluzione; seguono il protocollo da usare (da
+cui sarà effettuata la risoluzione; seguono il protocollo da usare (da
 specificare con il valore numerico di \conffile{/etc/protocols}) ed il tipo di
 socket (al solito specificato con i valori illustrati in
 sez.~\ref{sec:sock_type}).  La funzione ritorna il valore del file descriptor
 associato al socket (un numero positivo) in caso di successo, o -1 in caso di
 errore; per risolvere il problema di non poter passare indietro i valori di
 ritorno di \func{getaddrinfo} contenenti i relativi codici di
-errore\footnote{non si può avere nessuna certezza che detti valori siano
-  negativi, è questo è invece necessario per evitare ogni possibile ambiguità
+errore\footnote{non si può avere nessuna certezza che detti valori siano
+  negativi, è questo è invece necessario per evitare ogni possibile ambiguità
   nei confronti del valore di ritorno in caso di successo.} si sono stampati i
 messaggi d'errore direttamente nella funzione.
 
@@ -1724,8 +1724,8 @@ provvede (\texttt{\small 7--9}) ad inizializzarne i valori necessari per la
 chiamata (\texttt{\small 10}) a \func{getaddrinfo}. Di quest'ultima si
 controlla (\texttt{\small 12-16}) il codice di ritorno, in modo da stampare un
 avviso di errore, azzerare \var{errno} ed uscire in caso di errore.  Dato che
-ad una macchina possono corrispondere più indirizzi IP, e di tipo diverso (sia
-IPv4 che IPv6), mentre il servizio può essere in ascolto soltanto su uno solo
+ad una macchina possono corrispondere più indirizzi IP, e di tipo diverso (sia
+IPv4 che IPv6), mentre il servizio può essere in ascolto soltanto su uno solo
 di questi, si provvede a tentare la connessione per ciascun indirizzo
 restituito all'interno di un ciclo (\texttt{\small 18-40}) di scansione della
 lista restituita da \func{getaddrinfo}, ma prima (\texttt{\small 17}) si salva
@@ -1741,9 +1741,9 @@ l'errore ritornando immediatamente (\texttt{\small 24-27}). Quando la
 creazione del socket ha avuto successo si procede (\texttt{\small 29})
 direttamente con la connessione, di nuovo in caso di fallimento viene ripetuto
 (\texttt{\small 30--38}) il controllo se vi sono o no altri indirizzi da
-provare nella stessa modalità fatta in precedenza, aggiungendovi però in
+provare nella stessa modalità fatta in precedenza, aggiungendovi però in
 entrambi i casi (\texttt{\small 32} e (\texttt{\small 36}) la chiusura del
-socket precedentemente aperto, che non è più utilizzabile.
+socket precedentemente aperto, che non è più utilizzabile.
 
 Se la connessione ha avuto successo invece si termina (\texttt{\small 39})
 direttamente il ciclo, e prima di ritornare (\texttt{\small 31}) il valore del
@@ -1769,12 +1769,12 @@ Per usare questa funzione possiamo allora modificare ulteriormente il nostro
 programma client per il servizio \textit{echo}; in questo caso rispetto al
 codice usato finora per collegarsi (vedi fig.~\ref{fig:TCP_echo_client_1})
 avremo una semplificazione per cui il corpo principale del nostro client
-diventerà quello illustrato in fig.~\ref{fig:TCP_echo_fifth}, in cui le
+diventerà quello illustrato in fig.~\ref{fig:TCP_echo_fifth}, in cui le
 chiamate a \func{socket}, \func{inet\_pton} e \func{connect} sono sostituite
 da una singola chiamata a \func{sockconn}. Inoltre il nuovo client (il cui
-codice completo è nel file \file{TCP\_echo\_fifth.c} dei sorgenti allegati)
+codice completo è nel file \file{TCP\_echo\_fifth.c} dei sorgenti allegati)
 consente di utilizzare come argomento del programma un nome a dominio al posto
-dell'indirizzo numerico, e può utilizzare sia indirizzi IPv4 che IPv6.
+dell'indirizzo numerico, e può utilizzare sia indirizzi IPv4 che IPv6.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -1786,42 +1786,42 @@ dell'indirizzo numerico, e pu
   \label{fig:sockbind_code}
 \end{figure}
 
-La seconda funzione di ausilio è \func{sockbind}, il cui corpo principale è
-riportato in fig.~\ref{fig:sockbind_code} (al solito il sorgente completo è
-nel file \file{sockbind.c} dei sorgenti allegati alla guida). Come si può
-notare la funzione è del tutto analoga alla precedente \func{sockconn}, e
-prende gli stessi argomenti, però invece di eseguire una connessione con
+La seconda funzione di ausilio è \func{sockbind}, il cui corpo principale è
+riportato in fig.~\ref{fig:sockbind_code} (al solito il sorgente completo è
+nel file \file{sockbind.c} dei sorgenti allegati alla guida). Come si può
+notare la funzione è del tutto analoga alla precedente \func{sockconn}, e
+prende gli stessi argomenti, però invece di eseguire una connessione con
 \func{connect} si limita a chiamare \func{bind} per collegare il socket ad una
 porta.
 
-Dato che la funzione è pensata per essere utilizzata da un server ci si può
+Dato che la funzione è pensata per essere utilizzata da un server ci si può
 chiedere a quale scopo mantenere l'argomento \param{host} quando l'indirizzo
-di questo è usualmente noto. Si ricordi però quanto detto in
+di questo è usualmente noto. Si ricordi però quanto detto in
 sez.~\ref{sec:TCP_func_bind}, relativamente al significato della scelta di un
 indirizzo specifico come argomento di \func{bind}, che consente di porre il
 server in ascolto su uno solo dei possibili diversi indirizzi presenti su di
 una macchina.  Se non si vuole che la funzione esegua \func{bind} su un
-indirizzo specifico, ma utilizzi l'indirizzo generico, occorrerà avere cura di
+indirizzo specifico, ma utilizzi l'indirizzo generico, occorrerà avere cura di
 passare un valore \const{NULL} come valore per l'argomento \var{host}; l'uso
 del valore \const{AI\_PASSIVE} serve ad ottenere il valore generico nella
 rispettiva struttura degli indirizzi.
 
-Come già detto la funzione è analoga a \func{sockconn} ed inizia azzerando ed
+Come già detto la funzione è analoga a \func{sockconn} ed inizia azzerando ed
 inizializzando (\texttt{\small 6-11}) opportunamente la struttura \var{hint}
-con i valori ricevuti come argomenti, soltanto che in questo caso si è usata
+con i valori ricevuti come argomenti, soltanto che in questo caso si è usata
 (\texttt{\small 8}) una impostazione specifica dei flag di \var{hint} usando
-\const{AI\_PASSIVE} per indicare che il socket sarà usato per una apertura
+\const{AI\_PASSIVE} per indicare che il socket sarà usato per una apertura
 passiva. Per il resto la chiamata (\texttt{\small 12-18}) a \func{getaddrinfo}
-e ed il ciclo principale (\texttt{\small 20--42}) sono identici, solo che si è
+e ed il ciclo principale (\texttt{\small 20--42}) sono identici, solo che si è
 sostituita (\texttt{\small 31}) la chiamata a \func{connect} con una chiamata
-a \func{bind}. Anche la conclusione (\texttt{\small 43--44}) della funzione è
+a \func{bind}. Anche la conclusione (\texttt{\small 43--44}) della funzione è
 identica. 
 
 Si noti come anche in questo caso si siano inserite le stampe degli errori
 sullo standard error, nonostante la funzione possa essere invocata da un
-demone. Nel nostro caso questo non è un problema in quanto se la funzione non
+demone. Nel nostro caso questo non è un problema in quanto se la funzione non
 ha successo il programma deve uscire immediatamente prima di essere posto in
-background, e può quindi scrivere gli errori direttamente sullo standard
+background, e può quindi scrivere gli errori direttamente sullo standard
 error.
 
 \begin{figure}[!htb]
@@ -1834,7 +1834,7 @@ error.
   \label{fig:TCP_echod_third}
 \end{figure}
 
-Con l'uso di questa funzione si può modificare anche il codice del nostro
+Con l'uso di questa funzione si può modificare anche il codice del nostro
 server \textit{echo}, che rispetto a quanto illustrato nella versione iniziale
 di fig.~\ref{fig:TCP_echo_server_first_code} viene modificato nella forma
 riportata in fig.~\ref{fig:TCP_echod_third}. In questo caso il socket su cui
@@ -1847,9 +1847,9 @@ quale si voglia far ascoltare il server.
 \section{Le opzioni dei socket}
 \label{sec:sock_options}
 
-Benché dal punto di vista del loro uso come canali di trasmissione di dati i
+Benché dal punto di vista del loro uso come canali di trasmissione di dati i
 socket siano trattati allo stesso modo dei file, ed acceduti tramite i file
-descriptor, la normale interfaccia usata per la gestione dei file non è
+descriptor, la normale interfaccia usata per la gestione dei file non è
 sufficiente a poterne controllare tutte le caratteristiche, che variano tra
 l'altro a seconda del loro tipo (e della relativa forma di comunicazione
 sottostante). In questa sezione vedremo allora quali sono le funzioni dedicate
@@ -1863,8 +1863,8 @@ cosiddette \textit{socket options}.
 Le varie caratteristiche dei socket possono essere gestite attraverso l'uso di
 due funzioni generiche che permettono rispettivamente di impostarle e di
 recuperarne il valore corrente. La prima di queste due funzioni, quella usata
-per impostare le \textit{socket options}, è \funcd{setsockopt}, ed il suo
-prototipo è:
+per impostare le \textit{socket options}, è \funcd{setsockopt}, ed il suo
+prototipo è:
 \begin{functions}
   \headdecl{sys/socket.h}
   \headdecl{sys/types.h}
@@ -1874,11 +1874,11 @@ prototipo 
   Imposta le opzioni di un socket.
 
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
-  \item[\errcode{EBADF}]  il file descriptor \param{sock} non è valido.
-  \item[\errcode{EFAULT}] l'indirizzo \param{optval} non è valido.
-  \item[\errcode{EINVAL}] il valore di \param{optlen} non è valido.
+  \item[\errcode{EBADF}]  il file descriptor \param{sock} non è valido.
+  \item[\errcode{EFAULT}] l'indirizzo \param{optval} non è valido.
+  \item[\errcode{EINVAL}] il valore di \param{optlen} non è valido.
   \item[\errcode{ENOPROTOOPT}] l'opzione scelta non esiste per il livello
     indicato. 
   \item[\errcode{ENOTSOCK}] il file descriptor \param{sock} non corrisponde ad
@@ -1892,8 +1892,8 @@ Il primo argomento della funzione, \param{sock}, indica il socket su cui si
 intende operare; per indicare l'opzione da impostare si devono usare i due
 argomenti successivi, \param{level} e \param{optname}.  Come abbiamo visto in
 sez.~\ref{sec:net_protocols} i protocolli di rete sono strutturati su vari
-livelli, ed l'interfaccia dei socket può usarne più di uno. Si avranno allora
-funzionalità e caratteristiche diverse per ciascun protocollo usato da un
+livelli, ed l'interfaccia dei socket può usarne più di uno. Si avranno allora
+funzionalità e caratteristiche diverse per ciascun protocollo usato da un
 socket, e quindi saranno anche diverse le opzioni che si potranno impostare
 per ciascun socket, a seconda del \textsl{livello} (trasporto, rete, ecc.) su
 cui si vuole andare ad operare.
@@ -1902,26 +1902,26 @@ Il valore di \param{level} seleziona allora il protocollo su cui vuole
 intervenire, mentre \param{optname} permette di scegliere su quale delle
 opzioni che sono definite per quel protocollo si vuole operare. In sostanza la
 selezione di una specifica opzione viene fatta attraverso una coppia di valori
-\param{level} e \param{optname} e chiaramente la funzione avrà successo
-soltanto se il protocollo in questione prevede quella opzione ed è utilizzato
+\param{level} e \param{optname} e chiaramente la funzione avrà successo
+soltanto se il protocollo in questione prevede quella opzione ed è utilizzato
 dal socket.  Infine \param{level} prevede anche il valore speciale
 \const{SOL\_SOCKET} usato per le opzioni generiche che sono disponibili per
 qualunque tipo di socket.
 
 I valori usati per \param{level}, corrispondenti ad un dato protocollo usato
 da un socket, sono quelli corrispondenti al valore numerico che identifica il
-suddetto protocollo in \conffile{/etc/protocols}; dato che la leggibilità di un
+suddetto protocollo in \conffile{/etc/protocols}; dato che la leggibilità di un
 programma non trarrebbe certo beneficio dall'uso diretto dei valori numerici,
-più comunemente si indica il protocollo tramite le apposite costanti
+più comunemente si indica il protocollo tramite le apposite costanti
 \texttt{SOL\_*} riportate in tab.~\ref{tab:sock_option_levels}, dove si sono
 riassunti i valori che possono essere usati per l'argomento
-\param{level}.\footnote{la notazione in questo caso è, purtroppo, abbastanza
-  confusa: infatti in Linux il valore si può impostare sia usando le costanti
+\param{level}.\footnote{la notazione in questo caso è, purtroppo, abbastanza
+  confusa: infatti in Linux il valore si può impostare sia usando le costanti
   \texttt{SOL\_*}, che le analoghe \texttt{IPPROTO\_*} (citate anche da
   Stevens in \cite{UNP1}); entrambe hanno gli stessi valori che sono
   equivalenti ai numeri di protocollo di \conffile{/etc/protocols}, con una
-  eccezione specifica, che è quella del protocollo ICMP, per la quale non
-  esista una costante, il che è comprensibile dato che il suo valore, 1, è
+  eccezione specifica, che è quella del protocollo ICMP, per la quale non
+  esista una costante, il che è comprensibile dato che il suo valore, 1, è
   quello che viene assegnato a \const{SOL\_SOCKET}.}
 
 \begin{table}[!htb]
@@ -1944,29 +1944,29 @@ riassunti i valori che possono essere usati per l'argomento
   \label{tab:sock_option_levels}
 \end{table}
 
-Il quarto argomento, \param{optval} è un puntatore ad una zona di memoria che
+Il quarto argomento, \param{optval} è un puntatore ad una zona di memoria che
 contiene i dati che specificano il valore dell'opzione che si vuole passare al
-socket, mentre l'ultimo argomento \param{optlen},\footnote{questo argomento è
-  in realtà sempre di tipo \ctyp{int}, come era nelle \acr{libc4} e
-  \acr{libc5}; l'uso di \ctyp{socklen\_t} è stato introdotto da POSIX (valgono
+socket, mentre l'ultimo argomento \param{optlen},\footnote{questo argomento è
+  in realtà sempre di tipo \ctyp{int}, come era nelle \acr{libc4} e
+  \acr{libc5}; l'uso di \ctyp{socklen\_t} è stato introdotto da POSIX (valgono
   le stesse considerazioni per l'uso di questo tipo di dato fatte in
-  sez.~\ref{sec:TCP_func_accept}) ed adottato dalle \acr{glibc}.} è la
+  sez.~\ref{sec:TCP_func_accept}) ed adottato dalle \acr{glibc}.} è la
 dimensione in byte dei dati presenti all'indirizzo indicato da \param{optval}.
-Dato che il tipo di dati varia a seconda dell'opzione scelta, occorrerà
-individuare qual è quello che deve essere usato, ed utilizzare le opportune
+Dato che il tipo di dati varia a seconda dell'opzione scelta, occorrerà
+individuare qual è quello che deve essere usato, ed utilizzare le opportune
 variabili.
 
 La gran parte delle opzioni utilizzano per \param{optval} un valore intero, se
-poi l'opzione esprime una condizione logica, il valore è sempre un intero, ma
-si dovrà usare un valore non nullo per abilitarla ed un valore nullo per
+poi l'opzione esprime una condizione logica, il valore è sempre un intero, ma
+si dovrà usare un valore non nullo per abilitarla ed un valore nullo per
 disabilitarla.  Se invece l'opzione non prevede di dover ricevere nessun tipo
 di valore si deve impostare \param{optval} a \const{NULL}. Un piccolo numero
-di opzioni però usano dei tipi di dati peculiari, è questo il motivo per cui
-\param{optval} è stato definito come puntatore generico.
+di opzioni però usano dei tipi di dati peculiari, è questo il motivo per cui
+\param{optval} è stato definito come puntatore generico.
 
-La seconda funzione usata per controllare le proprietà dei socket è
+La seconda funzione usata per controllare le proprietà dei socket è
 \funcd{getsockopt}, che serve a leggere i valori delle opzioni dei socket ed a
-farsi restituire i dati relativi al loro funzionamento; il suo prototipo è:
+farsi restituire i dati relativi al loro funzionamento; il suo prototipo è:
 \begin{functions}
   \headdecl{sys/socket.h}
   \headdecl{sys/types.h}
@@ -1975,11 +1975,11 @@ farsi restituire i dati relativi al loro funzionamento; il suo prototipo 
     socklen\_t *optlen)} Legge le opzioni di un socket.
 
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
-  \item[\errcode{EBADF}] il file descriptor \param{sock} non è valido.
+  \item[\errcode{EBADF}] il file descriptor \param{sock} non è valido.
   \item[\errcode{EFAULT}] l'indirizzo \param{optval} o quello di
-    \param{optlen} non è valido.
+    \param{optlen} non è valido.
   \item[\errcode{ENOPROTOOPT}] l'opzione scelta non esiste per il livello
     indicato. 
   \item[\errcode{ENOTSOCK}] il file descriptor \param{sock} non corrisponde ad
@@ -1989,7 +1989,7 @@ farsi restituire i dati relativi al loro funzionamento; il suo prototipo 
 \end{functions}
 
 I primi tre argomenti sono identici ed hanno lo stesso significato di quelli
-di \func{setsockopt}, anche se non è detto che tutte le opzioni siano definite
+di \func{setsockopt}, anche se non è detto che tutte le opzioni siano definite
 per entrambe le funzioni. In questo caso \param{optval} viene usato per
 ricevere le informazioni ed indica l'indirizzo a cui andranno scritti i dati
 letti dal socket, infine \param{optlen} diventa un puntatore ad una variabile
@@ -1997,8 +1997,8 @@ che viene usata come \itindex{value~result~argument} \textit{value result
   argument} per indicare, prima della chiamata della funzione, la lunghezza
 del buffer allocato per \param{optval} e per ricevere indietro, dopo la
 chiamata della funzione, la dimensione effettiva dei dati scritti su di esso.
-Se la dimensione del buffer allocato per \param{optval} non è sufficiente si
-avrà un errore.
+Se la dimensione del buffer allocato per \param{optval} non è sufficiente si
+avrà un errore.
 
 
 
@@ -2007,11 +2007,11 @@ avr
 
 Come accennato esiste un insieme generico di opzioni dei socket che possono
 applicarsi a qualunque tipo di socket,\footnote{una descrizione di queste
-  opzioni è generalmente disponibile nella settima sezione delle pagine di
-  manuale, nel caso specifico la si può consultare con \texttt{man 7 socket}.}
+  opzioni è generalmente disponibile nella settima sezione delle pagine di
+  manuale, nel caso specifico la si può consultare con \texttt{man 7 socket}.}
 indipendentemente da quale protocollo venga poi utilizzato. Se si vuole
-operare su queste opzioni generiche il livello da utilizzare è
-\const{SOL\_SOCKET}; si è riportato un elenco di queste opzioni in
+operare su queste opzioni generiche il livello da utilizzare è
+\const{SOL\_SOCKET}; si è riportato un elenco di queste opzioni in
 tab.~\ref{tab:sock_opt_socklevel}.
 
 
@@ -2025,7 +2025,7 @@ tab.~\ref{tab:sock_opt_socklevel}.
     \hline
     \hline
     \const{SO\_KEEPALIVE}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}& 
-                          Controlla l'attività della connessione.\\
+                          Controlla l'attività della connessione.\\
     \const{SO\_OOBINLINE}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}& 
                           Lascia in linea i dati \itindex{out-of-band}
                           \textit{out-of-band}.\\
@@ -2038,7 +2038,7 @@ tab.~\ref{tab:sock_opt_socklevel}.
     \const{SO\_SNDTIMEO} &$\bullet$&$\bullet$&         &\texttt{timeval}& 
                           Timeout in trasmissione.\\
     \const{SO\_BSDCOMPAT}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}& 
-                          Abilita la compatibilità con BSD.\\
+                          Abilita la compatibilità con BSD.\\
     \const{SO\_PASSCRED} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}& 
                           Abilita la ricezione di credenziali.\\
     \const{SO\_PEERCRED} &$\bullet$&         &         &\texttt{ucred}& 
@@ -2052,7 +2052,7 @@ tab.~\ref{tab:sock_opt_socklevel}.
     \const{SO\_TYPE}     &$\bullet$&         &         &\texttt{int}& 
                           Restituisce il tipo di socket.\\
     \const{SO\_ACCEPTCONN}&$\bullet$&        &         &\texttt{int}& 
-                          Indica se il socket è in ascolto.\\
+                          Indica se il socket è in ascolto.\\
     \const{SO\_DONTROUTE}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}& 
                           Non invia attraverso un gateway.\\
     \const{SO\_BROADCAST}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}& 
@@ -2065,7 +2065,7 @@ tab.~\ref{tab:sock_opt_socklevel}.
     \const{SO\_LINGER}   &$\bullet$&$\bullet$&         &\texttt{linger}&
                           Indugia nella chiusura con dati da spedire.\\
     \const{SO\_PRIORITY} &$\bullet$&$\bullet$&         &\texttt{int}& 
-                          Imposta la priorità del socket.\\
+                          Imposta la priorità del socket.\\
     \const{SO\_ERROR}    &$\bullet$&         &         &\texttt{int}& 
                           Riceve e cancella gli errori pendenti.\\
    \hline
@@ -2076,25 +2076,25 @@ tab.~\ref{tab:sock_opt_socklevel}.
 
 La tabella elenca le costanti che identificano le singole opzioni da usare
 come valore per \param{optname}; le due colonne seguenti indicano per quali
-delle due funzioni (\func{getsockopt} o \func{setsockopt}) l'opzione è
+delle due funzioni (\func{getsockopt} o \func{setsockopt}) l'opzione è
 disponibile, mentre la colonna successiva indica, quando di ha a che fare con
-un valore di \param{optval} intero, se l'opzione è da considerare un numero o
-un valore logico. Si è inoltre riportato sulla quinta colonna il tipo di dato
+un valore di \param{optval} intero, se l'opzione è da considerare un numero o
+un valore logico. Si è inoltre riportato sulla quinta colonna il tipo di dato
 usato per \param{optval} ed una breve descrizione del significato delle
 singole opzioni sulla sesta.
 
 Le descrizioni delle opzioni presenti in tab.~\ref{tab:sock_opt_socklevel}
-sono estremamente sommarie, è perciò necessario fornire un po' più di
+sono estremamente sommarie, è perciò necessario fornire un po' più di
 informazioni. Alcune opzioni inoltre hanno una notevole rilevanza nella
-gestione dei socket, e pertanto il loro utilizzo sarà approfondito
-separatamente in sez.~\ref{sec:sock_options_main}. Quello che segue è quindi
-soltanto un elenco più dettagliato della breve descrizione di
+gestione dei socket, e pertanto il loro utilizzo sarà approfondito
+separatamente in sez.~\ref{sec:sock_options_main}. Quello che segue è quindi
+soltanto un elenco più dettagliato della breve descrizione di
 tab.~\ref{tab:sock_opt_socklevel} sul significato delle varie opzioni:
 \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
 
 \item[\const{SO\_KEEPALIVE}] questa opzione abilita un meccanismo di verifica
-  della persistenza di una connessione associata al socket (ed è pertanto
-  effettiva solo sui socket che supportano le connessioni, ed è usata
+  della persistenza di una connessione associata al socket (ed è pertanto
+  effettiva solo sui socket che supportano le connessioni, ed è usata
   principalmente con il TCP). L'opzione utilizza per \param{optval} un intero
   usato come valore logico. Maggiori dettagli sul suo funzionamento sono
   forniti in sez.~\ref{sec:sock_options_main}.
@@ -2103,7 +2103,7 @@ tab.~\ref{tab:sock_opt_socklevel} sul significato delle varie opzioni:
   \itindex{out-of-band} \textit{out-of-band} vengono inviati direttamente nel
   flusso di dati del socket (e sono quindi letti con una normale \func{read})
   invece che restare disponibili solo per l'accesso con l'uso del flag
-  \const{MSG\_OOB} di \func{recvmsg}. L'argomento è trattato in dettaglio in
+  \const{MSG\_OOB} di \func{recvmsg}. L'argomento è trattato in dettaglio in
   sez.~\ref{sec:TCP_urgent_data}. L'opzione funziona soltanto con socket che
   supportino i dati \itindex{out-of-band} \textit{out-of-band} (non ha senso
   per socket UDP ad esempio), ed utilizza per \param{optval} un intero usato
@@ -2111,27 +2111,27 @@ tab.~\ref{tab:sock_opt_socklevel} sul significato delle varie opzioni:
 
 \item[\const{SO\_RCVLOWAT}] questa opzione imposta il valore che indica il
   numero minimo di byte che devono essere presenti nel buffer di ricezione
-  perché il kernel passi i dati all'utente, restituendoli ad una \func{read} o
+  perché il kernel passi i dati all'utente, restituendoli ad una \func{read} o
   segnalando ad una \func{select} (vedi sez.~\ref{sec:TCP_sock_select}) che ci
   sono dati in ingresso. L'opzione utilizza per \param{optval} un intero che
-  specifica il numero di byte, ma con Linux questo valore è sempre 1 e non può
-  essere cambiato; \func{getsockopt} leggerà questo valore mentre
-  \func{setsockopt} darà un errore di \errcode{ENOPROTOOPT}. 
+  specifica il numero di byte, ma con Linux questo valore è sempre 1 e non può
+  essere cambiato; \func{getsockopt} leggerà questo valore mentre
+  \func{setsockopt} darà un errore di \errcode{ENOPROTOOPT}. 
 
 \item[\const{SO\_SNDLOWAT}] questa opzione imposta il valore che indica il
   numero minimo di byte che devono essere presenti nel buffer di trasmissione
-  perché il kernel li invii al protocollo successivo, consentendo ad una
+  perché il kernel li invii al protocollo successivo, consentendo ad una
   \func{write} di ritornare o segnalando ad una \func{select} (vedi
-  sez.~\ref{sec:TCP_sock_select}) che è possibile eseguire una scrittura.
+  sez.~\ref{sec:TCP_sock_select}) che è possibile eseguire una scrittura.
   L'opzione utilizza per \param{optval} un intero che specifica il numero di
-  byte, come per la precedente \const{SO\_RCVLOWAT} con Linux questo valore è
-  sempre 1 e non può essere cambiato; \func{getsockopt} leggerà questo valore
-  mentre \func{setsockopt} darà un errore di \errcode{ENOPROTOOPT}.
+  byte, come per la precedente \const{SO\_RCVLOWAT} con Linux questo valore è
+  sempre 1 e non può essere cambiato; \func{getsockopt} leggerà questo valore
+  mentre \func{setsockopt} darà un errore di \errcode{ENOPROTOOPT}.
 
 \item[\const{SO\_RCVTIMEO}] l'opzione permette di impostare un tempo massimo
   sulle operazioni di lettura da un socket, e prende per \param{optval} una
   struttura di tipo \struct{timeval} (vedi fig.~\ref{fig:sys_timeval_struct})
-  identica a quella usata con \func{select}. Con \func{getsockopt} si può
+  identica a quella usata con \func{select}. Con \func{getsockopt} si può
   leggere il valore attuale, mentre con \func{setsockopt} si imposta il tempo
   voluto, usando un valore nullo per \struct{timeval} il timeout viene
   rimosso. 
@@ -2139,40 +2139,40 @@ tab.~\ref{tab:sock_opt_socklevel} sul significato delle varie opzioni:
   Se l'opzione viene attivata tutte le volte che una delle funzioni di lettura
   (\func{read}, \func{readv}, \func{recv}, \func{recvfrom} e \func{recvmsg})
   si blocca in attesa di dati per un tempo maggiore di quello impostato, essa
-  ritornerà un valore -1 e la variabile \var{errno} sarà impostata con un
-  errore di \errcode{EAGAIN} e \errcode{EWOULDBLOCK}, così come sarebbe
-  avvenuto se si fosse aperto il socket in modalità non bloccante.\footnote{in
+  ritornerà un valore -1 e la variabile \var{errno} sarà impostata con un
+  errore di \errcode{EAGAIN} e \errcode{EWOULDBLOCK}, così come sarebbe
+  avvenuto se si fosse aperto il socket in modalità non bloccante.\footnote{in
     teoria, se il numero di byte presenti nel buffer di ricezione fosse
     inferiore a quello specificato da \const{SO\_RCVLOWAT}, l'effetto potrebbe
     essere semplicemente quello di provocare l'uscita delle funzioni di
     lettura restituendo il numero di byte fino ad allora ricevuti; dato che
-    con Linux questo valore è sempre 1 questo caso non esiste.}
+    con Linux questo valore è sempre 1 questo caso non esiste.}
 
-  In genere questa opzione non è molto utilizzata se si ha a che fare con la
-  lettura dei dati, in quanto è sempre possibile usare una \func{select} che
+  In genere questa opzione non è molto utilizzata se si ha a che fare con la
+  lettura dei dati, in quanto è sempre possibile usare una \func{select} che
   consente di specificare un \textit{timeout}; l'uso di \func{select} non
-  consente però di impostare il timeout per l'uso di \func{connect}, per avere
-  il quale si può ricorrere a questa opzione. 
+  consente però di impostare il timeout per l'uso di \func{connect}, per avere
+  il quale si può ricorrere a questa opzione. 
 
 % TODO verificare il timeout con un programma di test
 
 \item[\const{SO\_SNDTIMEO}] l'opzione permette di impostare un tempo massimo
   sulle operazioni di scrittura su un socket, ed usa gli stessi valori di
-  \const{SO\_RCVTIMEO}.  In questo caso però si avrà un errore di
+  \const{SO\_RCVTIMEO}.  In questo caso però si avrà un errore di
   \errcode{EAGAIN} o \errcode{EWOULDBLOCK} per le funzioni di scrittura
   \func{write}, \func{writev}, \func{send}, \func{sendto} e \func{sendmsg}
   qualora queste restino bloccate per un tempo maggiore di quello specificato. 
 
-\item[\const{SO\_BSDCOMPAT}] questa opzione abilita la compatibilità con il
-  comportamento di BSD (in particolare ne riproduce i bug).  Attualmente è una
-  opzione usata solo per il protocollo UDP e ne è prevista la rimozione in
+\item[\const{SO\_BSDCOMPAT}] questa opzione abilita la compatibilità con il
+  comportamento di BSD (in particolare ne riproduce i bug).  Attualmente è una
+  opzione usata solo per il protocollo UDP e ne è prevista la rimozione in
   futuro.  L'opzione utilizza per \param{optval} un intero usato come valore
   logico. 
 
   Quando viene abilitata gli errori riportati da messaggi ICMP per un socket
   UDP non vengono passati al programma in user space. Con le versioni 2.0.x
   del kernel erano anche abilitate altre opzioni per i socket raw, che sono
-  state rimosse con il passaggio al 2.2; è consigliato correggere i programmi
+  state rimosse con il passaggio al 2.2; è consigliato correggere i programmi
   piuttosto che usare questa funzione. 
 
 \item[\const{SO\_PASSCRED}] questa opzione abilita sui socket unix-domain
@@ -2181,8 +2181,8 @@ tab.~\ref{tab:sock_opt_socklevel} sul significato delle varie opzioni:
   come valore logico.
 
 \item[\const{SO\_PEERCRED}] questa opzione restituisce le credenziali del
-  processo remoto connesso al socket; l'opzione è disponibile solo per socket
-  unix-domain e può essere usata solo con \func{getsockopt}.  Utilizza per
+  processo remoto connesso al socket; l'opzione è disponibile solo per socket
+  unix-domain e può essere usata solo con \func{getsockopt}.  Utilizza per
   \param{optval} una apposita struttura \struct{ucred} (vedi
   sez.~\ref{sec:unix_socket}). 
 
@@ -2191,53 +2191,53 @@ tab.~\ref{tab:sock_opt_socklevel} sul significato delle varie opzioni:
   inviare pacchetti solo su quella. L'opzione richiede per \param{optval} il
   puntatore ad una stringa contenente il nome dell'interfaccia (ad esempio
   \texttt{eth0}); utilizzando una stringa nulla o un valore nullo per
-  \param{optlen} si può rimuovere un precedente collegamento.
+  \param{optlen} si può rimuovere un precedente collegamento.
 
   Il nome della interfaccia deve essere specificato con una stringa terminata
-  da uno zero e di lunghezza massima pari a \const{IFNAMSIZ}; l'opzione è
+  da uno zero e di lunghezza massima pari a \const{IFNAMSIZ}; l'opzione è
   effettiva solo per alcuni tipi di socket, ed in particolare per quelli della
-  famiglia \const{AF\_INET}; non è invece supportata per i \textit{packet
+  famiglia \const{AF\_INET}; non è invece supportata per i \textit{packet
     socket} (vedi sez.~\ref{sec:socket_raw}). 
 
 \item[\const{SO\_DEBUG}] questa opzione abilita il debugging delle operazioni
   dei socket; l'opzione utilizza per \param{optval} un intero usato come
-  valore logico, e può essere utilizzata solo da un processo con i privilegi
+  valore logico, e può essere utilizzata solo da un processo con i privilegi
   di amministratore (in particolare con la \itindex{capabilities}
   \textit{capability} \const{CAP\_NET\_ADMIN}).  L'opzione necessita inoltre
-  dell'opportuno supporto nel kernel;\footnote{deve cioè essere definita la
+  dell'opportuno supporto nel kernel;\footnote{deve cioè essere definita la
     macro di preprocessore \macro{SOCK\_DEBUGGING} nel file
-    \file{include/net/sock.h} dei sorgenti del kernel, questo è sempre vero
+    \file{include/net/sock.h} dei sorgenti del kernel, questo è sempre vero
     nei kernel delle serie superiori alla 2.3, per i kernel delle serie
-    precedenti invece è necessario aggiungere a mano detta definizione; è
+    precedenti invece è necessario aggiungere a mano detta definizione; è
     inoltre possibile abilitare anche il tracciamento degli stati del TCP
     definendo la macro \macro{STATE\_TRACE} in \file{include/net/tcp.h}.}
   quando viene abilitata una serie di messaggi con le informazioni di debug
   vengono inviati direttamente al sistema del kernel log.\footnote{si tenga
-    presente che il comportamento è diverso da quanto avviene con BSD, dove
+    presente che il comportamento è diverso da quanto avviene con BSD, dove
     l'opzione opera solo sui socket TCP, causando la scrittura di tutti i
     pacchetti inviati sulla rete su un buffer circolare che viene letto da un
     apposito programma, \cmd{trpt}.}
 
 \item[\const{SO\_REUSEADDR}] questa opzione permette di eseguire la funzione
-  \func{bind} su indirizzi locali che siano già in uso da altri socket;
+  \func{bind} su indirizzi locali che siano già in uso da altri socket;
   l'opzione utilizza per \param{optval} un intero usato come valore logico.
   Questa opzione modifica il comportamento normale dell'interfaccia dei socket
   che fa fallire l'esecuzione della funzione \func{bind} con un errore di
-  \errcode{EADDRINUSE} quando l'indirizzo locale\footnote{più propriamente il
-    controllo viene eseguito sulla porta.} è già in uso da parte di un altro
+  \errcode{EADDRINUSE} quando l'indirizzo locale\footnote{più propriamente il
+    controllo viene eseguito sulla porta.} è già in uso da parte di un altro
   socket.  Maggiori dettagli sul suo funzionamento sono forniti in
   sez.~\ref{sec:sock_options_main}.
 
 \item[\const{SO\_TYPE}] questa opzione permette di leggere il tipo di socket
   su cui si opera; funziona solo con \func{getsockopt}, ed utilizza per
-  \param{optval} un intero in cui verrà restituito il valore numerico che lo
+  \param{optval} un intero in cui verrà restituito il valore numerico che lo
   identifica (ad esempio \const{SOCK\_STREAM}). 
 
 \item[\const{SO\_ACCEPTCONN}] questa opzione permette di rilevare se il socket
-  su cui opera è stato posto in modalità di ricezione di eventuali connessioni
-  con una chiamata a \func{listen}. L'opzione può essere usata soltanto con
+  su cui opera è stato posto in modalità di ricezione di eventuali connessioni
+  con una chiamata a \func{listen}. L'opzione può essere usata soltanto con
   \func{getsockopt} e utilizza per \param{optval} un intero in cui viene
-  restituito 1 se il socket è in ascolto e 0 altrimenti. 
+  restituito 1 se il socket è in ascolto e 0 altrimenti. 
 
 \item[\const{SO\_DONTROUTE}] questa opzione forza l'invio diretto dei
   pacchetti del socket, saltando ogni processo relativo all'uso della tabella
@@ -2260,20 +2260,20 @@ tab.~\ref{tab:sock_opt_socklevel} sul significato delle varie opzioni:
 
 \item[\const{SO\_RCVBUF}] questa opzione imposta la dimensione del buffer di
   ricezione del socket. Prende per \param{optval} un intero indicante il
-  numero di byte. Il valore di default ed il valore massimo che si può
+  numero di byte. Il valore di default ed il valore massimo che si può
   specificare come argomento per questa opzione sono impostabili tramiti gli
   opportuni valori di \func{sysctl} (vedi sez.~\ref{sec:sock_sysctl}).
 
   Si tenga presente che nel caso di socket TCP, per entrambe le opzioni
   \const{SO\_RCVBUF} e \const{SO\_SNDBUF}, il kernel alloca effettivamente una
-  quantità di memoria doppia rispetto a quanto richiesto con
+  quantità di memoria doppia rispetto a quanto richiesto con
   \func{setsockopt}. Questo comporta che una successiva lettura con
-  \func{getsockopt} riporterà un valore diverso da quello impostato con
-  \func{setsockopt}.  Questo avviene perché TCP necessita dello spazio in più
+  \func{getsockopt} riporterà un valore diverso da quello impostato con
+  \func{setsockopt}.  Questo avviene perché TCP necessita dello spazio in più
   per mantenere dati amministrativi e strutture interne, e solo una parte
   viene usata come buffer per i dati, mentre il valore letto da
   \func{getsockopt} e quello riportato nei vari parametri di
-  \textit{sysctl}\footnote{cioè \procrelfile{/proc/sys/net/core}{wmem\_max} e
+  \textit{sysctl}\footnote{cioè \procrelfile{/proc/sys/net/core}{wmem\_max} e
     \procrelfile{/proc/sys/net/core}{rmem\_max} in \texttt{/proc/sys/net/core}
     e \procrelfile{/proc/sys/net/ipv4}{tcp\_wmem} e
     \procrelfile{/proc/sys/net/ipv4}{tcp\_rmem} in
@@ -2283,31 +2283,31 @@ tab.~\ref{tab:sock_opt_socklevel} sul significato delle varie opzioni:
   essere effettive, devono essere impostate prima della chiamata alle funzioni
   \func{listen} o \func{connect}.
 
-\item[\const{SO\_LINGER}] questa opzione controlla le modalità con cui viene
+\item[\const{SO\_LINGER}] questa opzione controlla le modalità con cui viene
   chiuso un socket quando si utilizza un protocollo che supporta le
-  connessioni (è pertanto usata con i socket TCP ed ignorata per UDP) e
+  connessioni (è pertanto usata con i socket TCP ed ignorata per UDP) e
   modifica il comportamento delle funzioni \func{close} e \func{shutdown}.
   L'opzione richiede che l'argomento \param{optval} sia una struttura di tipo
   \struct{linger}, definita in \texttt{sys/socket.h} ed illustrata in
   fig.~\ref{fig:sock_linger_struct}.  Maggiori dettagli sul suo funzionamento
   sono forniti in sez.~\ref{sec:sock_options_main}.
 
-\item[\const{SO\_PRIORITY}] questa opzione permette di impostare le priorità
+\item[\const{SO\_PRIORITY}] questa opzione permette di impostare le priorità
   per tutti i pacchetti che sono inviati sul socket, prende per \param{optval}
   un valore intero. Con questa opzione il kernel usa il valore per ordinare le
-  priorità sulle code di rete,\footnote{questo richiede che sia abilitato il
+  priorità sulle code di rete,\footnote{questo richiede che sia abilitato il
     sistema di \textit{Quality of Service} disponibile con le opzioni di
-    routing avanzato.} i pacchetti con priorità più alta vengono processati
-  per primi, in modalità che dipendono dalla disciplina di gestione della
+    routing avanzato.} i pacchetti con priorità più alta vengono processati
+  per primi, in modalità che dipendono dalla disciplina di gestione della
   coda. Nel caso di protocollo IP questa opzione permette anche di impostare i
   valori del campo \textit{type of service} (noto come TOS, vedi
   sez.~\ref{sec:IP_header}) per i pacchetti uscenti. Per impostare una
-  priorità al di fuori dell'intervallo di valori fra 0 e 6 sono richiesti i
+  priorità al di fuori dell'intervallo di valori fra 0 e 6 sono richiesti i
   privilegi di amministratore con la \itindex{capabilities} capability
   \const{CAP\_NET\_ADMIN}.
 
 \item[\const{SO\_ERROR}] questa opzione riceve un errore presente sul socket;
-  può essere utilizzata soltanto con \func{getsockopt} e prende per
+  può essere utilizzata soltanto con \func{getsockopt} e prende per
   \param{optval} un valore intero, nel quale viene restituito il codice di
   errore, e la condizione di errore sul socket viene cancellata. Viene
   usualmente utilizzata per ricevere il codice di errore, come accennato in
@@ -2346,74 +2346,74 @@ tab.~\ref{tab:sock_opt_socklevel} sul significato delle varie opzioni:
 \label{sec:sock_options_main}
 
 La descrizione sintetica del significato delle opzioni generiche dei socket,
-riportata nell'elenco in sez.~\ref{sec:sock_generic_options}, è
-necessariamente sintetica, alcune di queste però possono essere utilizzate
-per controllare delle funzionalità che hanno una notevole rilevanza nella
+riportata nell'elenco in sez.~\ref{sec:sock_generic_options}, è
+necessariamente sintetica, alcune di queste però possono essere utilizzate
+per controllare delle funzionalità che hanno una notevole rilevanza nella
 programmazione dei socket.  Per questo motivo faremo in questa sezione un
-approfondimento sul significato delle opzioni generiche più importanti.
+approfondimento sul significato delle opzioni generiche più importanti.
 
 
 \index{costante!{SO\_KEEPALIVE}@{{\tt  {SO\_KEEPALIVE}}}|(}
 \subsubsection{L'opzione \const{SO\_KEEPALIVE}}
 
-La prima opzione da approfondire è \const{SO\_KEEPALIVE} che permette di
+La prima opzione da approfondire è \const{SO\_KEEPALIVE} che permette di
 tenere sotto controllo lo stato di una connessione. Una connessione infatti
-resta attiva anche quando non viene effettuato alcun traffico su di essa; è
+resta attiva anche quando non viene effettuato alcun traffico su di essa; è
 allora possibile, in caso di una interruzione completa della rete, che la
 caduta della connessione non venga rilevata, dato che sulla stessa non passa
 comunque alcun traffico.
 
-Se si imposta questa opzione, è invece cura del kernel inviare degli appositi
+Se si imposta questa opzione, è invece cura del kernel inviare degli appositi
 messaggi sulla rete, detti appunto \textit{keep-alive}, per verificare se la
-connessione è attiva.  L'opzione funziona soltanto con i socket che supportano
+connessione è attiva.  L'opzione funziona soltanto con i socket che supportano
 le connessioni (non ha senso per socket UDP ad esempio) e si applica
 principalmente ai socket TCP.
 
 Con le impostazioni di default (che sono riprese da BSD) Linux emette un
 messaggio di \textit{keep-alive}\footnote{in sostanza un segmento ACK vuoto,
-  cui sarà risposto con un altro segmento ACK vuoto.} verso l'altro capo della
-connessione se questa è rimasta senza traffico per più di due ore.  Se è tutto
-a posto il messaggio viene ricevuto e verrà emesso un segmento ACK di
-risposta, alla cui ricezione ripartirà un altro ciclo di attesa per altre due
-ore di inattività; il tutto avviene all'interno del kernel e le applicazioni
+  cui sarà risposto con un altro segmento ACK vuoto.} verso l'altro capo della
+connessione se questa è rimasta senza traffico per più di due ore.  Se è tutto
+a posto il messaggio viene ricevuto e verrà emesso un segmento ACK di
+risposta, alla cui ricezione ripartirà un altro ciclo di attesa per altre due
+ore di inattività; il tutto avviene all'interno del kernel e le applicazioni
 non riceveranno nessun dato.
 
 Qualora ci siano dei problemi di rete si possono invece verificare i due casi
-di terminazione precoce del server già illustrati in
-sez.~\ref{sec:TCP_conn_crash}. Il primo è quello in cui la macchina remota ha
-avuto un crollo del sistema ed è stata riavviata, per cui dopo il riavvio la
-connessione non esiste più.\footnote{si ricordi che un normale riavvio o il
+di terminazione precoce del server già illustrati in
+sez.~\ref{sec:TCP_conn_crash}. Il primo è quello in cui la macchina remota ha
+avuto un crollo del sistema ed è stata riavviata, per cui dopo il riavvio la
+connessione non esiste più.\footnote{si ricordi che un normale riavvio o il
   crollo dell'applicazione non ha questo effetto, in quanto in tal caso si
   passa sempre per la chiusura del processo, e questo, come illustrato in
   sez.~\ref{sec:file_close}, comporta anche la regolare chiusura del socket
   con l'invio di un segmento FIN all'altro capo della connessione.} In questo
-caso all'invio del messaggio di \textit{keep-alive} si otterrà come risposta
-un segmento RST che indica che l'altro capo non riconosce più l'esistenza
-della connessione ed il socket verrà chiuso riportando un errore di
+caso all'invio del messaggio di \textit{keep-alive} si otterrà come risposta
+un segmento RST che indica che l'altro capo non riconosce più l'esistenza
+della connessione ed il socket verrà chiuso riportando un errore di
 \errcode{ECONNRESET}.
 
-Se invece non viene ricevuta nessuna risposta (indice che la macchina non è
-più raggiungibile) l'emissione dei messaggi viene ripetuta ad intervalli di 75
+Se invece non viene ricevuta nessuna risposta (indice che la macchina non è
+più raggiungibile) l'emissione dei messaggi viene ripetuta ad intervalli di 75
 secondi per un massimo di 9 volte\footnote{entrambi questi valori possono
-  essere modificati a livello di sistema (cioè per tutti i socket) con gli
+  essere modificati a livello di sistema (cioè per tutti i socket) con gli
   opportuni parametri illustrati in sez.~\ref{sec:sock_sysctl} ed a livello di
   singolo socket con le opzioni \texttt{TCP\_KEEP*} di
   sez.~\ref{sec:sock_tcp_udp_options}.}  (per un totale di 11 minuti e 15
-secondi) dopo di che, se non si è ricevuta nessuna risposta, il socket viene
+secondi) dopo di che, se non si è ricevuta nessuna risposta, il socket viene
 chiuso dopo aver impostato un errore di \errcode{ETIMEDOUT}. Qualora la
 connessione si sia ristabilita e si riceva un successivo messaggio di risposta
 il ciclo riparte come se niente fosse avvenuto.  Infine se si riceve come
 risposta un pacchetto ICMP di destinazione irraggiungibile (vedi
-sez.~\ref{sec:ICMP_protocol}), verrà restituito l'errore corrispondente.
+sez.~\ref{sec:ICMP_protocol}), verrà restituito l'errore corrispondente.
 
 In generale questa opzione serve per individuare una caduta della connessione
 anche quando non si sta facendo traffico su di essa.  Viene usata
 principalmente sui server per evitare di mantenere impegnate le risorse che
-verrebbero dedicate a trattare delle connessioni che in realtà sono già
+verrebbero dedicate a trattare delle connessioni che in realtà sono già
 terminate (quelle che vengono anche chiamate connessioni
-\textsl{semi-aperte}); in tutti quei casi cioè in cui il server si trova in
-attesa di dati in ingresso su una connessione che non arriveranno mai o perché
-il client sull'altro capo non è più attivo o perché non è più in grado di
+\textsl{semi-aperte}); in tutti quei casi cioè in cui il server si trova in
+attesa di dati in ingresso su una connessione che non arriveranno mai o perché
+il client sull'altro capo non è più attivo o perché non è più in grado di
 comunicare con il server via rete.
 
 \begin{figure}[!htb]
@@ -2430,29 +2430,29 @@ comunicare con il server via rete.
 
 Abilitandola dopo un certo tempo le connessioni effettivamente terminate
 verranno comunque chiuse per cui, utilizzando ad esempio una \func{select}, se
-be potrà rilevare la conclusione e ricevere il relativo errore. Si tenga
-presente però che non può avere la certezza assoluta che un errore di
+be potrà rilevare la conclusione e ricevere il relativo errore. Si tenga
+presente però che non può avere la certezza assoluta che un errore di
 \errcode{ETIMEDOUT} ottenuto dopo aver abilitato questa opzione corrisponda
 necessariamente ad una reale conclusione della connessione, il problema
 potrebbe anche essere dovuto ad un problema di routing che perduri per un
 tempo maggiore di quello impiegato nei vari tentativi di ritrasmissione del
-\textit{keep-alive} (anche se questa non è una condizione molto probabile).
+\textit{keep-alive} (anche se questa non è una condizione molto probabile).
 
 Come esempio dell'utilizzo di questa opzione introduciamo all'interno del
 nostro server per il servizio \textit{echo} la nuova opzione \texttt{-k} che
 permette di attivare il \textit{keep-alive} sui socket; tralasciando la parte
 relativa alla gestione di detta opzione (che si limita ad assegnare ad 1 la
 variabile \var{keepalive}) tutte le modifiche al server sono riportate in
-fig.~\ref{fig:echod_keepalive_code}. Al solito il codice completo è contenuto
+fig.~\ref{fig:echod_keepalive_code}. Al solito il codice completo è contenuto
 nel file \texttt{TCP\_echod\_fourth.c} dei sorgenti allegati alla guida.
 
-Come si può notare la variabile \var{keepalive} è preimpostata (\texttt{\small
+Come si può notare la variabile \var{keepalive} è preimpostata (\texttt{\small
   8}) ad un valore nullo; essa viene utilizzata sia come variabile logica per
 la condizione (\texttt{\small 14}) che controlla l'attivazione del
 \textit{keep-alive} che come valore dell'argomento \param{optval} della
 chiamata a \func{setsockopt} (\texttt{\small 16}).  A seconda del suo valore
 tutte le volte che un processo figlio viene eseguito in risposta ad una
-connessione verrà pertanto eseguita o meno la sezione (\texttt{\small 14--17})
+connessione verrà pertanto eseguita o meno la sezione (\texttt{\small 14--17})
 che esegue l'impostazione di \const{SO\_KEEPALIVE} sul socket connesso,
 attivando il relativo comportamento.
 \index{costante!{SO\_KEEPALIVE}@{{\tt  {SO\_KEEPALIVE}}}|)}
@@ -2462,51 +2462,51 @@ attivando il relativo comportamento.
 \index{costante!{SO\_REUSEADDR}@{{\tt  {SO\_REUSEADDR}}}|(}
 \subsubsection{L'opzione \const{SO\_REUSEADDR}}
 
-La seconda opzione da approfondire è \const{SO\_REUSEADDR}, che consente di
-eseguire \func{bind} su un socket anche quando la porta specificata è già in
+La seconda opzione da approfondire è \const{SO\_REUSEADDR}, che consente di
+eseguire \func{bind} su un socket anche quando la porta specificata è già in
 uso da parte di un altro socket. Si ricordi infatti che, come accennato in
 sez.~\ref{sec:TCP_func_bind}, normalmente la funzione \func{bind} fallisce con
-un errore di \errcode{EADDRINUSE} se la porta scelta è già utilizzata da un
+un errore di \errcode{EADDRINUSE} se la porta scelta è già utilizzata da un
 altro socket, proprio per evitare che possano essere lanciati due server sullo
 stesso indirizzo e la stessa porta, che verrebbero a contendersi i pacchetti
 aventi quella destinazione.
 
-Esistono però situazioni ed esigenze particolari in cui non si vuole che
-questo comportamento di salvaguardia accada, ed allora si può fare ricorso a
-questa opzione.  La questione è comunque abbastanza complessa in quanto, come
+Esistono però situazioni ed esigenze particolari in cui non si vuole che
+questo comportamento di salvaguardia accada, ed allora si può fare ricorso a
+questa opzione.  La questione è comunque abbastanza complessa in quanto, come
 sottolinea Stevens in \cite{UNP1}, si distinguono ben quattro casi diversi in
-cui è prevista la possibilità di un utilizzo di questa opzione, il che la
-rende una delle più difficili da capire.
+cui è prevista la possibilità di un utilizzo di questa opzione, il che la
+rende una delle più difficili da capire.
 
-Il primo caso, che è anche il più comune, in cui si fa ricorso a
-\const{SO\_REUSEADDR} è quello in cui un server è terminato ma esistono ancora
+Il primo caso, che è anche il più comune, in cui si fa ricorso a
+\const{SO\_REUSEADDR} è quello in cui un server è terminato ma esistono ancora
 dei processi figli che mantengono attiva almeno una connessione remota che
 utilizza l'indirizzo locale, mantenendo occupata la porta. Quando si riesegue
 il server allora questo riceve un errore sulla chiamata a \func{bind} dato che
-la porta è ancora utilizzata in una connessione esistente.\footnote{questa è
-  una delle domande più frequenti sui newsgroup dedicati allo sviluppo, in
-  quanto è piuttosto comune trovarsi in questa situazione quando si sta
+la porta è ancora utilizzata in una connessione esistente.\footnote{questa è
+  una delle domande più frequenti sui newsgroup dedicati allo sviluppo, in
+  quanto è piuttosto comune trovarsi in questa situazione quando si sta
   sviluppando un server che si ferma e si riavvia in continuazione dopo aver
-  fatto modifiche.}  Inoltre se si usa il protocollo TCP questo può avvenire
-anche dopo tutti i processi figli sono terminati, dato che una connessione può
+  fatto modifiche.}  Inoltre se si usa il protocollo TCP questo può avvenire
+anche dopo tutti i processi figli sono terminati, dato che una connessione può
 restare attiva anche dopo la chiusura del socket, mantenendosi nello stato
 \texttt{TIME\_WAIT} (vedi sez.~\ref{sec:TCP_time_wait}).
 
 Usando \const{SO\_REUSEADDR} fra la chiamata a \func{socket} e quella a
 \func{bind} si consente a quest'ultima di avere comunque successo anche se la
-connessione è attiva (o nello stato \texttt{TIME\_WAIT}). È bene però
+connessione è attiva (o nello stato \texttt{TIME\_WAIT}). È bene però
 ricordare (si riveda quanto detto in sez.~\ref{sec:TCP_time_wait}) che la
 presenza dello stato \texttt{TIME\_WAIT} ha una ragione, ed infatti se si usa
-questa opzione esiste sempre una probabilità, anche se estremamente
-remota,\footnote{perché ciò avvenga infatti non solo devono coincidere gli
+questa opzione esiste sempre una probabilità, anche se estremamente
+remota,\footnote{perché ciò avvenga infatti non solo devono coincidere gli
   indirizzi IP e le porte degli estremi della nuova connessione, ma anche i
-  numeri di sequenza dei pacchetti, e questo è estremamente improbabile.}  che
+  numeri di sequenza dei pacchetti, e questo è estremamente improbabile.}  che
 eventuali pacchetti rimasti intrappolati in una precedente connessione possano
 finire fra quelli di una nuova.
 
 Come esempio di uso di questa connessione abbiamo predisposto una nuova
 versione della funzione \func{sockbind} (vedi fig.~\ref{fig:sockbind_code})
-che consenta l'impostazione di questa opzione. La nuova funzione è
+che consenta l'impostazione di questa opzione. La nuova funzione è
 \func{sockbindopt}, e le principali differenze rispetto alla precedente sono
 illustrate in fig.~\ref{fig:sockbindopt_code}, dove si sono riportate le
 sezioni di codice modificate rispetto alla versione precedente. Il codice
@@ -2525,28 +2525,28 @@ guida.
   \label{fig:sockbindopt_code}
 \end{figure}
 
-In realtà tutto quello che si è fatto è stato introdurre nella nuova funzione
-(\texttt{\small 1}) un nuovo argomento intero, \param{reuse}, che conterrà il
+In realtà tutto quello che si è fatto è stato introdurre nella nuova funzione
+(\texttt{\small 1}) un nuovo argomento intero, \param{reuse}, che conterrà il
 valore logico da usare nella successiva chiamata (\texttt{\small 14}) a
-\func{setsockopt}. Si è poi aggiunta una sezione (\texttt{\small 13-17}) che
+\func{setsockopt}. Si è poi aggiunta una sezione (\texttt{\small 13-17}) che
 esegue l'impostazione dell'opzione fra la chiamata a \func{socket} e quella a
 \func{bind}.
 
 
-A questo punto basterà modificare il  server per utilizzare la nuova
+A questo punto basterà modificare il  server per utilizzare la nuova
 funzione; in fig.~\ref{fig:TCP_echod_fifth} abbiamo riportato le sezioni
 modificate rispetto alla precedente versione di
-fig.~\ref{fig:TCP_echod_third}. Al solito il codice completo è coi sorgenti
+fig.~\ref{fig:TCP_echod_third}. Al solito il codice completo è coi sorgenti
 allegati alla guida, nel file \texttt{TCP\_echod\_fifth.c}.
 
-Anche in questo caso si è introdotta (\texttt{\small 8}) una nuova variabile
-\var{reuse} che consente di controllare l'uso dell'opzione e che poi sarà
+Anche in questo caso si è introdotta (\texttt{\small 8}) una nuova variabile
+\var{reuse} che consente di controllare l'uso dell'opzione e che poi sarà
 usata (\texttt{\small 14}) come ultimo argomento di \func{setsockopt}. Il
-valore di default di questa variabile è nullo, ma usando l'opzione \texttt{-r}
-nell'invocazione del server (al solito la gestione delle opzioni non è
-riportata in fig.~\ref{fig:TCP_echod_fifth}) se ne potrà impostare ad 1 il
+valore di default di questa variabile è nullo, ma usando l'opzione \texttt{-r}
+nell'invocazione del server (al solito la gestione delle opzioni non è
+riportata in fig.~\ref{fig:TCP_echod_fifth}) se ne potrà impostare ad 1 il
 valore, per cui in tal caso la successiva chiamata (\texttt{\small 13-17}) a
-\func{setsockopt} attiverà l'opzione \const{SO\_REUSEADDR}.
+\func{setsockopt} attiverà l'opzione \const{SO\_REUSEADDR}.
 
 \begin{figure}[!htb] 
   \footnotesize \centering
@@ -2559,78 +2559,78 @@ valore, per cui in tal caso la successiva chiamata (\texttt{\small 13-17}) a
   \label{fig:TCP_echod_fifth}
 \end{figure}
 
-Il secondo caso in cui viene usata \const{SO\_REUSEADDR} è quando si ha una
+Il secondo caso in cui viene usata \const{SO\_REUSEADDR} è quando si ha una
 macchina cui sono assegnati diversi numeri IP (o come suol dirsi
 \textit{multi-homed}) e si vuole porre in ascolto sulla stessa porta un
 programma diverso (o una istanza diversa dello stesso programma) per indirizzi
-IP diversi. Si ricordi infatti che è sempre possibile indicare a \func{bind}
+IP diversi. Si ricordi infatti che è sempre possibile indicare a \func{bind}
 di collegarsi solo su di un indirizzo specifico; in tal caso se un altro
 programma cerca di riutilizzare la stessa porta (anche specificando un
-indirizzo diverso) otterrà un errore, a meno di non aver preventivamente
+indirizzo diverso) otterrà un errore, a meno di non aver preventivamente
 impostato \const{SO\_REUSEADDR}.
 
 Usando questa opzione diventa anche possibile eseguire \func{bind}
-sull'indirizzo generico, e questo permetterà il collegamento per tutti gli
+sull'indirizzo generico, e questo permetterà il collegamento per tutti gli
 indirizzi (di quelli presenti) per i quali la porta non risulti occupata da
-una precedente chiamata più specifica. Infine si tenga presente che con il
-protocollo TCP non è mai possibile far partire server che eseguano \func{bind}
-sullo stesso indirizzo e la stessa porta, cioè ottenere quello che viene
+una precedente chiamata più specifica. Infine si tenga presente che con il
+protocollo TCP non è mai possibile far partire server che eseguano \func{bind}
+sullo stesso indirizzo e la stessa porta, cioè ottenere quello che viene
 chiamato un \textit{completely duplicate binding}.
 
-Il terzo impiego è simile al precedente e prevede l'uso di \func{bind}
+Il terzo impiego è simile al precedente e prevede l'uso di \func{bind}
 all'interno dello stesso programma per associare indirizzi locali diversi a
-socket diversi. In genere questo viene fatto per i socket UDP quando è
+socket diversi. In genere questo viene fatto per i socket UDP quando è
 necessario ottenere l'indirizzo a cui sono rivolte le richieste del client ed
 il sistema non supporta l'opzione \const{IP\_RECVDSTADDR};\footnote{nel caso
-  di Linux questa opzione è stata supportata per in certo periodo nello
-  sviluppo del kernel 2.1.x, ma è in seguito stata soppiantata dall'uso di
+  di Linux questa opzione è stata supportata per in certo periodo nello
+  sviluppo del kernel 2.1.x, ma è in seguito stata soppiantata dall'uso di
   \const{IP\_PKTINFO} (vedi sez.~\ref{sec:sock_ipv4_options}).} in tale modo
-si può sapere a quale socket corrisponde un certo indirizzo.  Non ha senso
-fare questa operazione per un socket TCP dato che su di essi si può sempre
-invocare \func{getsockname} una volta che si è completata la connessione.
+si può sapere a quale socket corrisponde un certo indirizzo.  Non ha senso
+fare questa operazione per un socket TCP dato che su di essi si può sempre
+invocare \func{getsockname} una volta che si è completata la connessione.
 
-Infine il quarto caso è quello in cui si vuole effettivamente ottenere un
-\textit{completely duplicate binding}, quando cioè si vuole eseguire
-\func{bind} su un indirizzo ed una porta che sono già \textsl{legati} ad un
+Infine il quarto caso è quello in cui si vuole effettivamente ottenere un
+\textit{completely duplicate binding}, quando cioè si vuole eseguire
+\func{bind} su un indirizzo ed una porta che sono già \textsl{legati} ad un
 altro socket.  Questo ovviamente non ha senso per il normale traffico di rete,
 in cui i pacchetti vengono scambiati direttamente fra due applicazioni; ma
 quando un sistema supporta il traffico in \itindex{multicast}
 \textit{multicast}, in cui una applicazione invia i pacchetti a molte altre
 (vedi sez.~\ref{sec:xxx_multicast}), allora ha senso che su una macchina i
 pacchetti provenienti dal traffico in \itindex{multicast} \textit{multicast}
-possano essere ricevuti da più applicazioni\footnote{l'esempio classico di
-  traffico in \textit{multicast} è quello di uno streaming di dati (audio,
+possano essere ricevuti da più applicazioni\footnote{l'esempio classico di
+  traffico in \textit{multicast} è quello di uno streaming di dati (audio,
   video, ecc.), l'uso del \textit{multicast} consente in tal caso di
-  trasmettere un solo pacchetto, che potrà essere ricevuto da tutti i
+  trasmettere un solo pacchetto, che potrà essere ricevuto da tutti i
   possibili destinatari (invece di inviarne un duplicato a ciascuno); in
-  questo caso è perfettamente logico aspettarsi che sulla stessa macchina più
+  questo caso è perfettamente logico aspettarsi che sulla stessa macchina più
   utenti possano lanciare un programma che permetta loro di ricevere gli
   stessi dati.} o da diverse istanze della stessa applicazione.
 \itindex{multicast}
 
 In questo caso utilizzando \const{SO\_REUSEADDR} si consente ad una
 applicazione eseguire \func{bind} sulla stessa porta ed indirizzo usata da
-un'altra, così che anche essa possa ricevere gli stessi pacchetti (chiaramente
+un'altra, così che anche essa possa ricevere gli stessi pacchetti (chiaramente
 la cosa non ha alcun senso per i socket TCP, ed infatti in questo tipo di
-applicazione è normale l'uso del protocollo UDP). La regola è che quando si
-hanno più applicazioni che hanno eseguito \func{bind} sulla stessa porta, di
+applicazione è normale l'uso del protocollo UDP). La regola è che quando si
+hanno più applicazioni che hanno eseguito \func{bind} sulla stessa porta, di
 tutti pacchetti destinati ad un indirizzo di \itindex{broadcast}
 \textit{broadcast} o di \itindex{multicast} \textit{multicast} viene inviata
-una copia a ciascuna applicazione.  Non è definito invece cosa accade qualora
+una copia a ciascuna applicazione.  Non è definito invece cosa accade qualora
 il pacchetto sia destinato ad un indirizzo normale (unicast).
 
-Essendo questo un caso particolare in alcuni sistemi (come BSD) è stata
+Essendo questo un caso particolare in alcuni sistemi (come BSD) è stata
 introdotta una opzione ulteriore, \const{SO\_REUSEPORT} che richiede che detta
 opzione sia specificata per tutti i socket per i quali si vuole eseguire il
 \textit{completely duplicate binding}. Nel caso di Linux questa opzione non
-esiste, ma il comportamento di \const{SO\_REUSEADDR} è analogo, sarà cioè
+esiste, ma il comportamento di \const{SO\_REUSEADDR} è analogo, sarà cioè
 possibile effettuare un \textit{completely duplicate binding} ed ottenere il
 successo di \func{bind} su un socket legato allo stesso indirizzo e porta solo
 se il programma che ha eseguito per primo \func{bind} su di essi ha impostato
 questa opzione.\footnote{questa restrizione permette di evitare il cosiddetto
   \textit{port stealing}, in cui un programma, usando \const{SO\_REUSEADDR},
-  può collegarsi ad una porta già in uso e ricevere i pacchetti destinati ad
-  un altro programma; con questa caratteristica ciò è possibile soltanto se il
+  può collegarsi ad una porta già in uso e ricevere i pacchetti destinati ad
+  un altro programma; con questa caratteristica ciò è possibile soltanto se il
   primo programma a consentirlo, avendo usato fin dall'inizio
   \const{SO\_REUSEADDR}.}  
 
@@ -2639,9 +2639,9 @@ questa opzione.\footnote{questa restrizione permette di evitare il cosiddetto
 \index{costante!{SO\_LINGER}@{{\tt  {SO\_LINGER}}}|(}
 \subsubsection{L'opzione \const{SO\_LINGER}}
 
-La terza opzione da approfondire è \const{SO\_LINGER}; essa, come il nome
+La terza opzione da approfondire è \const{SO\_LINGER}; essa, come il nome
 suggerisce, consente di ``\textsl{indugiare}'' nella chiusura di un socket. Il
-comportamento standard sia di \func{close} che \func{shutdown} è infatti
+comportamento standard sia di \func{close} che \func{shutdown} è infatti
 quello di terminare immediatamente dopo la chiamata, mentre il procedimento di
 chiusura della connessione (o di un lato di essa) ed il rispettivo invio sulla
 rete di tutti i dati ancora presenti nei buffer, viene gestito in sottofondo
@@ -2662,25 +2662,25 @@ L'uso di \const{SO\_LINGER} con \func{setsockopt} permette di modificare (ed
 eventualmente ripristinare) questo comportamento in base ai valori passati nei
 campi della struttura \struct{linger}, illustrata in
 fig.~\ref{fig:sock_linger_struct}.  Fintanto che il valore del campo
-\var{l\_onoff} di \struct{linger} è nullo la modalità che viene impostata
-(qualunque sia il valore di \var{l\_linger}) è quella standard appena
+\var{l\_onoff} di \struct{linger} è nullo la modalità che viene impostata
+(qualunque sia il valore di \var{l\_linger}) è quella standard appena
 illustrata; questa combinazione viene utilizzata per riportarsi al
 comportamento normale qualora esso sia stato cambiato da una precedente
 chiamata.
 
 Se si utilizza un valore di \var{l\_onoff} diverso da zero, il comportamento
 alla chiusura viene a dipendere dal valore specificato per il campo
-\var{l\_linger}; se quest'ultimo è nullo l'uso delle funzioni \func{close} e
+\var{l\_linger}; se quest'ultimo è nullo l'uso delle funzioni \func{close} e
 \func{shutdown} provoca la terminazione immediata della connessione: nel caso
-di TCP cioè non viene eseguito il procedimento di chiusura illustrato in
+di TCP cioè non viene eseguito il procedimento di chiusura illustrato in
 sez.~\ref{sec:TCP_conn_term}, ma tutti i dati ancora presenti nel buffer
 vengono immediatamente scartati e sulla rete viene inviato un segmento di RST
 che termina immediatamente la connessione.
 
-Un esempio di questo comportamento si può abilitare nel nostro client del
+Un esempio di questo comportamento si può abilitare nel nostro client del
 servizio \textit{echo} utilizzando l'opzione \texttt{-r}; riportiamo in
 fig.~\ref{fig:TCP_echo_sixth} la sezione di codice che permette di introdurre
-questa funzionalità,; al solito il codice completo è disponibile nei sorgenti
+questa funzionalità,; al solito il codice completo è disponibile nei sorgenti
 allegati.
 
 \begin{figure}[!htb] 
@@ -2695,7 +2695,7 @@ allegati.
 \end{figure}
 
 La sezione indicata viene eseguita dopo aver effettuato la connessione e prima
-di chiamare la funzione di gestione, cioè fra le righe (\texttt{\small 12}) e
+di chiamare la funzione di gestione, cioè fra le righe (\texttt{\small 12}) e
 (\texttt{\small 13}) del precedente esempio di fig.~\ref{fig:TCP_echo_fifth}.
 Il codice si limita semplicemente a controllare (\texttt{\small 3}) il
 valore della variabile \var{reset} che assegnata nella gestione delle opzioni
@@ -2707,16 +2707,16 @@ chiamata a \func{setsockopt}. Al solito si controlla (\texttt{\small 7--10})
 il valore di ritorno e si termina il programma in caso di errore, stampandone
 il valore.
 
-Infine l'ultima possibilità, quella in cui si utilizza effettivamente
-\const{SO\_LINGER} per \textsl{indugiare} nella chiusura, è quella in cui sia
+Infine l'ultima possibilità, quella in cui si utilizza effettivamente
+\const{SO\_LINGER} per \textsl{indugiare} nella chiusura, è quella in cui sia
 \var{l\_onoff} che \var{l\_linger} hanno un valore diverso da zero. Se si
 esegue l'impostazione con questi valori sia \func{close} che \func{shutdown}
 si bloccano, nel frattempo viene eseguita la normale procedura di conclusione
 della connessione (quella di sez.~\ref{sec:TCP_conn_term}) ma entrambe le
 funzioni non ritornano fintanto che non si sia concluso il procedimento di
 chiusura della connessione, o non sia passato un numero di
-secondi\footnote{questa è l'unità di misura indicata da POSIX ed adottata da
-  Linux, altri kernel possono usare unità di misura diverse, oppure usare il
+secondi\footnote{questa è l'unità di misura indicata da POSIX ed adottata da
+  Linux, altri kernel possono usare unità di misura diverse, oppure usare il
   campo \var{l\_linger} come valore logico (ignorandone il valore) per rendere
   (quando diverso da zero) \func{close} e \func{shutdown} bloccanti fino al
   completamento della trasmissione dei dati sul buffer.}  pari al valore
@@ -2729,13 +2729,13 @@ specificato in \var{l\_linger}.
 \subsection{Le opzioni per il protocollo IPv4}
 \label{sec:sock_ipv4_options}
 
-Il secondo insieme di opzioni dei socket che tratteremo è quello relativo ai
+Il secondo insieme di opzioni dei socket che tratteremo è quello relativo ai
 socket che usano il protocollo IPv4.\footnote{come per le precedenti opzioni
-  generiche una descrizione di esse è disponibile nella settima sezione delle
-  pagine di manuale, nel caso specifico la documentazione si può consultare
+  generiche una descrizione di esse è disponibile nella settima sezione delle
+  pagine di manuale, nel caso specifico la documentazione si può consultare
   con \texttt{man 7 ip}.}  Se si vuole operare su queste opzioni generiche il
-livello da utilizzare è \const{SOL\_IP} (o l'equivalente \const{IPPROTO\_IP});
-si è riportato un elenco di queste opzioni in tab.~\ref{tab:sock_opt_iplevel}.
+livello da utilizzare è \const{SOL\_IP} (o l'equivalente \const{IPPROTO\_IP});
+si è riportato un elenco di queste opzioni in tab.~\ref{tab:sock_opt_iplevel}.
 Le costanti indicanti le opzioni e tutte le altre costanti ad esse collegate
 sono definite in \file{netinet/ip.h}, ed accessibili includendo detto file.
 
@@ -2795,7 +2795,7 @@ sono definite in \file{netinet/ip.h}, ed accessibili includendo detto file.
 \end{table}
 
 Le descrizioni riportate in tab.~\ref{tab:sock_opt_iplevel} sono estremamente
-succinte, una maggiore quantità di dettagli sulle varie opzioni è fornita nel
+succinte, una maggiore quantità di dettagli sulle varie opzioni è fornita nel
 seguente elenco:
 \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
 
@@ -2816,7 +2816,7 @@ seguente elenco:
   sez.~\ref{sec:net_ancillary_data}) di tipo \const{IP\_PKTINFO} contenente
   una struttura \struct{pktinfo} (vedi fig.~\ref{fig:sock_pktinfo_struct}) che
   mantiene una serie di informazioni riguardo i pacchetti in arrivo. In
-  particolare è possibile conoscere l'interfaccia su cui è stato ricevuto un
+  particolare è possibile conoscere l'interfaccia su cui è stato ricevuto un
   pacchetto (nel campo \var{ipi\_ifindex}),\footnote{in questo campo viene
     restituito il valore numerico dell'indice dell'interfaccia,
     sez.~\ref{sec:sock_ioctl_netdevice}.} l'indirizzo locale da esso
@@ -2835,18 +2835,18 @@ seguente elenco:
 \end{figure}
 
 
-L'opzione è utilizzabile solo per socket di tipo \const{SOCK\_DGRAM}. Questa è
-una opzione introdotta con i kernel della serie 2.2.x, ed è specifica di
+L'opzione è utilizzabile solo per socket di tipo \const{SOCK\_DGRAM}. Questa è
+una opzione introdotta con i kernel della serie 2.2.x, ed è specifica di
 Linux;\footnote{non dovrebbe pertanto essere utilizzata se si ha a cuore la
-  portabilità.} essa permette di sostituire le opzioni \const{IP\_RECVDSTADDR}
-e \const{IP\_RECVIF} presenti in altri Unix (la relativa informazione è quella
+  portabilità.} essa permette di sostituire le opzioni \const{IP\_RECVDSTADDR}
+e \const{IP\_RECVIF} presenti in altri Unix (la relativa informazione è quella
 ottenibile rispettivamente dai campi \var{ipi\_addr} e \var{ipi\_ifindex} di
 \struct{pktinfo}). 
 
 L'opzione prende per \param{optval} un intero usato come valore logico, che
 specifica soltanto se insieme al pacchetto deve anche essere inviato o
 ricevuto il messaggio \const{IP\_PKTINFO} (vedi
-sez.~\ref{sec:net_ancillary_data}); il messaggio stesso dovrà poi essere
+sez.~\ref{sec:net_ancillary_data}); il messaggio stesso dovrà poi essere
 letto o scritto direttamente con \func{recvmsg} e \func{sendmsg} (vedi
 sez.~\ref{sec:net_sendmsg}).
 
@@ -2863,95 +2863,95 @@ sez.~\ref{sec:net_sendmsg}).
   sez.~\ref{sec:net_ancillary_data}) di tipo \const{IP\_RECVTTL}, contenente
   un byte con il valore del campo \textit{Time to Live} dell'intestazione IP
   (vedi sez.~\ref{sec:IP_header}).  L'opzione richiede per \param{optval} un
-  intero usato come valore logico. L'opzione non è supportata per socket di
+  intero usato come valore logico. L'opzione non è supportata per socket di
   tipo \const{SOCK\_STREAM}.
 
 \item[\const{IP\_RECVOPTS}] Quando abilitata l'opzione permette di ricevere
   insieme ai pacchetti un messaggio ancillare (vedi
   sez.~\ref{sec:net_ancillary_data}) di tipo \const{IP\_OPTIONS}, contenente
   le opzioni IP del protocollo (vedi sez.~\ref{sec:IP_options}). Le
-  intestazioni di instradamento e le altre opzioni sono già riempite con i
+  intestazioni di instradamento e le altre opzioni sono già riempite con i
   dati locali. L'opzione richiede per \param{optval} un intero usato come
-  valore logico.  L'opzione non è supportata per socket di tipo
+  valore logico.  L'opzione non è supportata per socket di tipo
   \const{SOCK\_STREAM}.
 
 \item[\const{IP\_RETOPTS}] Identica alla precedente \const{IP\_RECVOPTS}, ma
   in questo caso restituisce i dati grezzi delle opzioni, senza che siano
   riempiti i capi di instradamento e le marche temporali.  L'opzione richiede
-  per \param{optval} un intero usato come valore logico.  L'opzione non è
+  per \param{optval} un intero usato come valore logico.  L'opzione non è
   supportata per socket di tipo \const{SOCK\_STREAM}.
 
 \item[\const{IP\_TOS}] L'opzione consente di leggere o impostare il campo
-  \textit{Type of Service} dell'intestazione IP (per una trattazione più
+  \textit{Type of Service} dell'intestazione IP (per una trattazione più
   dettagliata, che riporta anche i valori possibili e le relative costanti di
   definizione si veda sez.~\ref{sec:IP_header}) che permette di indicare le
-  priorità dei pacchetti. Se impostato il valore verrà mantenuto per tutti i
-  pacchetti del socket; alcuni valori (quelli che aumentano la priorità)
+  priorità dei pacchetti. Se impostato il valore verrà mantenuto per tutti i
+  pacchetti del socket; alcuni valori (quelli che aumentano la priorità)
   richiedono i privilegi di amministrazione con la \itindex{capabilities}
   capability \const{CAP\_NET\_ADMIN}.
 
-  Il campo TOS è di 8 bit e l'opzione richiede per \param{optval} un intero
+  Il campo TOS è di 8 bit e l'opzione richiede per \param{optval} un intero
   che ne contenga il valore. Sono definite anche alcune costanti che
   definiscono alcuni valori standardizzati per il \textit{Type of Service},
   riportate in tab.~\ref{tab:IP_TOS_values}, il valore di default usato da
-  Linux è \const{IPTOS\_LOWDELAY}, ma esso può essere modificato con le
-  funzionalità del cosiddetto \textit{Advanced Routing}. Si ricordi che la
-  priorità dei pacchetti può essere impostata anche in maniera indipendente
+  Linux è \const{IPTOS\_LOWDELAY}, ma esso può essere modificato con le
+  funzionalità del cosiddetto \textit{Advanced Routing}. Si ricordi che la
+  priorità dei pacchetti può essere impostata anche in maniera indipendente
   dal protocollo utilizzando l'opzione \const{SO\_PRIORITY} illustrata in
   sez.~\ref{sec:sock_generic_options}.
 
 \item[\const{IP\_TTL}] L'opzione consente di leggere o impostare per tutti i
   pacchetti associati al socket il campo \textit{Time to Live}
   dell'intestazione IP che indica il numero massimo di \textit{hop} (passaggi
-  da un router ad un altro) restanti al paccheto (per una trattazione più
-  estesa si veda sez.~\ref{sec:IP_header}).  Il campo TTL è di 8 bit e
-  l'opzione richiede che \param{optval} sia un intero, che ne conterrà il
+  da un router ad un altro) restanti al paccheto (per una trattazione più
+  estesa si veda sez.~\ref{sec:IP_header}).  Il campo TTL è di 8 bit e
+  l'opzione richiede che \param{optval} sia un intero, che ne conterrà il
   valore.
 
 \item[\const{IP\_MINTTL}] L'opzione, introdotta con il kernel 2.6.34, imposta
   un valore minimo per il campo \textit{Time to Live} dei pacchetti associati
-  al socket su cui è attivata, che se non rispettato ne causa lo scarto
-  automatico. L'opzione è nata per implementare
+  al socket su cui è attivata, che se non rispettato ne causa lo scarto
+  automatico. L'opzione è nata per implementare
   l'\href{http://www.ietf.org/rfc/rfc5082.txt}{RFC~5082} che la prevede come
-  forma di protezione per i router che usano il protocollo BGP poiché questi,
+  forma di protezione per i router che usano il protocollo BGP poiché questi,
   essendo in genere adiacenti, possono, impostando un valore di 255, scartare
   automaticamente tutti gli eventuali pacchetti falsi creati da un attacco a
   questo protocollo, senza doversi curare di verificarne la
-  validità.\footnote{l'attacco viene in genere portato per causare un
+  validità.\footnote{l'attacco viene in genere portato per causare un
     \textit{Denial of Service} aumentando il consumo di CPU del router nella
-    verifica dell'autenticità di un gran numero di pacchetti di pacchetti
+    verifica dell'autenticità di un gran numero di pacchetti di pacchetti
     falsi; questi, arrivando da sorgenti diverse da un router adiacente, non
-    potrebbero più avere un TTL di 255 anche qualora questo fosse stato il
+    potrebbero più avere un TTL di 255 anche qualora questo fosse stato il
     valore di partenza, e l'impostazione dell'opzione consente di scartarli
     senza carico aggiuntivo sulla CPU (che altrimenti dovrebbe calcolare una
     checksum).}
 
 \item[\const{IP\_HDRINCL}] Se abilitata l'utente deve fornire lui stesso
-  l'intestazione IP in cima ai propri dati. L'opzione è valida soltanto per
+  l'intestazione IP in cima ai propri dati. L'opzione è valida soltanto per
   socket di tipo \const{SOCK\_RAW}, e quando utilizzata eventuali valori
   impostati con \const{IP\_OPTIONS}, \const{IP\_TOS} o \const{IP\_TTL} sono
   ignorati. In ogni caso prima della spedizione alcuni campi
   dell'intestazione vengono comunque modificati dal kernel, torneremo
   sull'argomento in sez.~\ref{sec:socket_raw}
 
-\item[\const{IP\_RECVERR}] Questa è una opzione introdotta con i kernel della
-  serie 2.2.x, ed è specifica di Linux. Essa permette di usufruire di un
+\item[\const{IP\_RECVERR}] Questa è una opzione introdotta con i kernel della
+  serie 2.2.x, ed è specifica di Linux. Essa permette di usufruire di un
   meccanismo affidabile per ottenere un maggior numero di informazioni in caso
-  di errori. Se l'opzione è abilitata tutti gli errori generati su un socket
+  di errori. Se l'opzione è abilitata tutti gli errori generati su un socket
   vengono memorizzati su una coda, dalla quale poi possono essere letti con
   \func{recvmsg} (vedi sez.~\ref{sec:net_sendmsg}) come messaggi ancillari
   (torneremo su questo in sez.~\ref{sec:net_ancillary_data}) di tipo
   \const{IP\_RECVERR}.  L'opzione richiede per \param{optval} un intero usato
-  come valore logico e non è applicabile a socket di tipo
+  come valore logico e non è applicabile a socket di tipo
   \const{SOCK\_STREAM}.
 
 \itindbeg{Maximum~Transfer~Unit}
-\item[\const{IP\_MTU\_DISCOVER}] Questa è una opzione introdotta con i kernel
-  della serie 2.2.x, ed è specifica di Linux.  L'opzione permette di scrivere
-  o leggere le impostazioni della modalità usata per la determinazione della
+\item[\const{IP\_MTU\_DISCOVER}] Questa è una opzione introdotta con i kernel
+  della serie 2.2.x, ed è specifica di Linux.  L'opzione permette di scrivere
+  o leggere le impostazioni della modalità usata per la determinazione della
   \textit{Path Maximum Transfer Unit} (vedi sez.~\ref{sec:net_lim_dim}) del
   socket. L'opzione prende per \param{optval} un valore intero che indica la
-  modalità usata, da specificare con una delle costanti riportate in
+  modalità usata, da specificare con una delle costanti riportate in
   tab.~\ref{tab:sock_ip_mtu_discover}.
 
   \begin{table}[!htb]
@@ -2977,14 +2977,14 @@ sez.~\ref{sec:net_sendmsg}).
     \label{tab:sock_ip_mtu_discover}
   \end{table}
 
-  Il valore di default applicato ai socket di tipo \const{SOCK\_STREAM} è
+  Il valore di default applicato ai socket di tipo \const{SOCK\_STREAM} è
   determinato dal parametro \texttt{ip\_no\_pmtu\_disc} (vedi
   sez.~\ref{sec:sock_sysctl}), mentre per tutti gli altri socket di default la
-  ricerca è disabilitata ed è responsabilità del programma creare pacchetti di
+  ricerca è disabilitata ed è responsabilità del programma creare pacchetti di
   dimensioni appropriate e ritrasmettere eventuali pacchetti persi. Se
-  l'opzione viene abilitata, il kernel si incaricherà di tenere traccia
+  l'opzione viene abilitata, il kernel si incaricherà di tenere traccia
   automaticamente della \itindex{Maximum~Transfer~Unit} \textit{Path MTU}
-  verso ciascuna destinazione, e rifiuterà immediatamente la trasmissione di
+  verso ciascuna destinazione, e rifiuterà immediatamente la trasmissione di
   pacchetti di dimensioni maggiori della MTU con un errore di
   \errval{EMSGSIZE}.\footnote{in caso contrario la trasmissione del pacchetto
     sarebbe effettuata, ottenendo o un fallimento successivo della
@@ -2992,41 +2992,41 @@ sez.~\ref{sec:net_sendmsg}).
 
 \item[\const{IP\_MTU}] Permette di leggere il valore della \textit{Path MTU}
   di percorso del socket.  L'opzione richiede per \param{optval} un intero che
-  conterrà il valore della \textit{Path MTU} in byte.  Questa è una opzione
-  introdotta con i kernel della serie 2.2.x, ed è specifica di Linux.
+  conterrà il valore della \textit{Path MTU} in byte.  Questa è una opzione
+  introdotta con i kernel della serie 2.2.x, ed è specifica di Linux.
 
-  È tramite questa opzione che un programma può leggere, quando si è avuto un
+  È tramite questa opzione che un programma può leggere, quando si è avuto un
   errore di \errval{EMSGSIZE}, il valore della MTU corrente del socket. Si
   tenga presente che per poter usare questa opzione, oltre ad avere abilitato
   la scoperta della \textit{Path MTU}, occorre che il socket sia stato
   esplicitamente connesso con \func{connect}. 
 
-  Ad esempio con i socket UDP si potrà ottenere una stima iniziale della
+  Ad esempio con i socket UDP si potrà ottenere una stima iniziale della
   \itindex{Maximum~Transfer~Unit} \textit{Path MTU} eseguendo prima una
   \func{connect} verso la destinazione, e poi usando \func{getsockopt} con
-  questa opzione. Si può anche avviare esplicitamente il procedimento di
-  scoperta inviando un pacchetto di grosse dimensioni (che verrà scartato) e
+  questa opzione. Si può anche avviare esplicitamente il procedimento di
+  scoperta inviando un pacchetto di grosse dimensioni (che verrà scartato) e
   ripetendo l'invio coi dati aggiornati. Si tenga infine conto che durante il
-  procedimento i pacchetti iniziali possono essere perduti, ed è compito
+  procedimento i pacchetti iniziali possono essere perduti, ed è compito
   dell'applicazione gestirne una eventuale ritrasmissione.
 
 \itindend{Maximum~Transfer~Unit}
 
-\item[\const{IP\_ROUTER\_ALERT}] Questa è una opzione introdotta con i
-  kernel della serie 2.2.x, ed è specifica di Linux. Prende per
+\item[\const{IP\_ROUTER\_ALERT}] Questa è una opzione introdotta con i
+  kernel della serie 2.2.x, ed è specifica di Linux. Prende per
   \param{optval} un intero usato come valore logico. Se abilitata
   passa tutti i pacchetti con l'opzione \textit{IP Router Alert} (vedi
   sez.~\ref{sec:IP_options}) che devono essere inoltrati al socket
-  corrente. Può essere usata soltanto per socket di tipo raw.
+  corrente. Può essere usata soltanto per socket di tipo raw.
 
 \itindbeg{multicast}
 \item[\const{IP\_MULTICAST\_TTL}] L'opzione permette di impostare o leggere il
   valore del campo TTL per i pacchetti \textit{multicast} in uscita associati
-  al socket. È importante che questo valore sia il più basso possibile, ed il
-  default è 1, che significa che i pacchetti non potranno uscire dalla rete
+  al socket. È importante che questo valore sia il più basso possibile, ed il
+  default è 1, che significa che i pacchetti non potranno uscire dalla rete
   locale. Questa opzione consente ai programmi che lo richiedono di superare
   questo limite.  L'opzione richiede per
-  \param{optval} un intero che conterrà il valore del TTL.
+  \param{optval} un intero che conterrà il valore del TTL.
 
 \item[\const{IP\_MULTICAST\_LOOP}] L'opzione consente di decidere se i dati
   che si inviano su un socket usato con il \textit{multicast} vengano ricevuti
@@ -3034,13 +3034,13 @@ sez.~\ref{sec:net_sendmsg}).
   \param{optval} un intero usato come valore logico.
 
   In generale se si vuole che eventuali client possano ricevere i dati che si
-  inviano occorre che questa funzionalità sia abilitata (come avviene di
-  default). Qualora però non si voglia generare traffico per dati che già sono
+  inviano occorre che questa funzionalità sia abilitata (come avviene di
+  default). Qualora però non si voglia generare traffico per dati che già sono
   disponibili in locale l'uso di questa opzione permette di disabilitare
   questo tipo di traffico.
 
 \item[\const{IP\_ADD\_MEMBERSHIP}] L'opzione consente di unirsi ad gruppo di
-  \textit{multicast}, e può essere usata solo con \func{setsockopt}.
+  \textit{multicast}, e può essere usata solo con \func{setsockopt}.
   L'argomento \param{optval} in questo caso deve essere una struttura di tipo
   \struct{ip\_mreqn}, illustrata in fig.~\ref{fig:ip_mreqn_struct}, che
   permette di indicare, con il campo \var{imr\_multiaddr} l'indirizzo del
@@ -3050,7 +3050,7 @@ sez.~\ref{sec:net_sendmsg}).
   dell'interfaccia da utilizzare (un valore nullo indica una interfaccia
   qualunque).
 
-  Per compatibilità è possibile utilizzare anche un argomento di tipo
+  Per compatibilità è possibile utilizzare anche un argomento di tipo
   \struct{ip\_mreq}, una precedente versione di \struct{ip\_mreqn}, che
   differisce da essa soltanto per l'assenza del campo \var{imr\_ifindex}.
 
@@ -3084,27 +3084,27 @@ sez.~\ref{sec:net_sendmsg}).
 In questa sezione tratteremo le varie opzioni disponibili per i socket che
 usano i due principali protocolli di comunicazione del livello di trasporto;
 UDP e TCP.\footnote{come per le precedenti, una descrizione di queste opzioni
-  è disponibile nella settima sezione delle pagine di manuale, che si può
+  è disponibile nella settima sezione delle pagine di manuale, che si può
   consultare rispettivamente con \texttt{man 7 tcp} e \texttt{man 7 udp}; le
-  pagine di manuale però, alla stesura di questa sezione (Agosto 2006) sono
+  pagine di manuale però, alla stesura di questa sezione (Agosto 2006) sono
   alquanto incomplete.}  Dato che questi due protocolli sono entrambi
 trasportati su IP,\footnote{qui si sottintende IPv4, ma le opzioni per TCP e
   UDP sono le stesse anche quando si usa IPv6.} oltre alle opzioni generiche
 di sez.~\ref{sec:sock_generic_options} saranno comunque disponibili anche le
-precedenti opzioni di sez.~\ref{sec:sock_ipv4_options}.\footnote{in realtà in
+precedenti opzioni di sez.~\ref{sec:sock_ipv4_options}.\footnote{in realtà in
   sez.~\ref{sec:sock_ipv4_options} si sono riportate le opzioni per IPv4, al
   solito, qualora si stesse utilizzando IPv6, si potrebbero utilizzare le
   opzioni di quest'ultimo.}
 
-Il protocollo che supporta il maggior numero di opzioni è TCP; per poterle
+Il protocollo che supporta il maggior numero di opzioni è TCP; per poterle
 utilizzare occorre specificare \const{SOL\_TCP} (o l'equivalente
 \const{IPPROTO\_TCP}) come valore per l'argomento \param{level}. Si sono
 riportate le varie opzioni disponibili in tab.~\ref{tab:sock_opt_tcplevel},
 dove sono elencate le rispettive costanti da utilizzare come valore per
 l'argomento \param{optname}. Dette costanti e tutte le altre costanti e
 strutture collegate all'uso delle opzioni TCP sono definite in
-\file{netinet/tcp.h}, ed accessibili includendo detto file.\footnote{in realtà
-  questo è il file usato dalle librerie; la definizione delle opzioni
+\file{netinet/tcp.h}, ed accessibili includendo detto file.\footnote{in realtà
+  questo è il file usato dalle librerie; la definizione delle opzioni
   effettivamente supportate da Linux si trova nel file \texttt{linux/tcp.h},
   dal quale si sono estratte le costanti di tab.~\ref{tab:sock_opt_tcplevel}.}
 
@@ -3141,7 +3141,7 @@ strutture collegate all'uso delle opzioni TCP sono definite in
     \const{TCP\_INFO}         &$\bullet$&        &       &\struct{tcp\_info}& 
       Restituisce informazioni sul socket.\\
     \const{TCP\_QUICKACK}     &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
-      Abilita la modalità \textit{quickack}.\\
+      Abilita la modalità \textit{quickack}.\\
     \const{TCP\_CONGESTION}   &$\bullet$&$\bullet$&         &\texttt{char *}&
       Imposta l'algoritmo per il controllo della congestione.\\
    \hline
@@ -3154,73 +3154,73 @@ strutture collegate all'uso delle opzioni TCP sono definite in
 Le descrizioni delle varie opzioni riportate in
 tab.~\ref{tab:sock_opt_tcplevel} sono estremamente sintetiche ed indicative,
 la spiegazione del funzionamento delle singole opzioni con una maggiore
-quantità di dettagli è fornita nel seguente elenco:
+quantità di dettagli è fornita nel seguente elenco:
 \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
 
 
 \item[\const{TCP\_NODELAY}] il protocollo TCP utilizza un meccanismo di
   bufferizzazione dei dati uscenti, per evitare la trasmissione di tanti
   piccoli segmenti con un utilizzo non ottimale della banda
-  disponibile.\footnote{il problema è chiamato anche \textit{silly window
+  disponibile.\footnote{il problema è chiamato anche \textit{silly window
       syndrome}, per averne un'idea si pensi al risultato che si ottiene
     quando un programma di terminale invia un segmento TCP per ogni tasto
     premuto, 40 byte di intestazione di protocollo con 1 byte di dati
-    trasmessi; per evitare situazioni del genere è stato introdotto
+    trasmessi; per evitare situazioni del genere è stato introdotto
     \index{algoritmo~di~Nagle} l'\textsl{algoritmo di Nagle}.}  Questo
-  meccanismo è controllato da un apposito algoritmo (detto
+  meccanismo è controllato da un apposito algoritmo (detto
   \index{algoritmo~di~Nagle} \textsl{algoritmo di Nagle}, vedi
   sez.~\ref{sec:tcp_protocol_xxx}).  Il comportamento normale del protocollo
   prevede che i dati siano accumulati fintanto che non si raggiunge una
-  quantità considerata adeguata per eseguire la trasmissione di un singolo
+  quantità considerata adeguata per eseguire la trasmissione di un singolo
   segmento.
 
-  Ci sono però delle situazioni in cui questo comportamento può non essere
-  desiderabile, ad esempio quando si sa in anticipo che l'applicazione invierà
-  soltanto un piccolo quantitativo di dati;\footnote{è il caso classico di una
+  Ci sono però delle situazioni in cui questo comportamento può non essere
+  desiderabile, ad esempio quando si sa in anticipo che l'applicazione invierà
+  soltanto un piccolo quantitativo di dati;\footnote{è il caso classico di una
     richiesta HTTP.} in tal caso l'attesa introdotta dall'algoritmo di
-  bufferizzazione non soltanto è inutile, ma peggiora le prestazioni
+  bufferizzazione non soltanto è inutile, ma peggiora le prestazioni
   introducendo un ritardo.  Impostando questa opzione si disabilita l'uso
   \index{algoritmo~di~Nagle} dell'\textsl{algoritmo di Nagle} ed i dati
   vengono inviati immediatamente in singoli segmenti, qualunque sia la loro
-  dimensione.  Ovviamente l'uso di questa opzione è dedicato a chi ha esigenze
+  dimensione.  Ovviamente l'uso di questa opzione è dedicato a chi ha esigenze
   particolari come quella illustrata, che possono essere stabilite solo per la
   singola applicazione.
 
   Si tenga conto che questa opzione viene sovrascritta dall'eventuale
-  impostazione dell'opzione \const{TCP\_CORK} (il cui scopo è sostanzialmente
+  impostazione dell'opzione \const{TCP\_CORK} (il cui scopo è sostanzialmente
   l'opposto) che blocca l'invio immediato. Tuttavia quando la si abilita viene
   sempre forzato lo scaricamento della coda di invio (con conseguente
-  trasmissione di tutti i dati pendenti), anche qualora si fosse già abilitata
-  \const{TCP\_CORK}.\footnote{si tenga presente però che \const{TCP\_CORK} può
+  trasmissione di tutti i dati pendenti), anche qualora si fosse già abilitata
+  \const{TCP\_CORK}.\footnote{si tenga presente però che \const{TCP\_CORK} può
     essere specificata insieme a \const{TCP\_NODELAY} soltanto a partire dal
     kernel 2.5.71.}
 
 \item[\const{TCP\_MAXSEG}] con questa opzione si legge o si imposta il valore
   della \itindex{Maximum~Segment~Size} MSS (\textit{Maximum~Segment~Size},
   vedi sez.~\ref{sec:net_lim_dim} e sez.~\ref{sec:tcp_protocol_xxx}) dei
-  segmenti TCP uscenti. Se l'opzione è impostata prima di stabilire la
+  segmenti TCP uscenti. Se l'opzione è impostata prima di stabilire la
   connessione, si cambia anche il valore della \itindex{Maximum~Segment~Size}
   MSS annunciata all'altro capo della connessione. Se si specificano valori
   maggiori della \itindex{Maximum~Transfer~Unit} MTU questi verranno ignorati,
-  inoltre TCP imporrà anche i suoi limiti massimo e minimo per questo valore.
+  inoltre TCP imporrà anche i suoi limiti massimo e minimo per questo valore.
 
-\item[\const{TCP\_CORK}] questa opzione è il complemento naturale di
+\item[\const{TCP\_CORK}] questa opzione è il complemento naturale di
   \const{TCP\_NODELAY} e serve a gestire a livello applicativo la situazione
-  opposta, cioè quella in cui si sa fin dal principio che si dovranno inviare
-  grosse quantità di dati. Anche in questo caso \index{algoritmo~di~Nagle}
-  l'\textsl{algoritmo di Nagle} tenderà a suddividerli in dimensioni da lui
+  opposta, cioè quella in cui si sa fin dal principio che si dovranno inviare
+  grosse quantità di dati. Anche in questo caso \index{algoritmo~di~Nagle}
+  l'\textsl{algoritmo di Nagle} tenderà a suddividerli in dimensioni da lui
   ritenute opportune,\footnote{l'algoritmo cerca di tenere conto di queste
-    situazioni, ma essendo un algoritmo generico tenderà comunque ad
+    situazioni, ma essendo un algoritmo generico tenderà comunque ad
     introdurre delle suddivisioni in segmenti diversi, anche quando potrebbero
     non essere necessarie, con conseguente spreco di banda.}  ma sapendo fin
-  dall'inizio quale è la dimensione dei dati si potranno di nuovo ottenere
+  dall'inizio quale è la dimensione dei dati si potranno di nuovo ottenere
   delle migliori prestazioni disabilitandolo, e gestendo direttamente l'invio
   del nostro blocco di dati in soluzione unica.
 
   Quando questa opzione viene abilitata non vengono inviati segmenti di dati
   fintanto che essa non venga disabilitata; a quel punto tutti i dati rimasti
   in coda saranno inviati in un solo segmento TCP. In sostanza con questa
-  opzione si può controllare il flusso dei dati mettendo una sorta di
+  opzione si può controllare il flusso dei dati mettendo una sorta di
   ``\textsl{tappo}'' (da cui il nome in inglese) al flusso di uscita, in modo
   ottimizzare a mano l'uso della banda. Si tenga presente che per l'effettivo
   funzionamento ci si deve ricordare di disattivare l'opzione al termine
@@ -3235,10 +3235,10 @@ quantit
   notevole penalizzazione delle prestazioni.
 
   Si tenga presente che l'implementazione corrente di \const{TCP\_CORK} non
-  consente di bloccare l'invio dei dati per più di 200 millisecondi, passati i
-  quali i dati accumulati in coda sanno inviati comunque.  Questa opzione è
-  tipica di Linux\footnote{l'opzione è stata introdotta con i kernel della
-    serie 2.4.x.} e non è disponibile su tutti i kernel unix-like, pertanto
+  consente di bloccare l'invio dei dati per più di 200 millisecondi, passati i
+  quali i dati accumulati in coda sanno inviati comunque.  Questa opzione è
+  tipica di Linux\footnote{l'opzione è stata introdotta con i kernel della
+    serie 2.4.x.} e non è disponibile su tutti i kernel unix-like, pertanto
   deve essere evitata se si vuole scrivere codice portabile.
 
 \item[\const{TCP\_KEEPIDLE}] con questa opzione si legge o si imposta
@@ -3246,22 +3246,22 @@ quantit
   socket prima che vengano inviati, qualora si sia attivata su di esso
   l'opzione \const{SO\_KEEPALIVE}, i messaggi di \textit{keep-alive} (si veda
   la trattazione relativa al \textit{keep-alive} in
-  sez.~\ref{sec:sock_options_main}).  Anche questa opzione non è disponibile
+  sez.~\ref{sec:sock_options_main}).  Anche questa opzione non è disponibile
   su tutti i kernel unix-like e deve essere evitata se si vuole scrivere
   codice portabile.
 
 \item[\const{TCP\_KEEPINTVL}] con questa opzione si legge o si imposta
   l'intervallo di tempo, in secondi, fra due messaggi di \textit{keep-alive}
   successivi (si veda sempre quanto illustrato in
-  sez.~\ref{sec:sock_options_main}). Come la precedente non è disponibile su
+  sez.~\ref{sec:sock_options_main}). Come la precedente non è disponibile su
   tutti i kernel unix-like e deve essere evitata se si vuole scrivere codice
   portabile.
 
 \item[\const{TCP\_KEEPCNT}] con questa opzione si legge o si imposta il numero
   totale di messaggi di \textit{keep-alive} da inviare prima di concludere che
-  la connessione è caduta per assenza di risposte ad un messaggio di
+  la connessione è caduta per assenza di risposte ad un messaggio di
   \textit{keep-alive} (di nuovo vedi sez.~\ref{sec:sock_options_main}). Come
-  la precedente non è disponibile su tutti i kernel unix-like e deve essere
+  la precedente non è disponibile su tutti i kernel unix-like e deve essere
   evitata se si vuole scrivere codice portabile.
 
 \item[\const{TCP\_SYNCNT}] con questa opzione si legge o si imposta il numero
@@ -3271,7 +3271,7 @@ quantit
   sez.~\ref{sec:TCP_func_connect}). Sovrascrive per il singolo socket il valore
   globale impostato con la \textit{sysctl} \texttt{tcp\_syn\_retries} (vedi
   sez.~\ref{sec:sock_ipv4_sysctl}).  Non vengono accettati valori maggiori di
-  255; anche questa opzione non è standard e deve essere evitata se si vuole
+  255; anche questa opzione non è standard e deve essere evitata se si vuole
   scrivere codice portabile.
 
 \item[\const{TCP\_LINGER2}] con questa opzione si legge o si imposta, in
@@ -3282,24 +3282,24 @@ quantit
     abbiamo visto in sez.~\ref{sec:sock_options_main}.}  Questa opzione
   consente di sovrascrivere per il singolo socket il valore globale impostato
   con la \textit{sysctl} \texttt{tcp\_fin\_timeout} (vedi
-  sez.~\ref{sec:sock_ipv4_sysctl}).  Anche questa opzione è da evitare se si
-  ha a cuore la portabilità del codice.
+  sez.~\ref{sec:sock_ipv4_sysctl}).  Anche questa opzione è da evitare se si
+  ha a cuore la portabilità del codice.
 
 \item[\const{TCP\_DEFER\_ACCEPT}] questa opzione consente di modificare il
   comportamento standard del protocollo TCP nello stabilirsi di una
   connessione; se ricordiamo il meccanismo del \itindex{three~way~handshake}
   \textit{three way handshake} illustrato in fig.~\ref{fig:TCP_TWH} possiamo
-  vedere che in genere un client inizierà ad inviare i dati ad un server solo
+  vedere che in genere un client inizierà ad inviare i dati ad un server solo
   dopo l'emissione dell'ultimo segmento di ACK.
 
-  Di nuovo esistono situazioni (e la più tipica è quella di una richiesta
+  Di nuovo esistono situazioni (e la più tipica è quella di una richiesta
   HTTP) in cui sarebbe utile inviare immediatamente la richiesta all'interno
   del segmento con l'ultimo ACK del \itindex{three~way~handshake}
-  \textit{three way handshake}; si potrebbe così risparmiare l'invio di un
+  \textit{three way handshake}; si potrebbe così risparmiare l'invio di un
   segmento successivo per la richiesta e il ritardo sul server fra la
   ricezione dell'ACK e quello della richiesta.
 
-  Se si invoca \const{TCP\_DEFER\_ACCEPT} su un socket dal lato client (cioè
+  Se si invoca \const{TCP\_DEFER\_ACCEPT} su un socket dal lato client (cioè
   dal lato da cui si invoca \func{connect}) si istruisce il kernel a non
   inviare immediatamente l'ACK finale del \itindex{three~way~handshake}
   \textit{three way handshake}, attendendo per un po' di tempo la prima
@@ -3311,21 +3311,21 @@ quantit
 
   Allo stesso tempo il protocollo TCP prevede che sul lato del server la
   funzione \func{accept} ritorni dopo la ricezione dell'ACK finale, in tal
-  caso quello che si fa usualmente è lanciare un nuovo processo per leggere i
-  successivi dati, che si bloccherà su una \func{read} se questi non sono
+  caso quello che si fa usualmente è lanciare un nuovo processo per leggere i
+  successivi dati, che si bloccherà su una \func{read} se questi non sono
   disponibili; in questo modo si saranno impiegate delle risorse (per la
   creazione del nuovo processo) che non vengono usate immediatamente.  L'uso
   di \const{TCP\_DEFER\_ACCEPT} consente di intervenire anche in questa
   situazione; quando la si invoca sul lato server (vale a dire su un socket in
-  ascolto) l'opzione fa sì che \func{accept} ritorni soltanto quando sono
+  ascolto) l'opzione fa sì che \func{accept} ritorni soltanto quando sono
   presenti dei dati sul socket, e non alla ricezione dell'ACK conclusivo del
   \itindex{three~way~handshake} \textit{three way handshake}.
 
   L'opzione prende un valore intero che indica il numero massimo di secondi
   per cui mantenere il ritardo, sia per quanto riguarda il ritorno di
   \func{accept} su un server, che per l'invio dell'ACK finale insieme ai dati
-  su un client. L'opzione è specifica di Linux non deve essere utilizzata in
-  codice che vuole essere portabile.\footnote{su FreeBSD è presente una
+  su un client. L'opzione è specifica di Linux non deve essere utilizzata in
+  codice che vuole essere portabile.\footnote{su FreeBSD è presente una
     opzione \texttt{SO\_ACCEPTFILTER} che consente di ottenere lo stesso
     comportamento di \const{TCP\_DEFER\_ACCEPT} per quanto riguarda il lato
     server.}
@@ -3351,14 +3351,14 @@ quantit
   anche in altri kernel (ad esempio FreeBSD) permette di controllare lo stato
   interno di un socket TCP direttamente da un programma in user space.
   L'opzione restituisce in una speciale struttura \struct{tcp\_info}, la cui
-  definizione è riportata in fig.~\ref{fig:tcp_info_struct}, tutta una serie
+  definizione è riportata in fig.~\ref{fig:tcp_info_struct}, tutta una serie
   di dati che il kernel mantiene, relativi al socket.  Anche questa opzione
   deve essere evitata se si vuole scrivere codice portabile.
 
   Con questa opzione diventa possibile ricevere una serie di informazioni
-  relative ad un socket TCP così da poter effettuare dei controlli senza dover
-  passare attraverso delle operazioni di lettura. Ad esempio si può verificare
-  se un socket è stato chiuso usando una funzione analoga a quella illustrata
+  relative ad un socket TCP così da poter effettuare dei controlli senza dover
+  passare attraverso delle operazioni di lettura. Ad esempio si può verificare
+  se un socket è stato chiuso usando una funzione analoga a quella illustrata
   in fig.~\ref{fig:is_closing}, in cui si utilizza il valore del campo
   \var{tcpi\_state} di \struct{tcp\_info} per controllare lo stato del socket.
 
@@ -3375,72 +3375,72 @@ quantit
 %Si noti come nell'esempio si sia (
 
 
-\item[\const{TCP\_QUICKACK}] con questa opzione è possibile eseguire una forma
+\item[\const{TCP\_QUICKACK}] con questa opzione è possibile eseguire una forma
   di controllo sull'invio dei segmenti ACK all'interno di in flusso di dati su
   TCP. In genere questo invio viene gestito direttamente dal kernel, il
   comportamento standard, corrispondente la valore logico di vero (in genere
-  1) per questa opzione, è quello di inviare immediatamente i segmenti ACK, in
-  quanto normalmente questo significa che si è ricevuto un blocco di dati e si
-  può passare all'elaborazione del blocco successivo.
+  1) per questa opzione, è quello di inviare immediatamente i segmenti ACK, in
+  quanto normalmente questo significa che si è ricevuto un blocco di dati e si
+  può passare all'elaborazione del blocco successivo.
 
-  Qualora però la nostra applicazione sappia in anticipo che alla ricezione di
-  un blocco di dati seguirà immediatamente l'invio di un altro
+  Qualora però la nostra applicazione sappia in anticipo che alla ricezione di
+  un blocco di dati seguirà immediatamente l'invio di un altro
   blocco,\footnote{caso tipico ad esempio delle risposte alle richieste HTTP.}
   poter accorpare quest'ultimo al segmento ACK permette di risparmiare sia in
-  termini di dati inviati che di velocità di risposta. Per far questo si può
-  utilizzare \const{TCP\_QUICKACK} impostando un valore logico falso (cioè 0),
-  in questo modo il kernel attenderà così da inviare il prossimo segmento di
+  termini di dati inviati che di velocità di risposta. Per far questo si può
+  utilizzare \const{TCP\_QUICKACK} impostando un valore logico falso (cioè 0),
+  in questo modo il kernel attenderà così da inviare il prossimo segmento di
   ACK insieme ai primi dati disponibili.
 
-  Si tenga presente che l'opzione non è permanente, vale a dire che una volta
-  che la si sia impostata a 0 il kernel la riporterà al valore di default dopo
-  il suo primo utilizzo. Sul lato server la si può impostare anche una volta
-  sola su un socket in ascolto, ed essa verrà ereditata da tutti i socket che
+  Si tenga presente che l'opzione non è permanente, vale a dire che una volta
+  che la si sia impostata a 0 il kernel la riporterà al valore di default dopo
+  il suo primo utilizzo. Sul lato server la si può impostare anche una volta
+  sola su un socket in ascolto, ed essa verrà ereditata da tutti i socket che
   si otterranno da esso al ritorno di \func{accept}.
 
 % TODO trattare con gli esempi di apache
 
 \item[\const{TCP\_CONGESTION}] questa opzione permette di impostare quale
   algoritmo per il controllo della congestione\footnote{il controllo della
-    congestione è un meccanismo previsto dal protocollo TCP (vedi
+    congestione è un meccanismo previsto dal protocollo TCP (vedi
     sez.~\ref{sec:tcp_protocol_xxx}) per evitare di trasmettere inutilmente
-    dati quando una connessione è congestionata; un buon algoritmo è
+    dati quando una connessione è congestionata; un buon algoritmo è
     fondamentale per il funzionamento del protocollo, dato che i pacchetti
     persi andrebbero ritrasmessi, per cui inviare un pacchetto su una linea
     congestionata potrebbe causare facilmente un peggioramento della
-    situazione.} utilizzare per il singolo socket. L'opzione è stata
+    situazione.} utilizzare per il singolo socket. L'opzione è stata
   introdotta con il kernel 2.6.13,\footnote{alla data di stesura di queste
-    note (Set. 2006) è pure scarsamente documentata, tanto che non è neanche
+    note (Set. 2006) è pure scarsamente documentata, tanto che non è neanche
     definita nelle intestazioni delle \acr{glibc} per cui occorre definirla a
-    mano al suo valore che è 13.} e prende come per \param{optval} il
+    mano al suo valore che è 13.} e prende come per \param{optval} il
   puntatore ad un buffer contenente il nome dell'algoritmo di controllo che
   si vuole usare. 
 
-  L'uso di un nome anziché di un valore numerico è dovuto al fatto che gli
+  L'uso di un nome anziché di un valore numerico è dovuto al fatto che gli
   algoritmi di controllo della congestione sono realizzati attraverso
   altrettanti moduli del kernel, e possono pertanto essere attivati a
   richiesta; il nome consente di caricare il rispettivo modulo e di introdurre
   moduli aggiuntivi che implementino altri meccanismi. 
 
-  Per poter disporre di questa funzionalità occorre aver compilato il kernel
+  Per poter disporre di questa funzionalità occorre aver compilato il kernel
   attivando l'opzione di configurazione generale
   \texttt{TCP\_CONG\_ADVANCED},\footnote{disponibile come \textit{TCP:
-      advanced congestion control} nel menù \textit{Network->Networking
-      options}, che a sua volta renderà disponibile un ulteriore menù con gli
+      advanced congestion control} nel menù \textit{Network->Networking
+      options}, che a sua volta renderà disponibile un ulteriore menù con gli
     algoritmi presenti.} e poi abilitare i singoli moduli voluti con le varie
   \texttt{TCP\_CONG\_*} presenti per i vari algoritmi disponibili; un elenco
-  di quelli attualmente supportati nella versione ufficiale del kernel è
-  riportato in tab.~\ref{tab:sock_tcp_congestion_algo}.\footnote{la lista è
+  di quelli attualmente supportati nella versione ufficiale del kernel è
+  riportato in tab.~\ref{tab:sock_tcp_congestion_algo}.\footnote{la lista è
     presa dalla versione 2.6.17.}
 
 
   Si tenga presente che prima della implementazione modulare alcuni di questi
   algoritmi erano disponibili soltanto come caratteristiche generali del
-  sistema, attivabili per tutti i socket, questo è ancora possibile con la
+  sistema, attivabili per tutti i socket, questo è ancora possibile con la
   \textit{sysctl} \texttt{tcp\_congestion\_control} (vedi
   sez.~\ref{sec:sock_ipv4_sysctl}) che ha sostituito le precedenti
   \textit{sysctl}.\footnote{riportate anche, alla data di stesura di queste
-    pagine (Set. 2006) nelle pagine di manuale, ma non più presenti.}
+    pagine (Set. 2006) nelle pagine di manuale, ma non più presenti.}
 
   \begin{table}[!htb]
     \centering
@@ -3486,14 +3486,14 @@ quantit
 \end{basedescript}
 
 
-Il protocollo UDP, anche per la sua maggiore semplicità, supporta un numero
+Il protocollo UDP, anche per la sua maggiore semplicità, supporta un numero
 ridotto di opzioni, riportate in tab.~\ref{tab:sock_opt_udplevel}; anche in
-questo caso per poterle utilizzare occorrerà impostare l'opportuno valore per
-l'argomento \param{level}, che è \const{SOL\_UDP} (o l'equivalente
+questo caso per poterle utilizzare occorrerà impostare l'opportuno valore per
+l'argomento \param{level}, che è \const{SOL\_UDP} (o l'equivalente
 \const{IPPROTO\_UDP}).  Le costanti che identificano dette opzioni sono
 definite in \file{netinet/udp.h}, ed accessibili includendo detto
 file.\footnote{come per TCP, la definizione delle opzioni effettivamente
-  supportate dal kernel si trova in realtà nel file \texttt{linux/udp.h}, dal
+  supportate dal kernel si trova in realtà nel file \texttt{linux/udp.h}, dal
   quale si sono estratte le costanti di tab.~\ref{tab:sock_opt_udplevel}.}
 
 \begin{table}[!htb]
@@ -3519,20 +3519,20 @@ file.\footnote{come per TCP, la definizione delle opzioni effettivamente
 % TODO documentare \const{UDP\_ENCAP} 
 
 Ancora una volta le descrizioni contenute tab.~\ref{tab:sock_opt_udplevel}
-sono un semplice riferimento, una maggiore quantità di dettagli sulle
-caratteristiche delle opzioni citate è quello dell'elenco seguente:
+sono un semplice riferimento, una maggiore quantità di dettagli sulle
+caratteristiche delle opzioni citate è quello dell'elenco seguente:
 \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
 
 \item[\const{UDP\_CORK}] questa opzione ha l'identico effetto dell'analoga
   \const{TCP\_CORK} vista in precedenza per il protocollo TCP, e quando
   abilitata consente di accumulare i dati in uscita su un solo pacchetto che
-  verrà inviato una volta che la si disabiliti. L'opzione è stata introdotta
+  verrà inviato una volta che la si disabiliti. L'opzione è stata introdotta
   con il kernel 2.5.44, e non deve essere utilizzata in codice che vuole
   essere portabile.
 
 \item[\const{UDP\_ENCAP}] Questa opzione permette di gestire l'incapsulazione
-  dei dati nel protocollo UDP. L'opzione è stata introdotta con il kernel
-  2.5.67, e non è documentata. Come la precedente è specifica di Linux e non
+  dei dati nel protocollo UDP. L'opzione è stata introdotta con il kernel
+  2.5.67, e non è documentata. Come la precedente è specifica di Linux e non
   deve essere utilizzata in codice portabile.
 
 \end{basedescript}
@@ -3543,9 +3543,9 @@ caratteristiche delle opzioni citate 
 \section{La gestione attraverso le funzioni di controllo}
 \label{sec:sock_ctrl_func}
 
-Benché la maggior parte delle caratteristiche dei socket sia gestibile con le
-funzioni \func{setsockopt} e \func{getsockopt}, alcune proprietà possono
-essere impostate attraverso le funzioni \func{fcntl} e \func{ioctl} già
+Benché la maggior parte delle caratteristiche dei socket sia gestibile con le
+funzioni \func{setsockopt} e \func{getsockopt}, alcune proprietà possono
+essere impostate attraverso le funzioni \func{fcntl} e \func{ioctl} già
 trattate in sez.~\ref{sec:file_fcntl} e sez.~\ref{sec:file_ioctl}; in
 quell'occasione abbiamo parlato di queste funzioni esclusivamente nell'ambito
 della loro applicazione a file descriptor associati a dei file normali; qui
@@ -3558,15 +3558,15 @@ dei socket.
 
 Tratteremo in questa sezione le caratteristiche specifiche delle funzioni
 \func{ioctl} e \func{fcntl} quando esse vengono utilizzate con dei socket
-generici. Quanto già detto in precedenza in sez.~\ref{sec:file_fcntl} e
+generici. Quanto già detto in precedenza in sez.~\ref{sec:file_fcntl} e
 sez.~\ref{sec:file_ioctl} continua a valere; quello che tratteremo qui sono le
 operazioni ed i comandi che sono validi, o che hanno significati peculiari,
 quando queste funzioni vengono applicate a dei socket generici.
 
-Nell'elenco seguente si riportano i valori specifici che può assumere il
+Nell'elenco seguente si riportano i valori specifici che può assumere il
 secondo argomento della funzione \func{ioctl} (\param{request}, che indica il
 tipo di operazione da effettuare) quando essa viene applicata ad un socket
-generico. Nell'elenco si illustrerà anche, per ciascuna operazione, il tipo di
+generico. Nell'elenco si illustrerà anche, per ciascuna operazione, il tipo di
 dato usato come terzo argomento della funzione ed il significato che esso
 viene ad assumere.  Dato che in caso di lettura questi dati vengono restituiti
 come \itindex{value~result~argument} \textit{value result argument}, con
@@ -3576,9 +3576,9 @@ identificano le operazioni sono le seguenti:
 \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
 \item[\const{SIOCGSTAMP}] restituisce il contenuto di una struttura
   \struct{timeval} con la marca temporale dell'ultimo pacchetto ricevuto sul
-  socket, questa operazione può essere utilizzata per effettuare delle
+  socket, questa operazione può essere utilizzata per effettuare delle
   misurazioni precise del tempo di andata e ritorno\footnote{il
-    \itindex{Round~Trip~Time} \textit{Round Trip Time} cui abbiamo già
+    \itindex{Round~Trip~Time} \textit{Round Trip Time} cui abbiamo già
     accennato in sez.~\ref{sec:net_tcp}.} dei pacchetti sulla rete.
 
 \item[\const{SIOCSPGRP}] imposta il processo o il \itindex{process~group}
@@ -3589,7 +3589,7 @@ identificano le operazioni sono le seguenti:
   \type{pid\_t}; un valore positivo indica direttamente il \acr{pid} del
   processo, mentre un valore negativo indica (col valore assoluto) il
   \textit{process group}. Senza privilegi di amministratore o la capability
-  \const{CAP\_KILL} si può impostare solo se stessi o il proprio
+  \const{CAP\_KILL} si può impostare solo se stessi o il proprio
   \textit{process group}.
 
 \item[\const{SIOCGPGRP}] legge le impostazioni presenti sul socket
@@ -3597,21 +3597,21 @@ identificano le operazioni sono le seguenti:
   \textit{process group} cui devono essere inviati i segnali \const{SIGIO} e
   \const{SIGURG}. Come per \const{SIOCSPGRP} l'argomento passato deve un
   puntatore ad una variabile di tipo \type{pid\_t}, con lo stesso significato.
-  Qualora non sia presente nessuna impostazione verrà restituito un valore
+  Qualora non sia presente nessuna impostazione verrà restituito un valore
   nullo.
 
-\item[\const{FIOASYNC}] Abilita o disabilita la modalità di I/O asincrono sul
+\item[\const{FIOASYNC}] Abilita o disabilita la modalità di I/O asincrono sul
   socket. Questo significa (vedi sez.~\ref{sec:file_asyncronous_operation})
-  che verrà inviato il segnale di \const{SIGIO} (o quanto impostato con
+  che verrà inviato il segnale di \const{SIGIO} (o quanto impostato con
   \const{F\_SETSIG}, vedi sez.~\ref{sec:file_fcntl}) in caso di eventi di I/O
   sul socket.
 \end{basedescript}
 
 Nel caso dei socket generici anche \func{fcntl} prevede un paio di comandi
 specifici; in questo caso il secondo argomento (\param{cmd}, che indica il
-comando) può assumere i due valori \const{FIOGETOWN} e \const{FIOSETOWN},
-mentre il terzo argomento dovrà essere un puntatore ad una variabile di tipo
-\type{pid\_t}. Questi due comandi sono una modalità alternativa di eseguire le
+comando) può assumere i due valori \const{FIOGETOWN} e \const{FIOSETOWN},
+mentre il terzo argomento dovrà essere un puntatore ad una variabile di tipo
+\type{pid\_t}. Questi due comandi sono una modalità alternativa di eseguire le
 stesse operazioni (lettura o impostazione del processo o del gruppo di
 processo che riceve i segnali) che si effettuano chiamando \func{ioctl} con
 \const{SIOCGPGRP} e \const{SIOCSPGRP}.
@@ -3620,12 +3620,12 @@ processo che riceve i segnali) che si effettuano chiamando \func{ioctl} con
 \subsection{L'uso di \func{ioctl} per l'accesso ai dispositivi di rete}
 \label{sec:sock_ioctl_netdevice}
 
-Benché non strettamente attinenti alla gestione dei socket, vale la pena di
+Benché non strettamente attinenti alla gestione dei socket, vale la pena di
 trattare qui l'interfaccia di accesso a basso livello ai dispositivi di rete
-che viene appunto fornita attraverso la funzione \texttt{ioctl}. Questa non è
+che viene appunto fornita attraverso la funzione \texttt{ioctl}. Questa non è
 attinente a caratteristiche specifiche di un qualche protocollo, ma si applica
 a tutti i socket, indipendentemente da tipo e famiglia degli stessi, e
-permette di impostare e rilevare le funzionalità delle interfacce di rete.
+permette di impostare e rilevare le funzionalità delle interfacce di rete.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -3639,44 +3639,44 @@ permette di impostare e rilevare le funzionalit
 
 Tutte le operazioni di questo tipo utilizzano come terzo argomento di
 \func{ioctl} il puntatore ad una struttura \struct{ifreq}, la cui definizione
-è illustrata in fig.~\ref{fig:netdevice_ifreq_struct}. Normalmente si utilizza
+è illustrata in fig.~\ref{fig:netdevice_ifreq_struct}. Normalmente si utilizza
 il primo campo della struttura, \var{ifr\_name} per specificare il nome
 dell'interfaccia su cui si vuole operare (ad esempio \texttt{eth0},
 \texttt{ppp0}, ecc.), e si inseriscono (o ricevono) i valori relativi alle
-diversa caratteristiche e funzionalità nel secondo campo, che come si può
-notare è definito come una \ctyp{union} proprio in quanto il suo significato
+diversa caratteristiche e funzionalità nel secondo campo, che come si può
+notare è definito come una \ctyp{union} proprio in quanto il suo significato
 varia a secondo dell'operazione scelta.
 
 Si tenga inoltre presente che alcune di queste operazioni (in particolare
 quelle che modificano le caratteristiche dell'interfaccia) sono privilegiate e
 richiedono i privilegi di amministratore o la \itindex{capabilities}
-\textit{capability} \const{CAP\_NET\_ADMIN}, altrimenti si otterrà un errore
+\textit{capability} \const{CAP\_NET\_ADMIN}, altrimenti si otterrà un errore
 di \errval{EPERM}.  Le costanti che identificano le operazioni disponibili
 sono le seguenti:
 \begin{basedescript}{\desclabelwidth{2.7cm}\desclabelstyle{\nextlinelabel}}
-\item[\const{SIOCGIFNAME}] questa è l'unica operazione che usa il campo
+\item[\const{SIOCGIFNAME}] questa è l'unica operazione che usa il campo
   \var{ifr\_name} per restituire un risultato, tutte le altre lo utilizzano
   per indicare l'interfaccia sulla quale operare. L'operazione richiede che si
   indichi nel campo \var{ifr\_ifindex} il valore numerico dell'\textsl{indice}
   dell'interfaccia, e restituisce il relativo nome in \var{ifr\_name}.
 
   Il kernel infatti assegna ad ogni interfaccia un numero progressivo, detto
-  appunto \itindex{interface~index} \textit{interface index}, che è quello che
+  appunto \itindex{interface~index} \textit{interface index}, che è quello che
   effettivamente la identifica nelle operazioni a basso livello, il nome
-  dell'interfaccia è soltanto una etichetta associata a detto \textsl{indice},
-  che permette di rendere più comprensibile l'indicazione dell'interfaccia
-  all'interno dei comandi. Una modalità per ottenere questo valore è usare il
+  dell'interfaccia è soltanto una etichetta associata a detto \textsl{indice},
+  che permette di rendere più comprensibile l'indicazione dell'interfaccia
+  all'interno dei comandi. Una modalità per ottenere questo valore è usare il
   comando \cmd{ip link}, che fornisce un elenco delle interfacce presenti
   ordinato in base a tale valore (riportato come primo campo).
   
 
 \item[\const{SIOCGIFINDEX}] restituisce nel campo \var{ifr\_ifindex} il valore
-  numerico dell'indice dell'interfaccia specificata con \var{ifr\_name}, è in
+  numerico dell'indice dell'interfaccia specificata con \var{ifr\_name}, è in
   sostanza l'operazione inversa di \const{SIOCGIFNAME}.
 
 \item[\const{SIOCGIFFLAGS}] permette di ottenere nel campo \var{ifr\_flags} il
   valore corrente dei flag dell'interfaccia specificata (con \var{ifr\_name}).
-  Il valore restituito è una maschera binaria i cui bit sono identificabili
+  Il valore restituito è una maschera binaria i cui bit sono identificabili
   attraverso le varie costanti di tab.~\ref{tab:netdevice_iface_flag}.
 
 \begin{table}[htb]
@@ -3687,34 +3687,34 @@ sono le seguenti:
     \textbf{Flag} & \textbf{Significato} \\
     \hline
     \hline
-    \const{IFF\_UP}        & L'interfaccia è attiva.\\
+    \const{IFF\_UP}        & L'interfaccia è attiva.\\
     \const{IFF\_BROADCAST} & L'interfaccia ha impostato un indirizzo di
                              \itindex{broadcast} \textit{broadcast} valido.\\
-    \const{IFF\_DEBUG}     & È attivo il flag interno di debug.\\
-    \const{IFF\_LOOPBACK}  & L'interfaccia è una interfaccia di
+    \const{IFF\_DEBUG}     & È attivo il flag interno di debug.\\
+    \const{IFF\_LOOPBACK}  & L'interfaccia è una interfaccia di
                              \textit{loopback}.\\ 
-    \const{IFF\_POINTOPOINT}&L'interfaccia è associata ad un collegamento
+    \const{IFF\_POINTOPOINT}&L'interfaccia è associata ad un collegamento
                              \textsl{punto-punto}.\\ 
-    \const{IFF\_RUNNING}   & L'interfaccia ha delle risorse allocate (non può
+    \const{IFF\_RUNNING}   & L'interfaccia ha delle risorse allocate (non può
                              quindi essere disattivata).\\
     \const{IFF\_NOARP}     & L'interfaccia ha il protocollo ARP disabilitato o
-                             l'indirizzo del livello di rete non è impostato.\\
-    \const{IFF\_PROMISC}   & L'interfaccia è in \index{modo~promiscuo}
-                             \textsl{modo promiscuo} (riceve cioè tutti i
+                             l'indirizzo del livello di rete non è impostato.\\
+    \const{IFF\_PROMISC}   & L'interfaccia è in \index{modo~promiscuo}
+                             \textsl{modo promiscuo} (riceve cioè tutti i
                              pacchetti che vede passare, compresi quelli non
                              direttamente indirizzati a lei).\\
     \const{IFF\_NOTRAILERS}& Evita l'uso di \textit{trailer} nei pacchetti.\\
     \const{IFF\_ALLMULTI}  & Riceve tutti i pacchetti di  \itindex{multicast}
                              \textit{multicast}.\\
-    \const{IFF\_MASTER}    & L'interfaccia è il master di un bundle per il
+    \const{IFF\_MASTER}    & L'interfaccia è il master di un bundle per il
                              bilanciamento di carico.\\
-    \const{IFF\_SLAVE}     & L'interfaccia è uno slave di un bundle per il
+    \const{IFF\_SLAVE}     & L'interfaccia è uno slave di un bundle per il
                              bilanciamento di carico.\\
     \const{IFF\_MULTICAST} & L'interfaccia ha il supporto per il
                              \textit{multicast} \itindex{multicast} attivo.\\
-    \const{IFF\_PORTSEL}   & L'interfaccia può impostare i suoi parametri
+    \const{IFF\_PORTSEL}   & L'interfaccia può impostare i suoi parametri
                              hardware (con l'uso di \struct{ifmap}).\\
-    \const{IFF\_AUTOMEDIA} & L'interfaccia è in grado di selezionare
+    \const{IFF\_AUTOMEDIA} & L'interfaccia è in grado di selezionare
                              automaticamente il tipo di collegamento.\\
     \const{IFF\_DYNAMIC}   & Gli indirizzi assegnati all'interfaccia vengono
                              persi quando questa viene disattivata.\\
@@ -3730,13 +3730,13 @@ sono le seguenti:
 \item[\const{SIOCSIFFLAGS}] permette di impostare il valore dei flag
   dell'interfaccia specificata (sempre con \var{ifr\_name}, non staremo a
   ripeterlo oltre) attraverso il valore della maschera binaria da passare nel
-  campo \var{ifr\_flags}, che può essere ottenuta con l'OR aritmetico delle
-  costanti di tab.~\ref{tab:netdevice_iface_flag}; questa operazione è
+  campo \var{ifr\_flags}, che può essere ottenuta con l'OR aritmetico delle
+  costanti di tab.~\ref{tab:netdevice_iface_flag}; questa operazione è
   privilegiata.
 
 \item[\const{SIOCGIFMETRIC}] permette di leggere il valore della metrica del
   dispositivo associato all'interfaccia specificata nel campo
-  \var{ifr\_metric}.  Attualmente non è implementato, e l'operazione
+  \var{ifr\_metric}.  Attualmente non è implementato, e l'operazione
   restituisce sempre un valore nullo.
 
 \item[\const{SIOCSIFMETRIC}] permette di impostare il valore della metrica del
@@ -3749,8 +3749,8 @@ sono le seguenti:
 
 \item[\const{SIOCSIFMTU}] permette di impostare il valore della
   \itindex{Maximum~Transfer~Unit} \textit{Maximum Transfer Unit} del
-  dispositivo al valore specificato campo \var{ifr\_mtu}. L'operazione è
-  privilegiata, e si tenga presente che impostare un valore troppo basso può
+  dispositivo al valore specificato campo \var{ifr\_mtu}. L'operazione è
+  privilegiata, e si tenga presente che impostare un valore troppo basso può
   causare un blocco del kernel.
 
 \item[\const{SIOCGIFHWADDR}] permette di leggere il valore dell'indirizzo
@@ -3763,17 +3763,17 @@ sono le seguenti:
 \item[\const{SIOCSIFHWADDR}] permette di impostare il valore dell'indirizzo
   hardware del dispositivo associato all'interfaccia attraverso il valore
   della struttura \struct{sockaddr} (con lo stesso formato illustrato per
-  \const{SIOCGIFHWADDR}) passata nel campo \var{ifr\_hwaddr}. L'operazione è
+  \const{SIOCGIFHWADDR}) passata nel campo \var{ifr\_hwaddr}. L'operazione è
   privilegiata.
 
 \item[\const{SIOCSIFHWBROADCAST}] imposta l'indirizzo \textit{broadcast}
   \itindex{broadcast} hardware dell'interfaccia al valore specificato dal
-  campo \var{ifr\_hwaddr}. L'operazione è privilegiata.
+  campo \var{ifr\_hwaddr}. L'operazione è privilegiata.
 
 \item[\const{SIOCGIFMAP}] legge alcuni parametri hardware (memoria, interrupt,
   canali di DMA) del driver dell'interfaccia specificata, restituendo i
   relativi valori nel campo \var{ifr\_map}; quest'ultimo contiene una
-  struttura di tipo \struct{ifmap}, la cui definizione è illustrata in
+  struttura di tipo \struct{ifmap}, la cui definizione è illustrata in
   fig.~\ref{fig:netdevice_ifmap_struct}.
 
 \begin{figure}[!htb]
@@ -3795,15 +3795,15 @@ sono le seguenti:
 \item[\const{SIOCADDMULTI}] aggiunge un indirizzo di \itindex{multicast}
   \textit{multicast} ai filtri del livello di collegamento associati
   dell'interfaccia. Si deve usare un indirizzo hardware da specificare
-  attraverso il campo \var{ifr\_hwaddr}, che conterrà l'opportuna struttura
-  \struct{sockaddr}; l'operazione è privilegiata. Per una modalità alternativa
+  attraverso il campo \var{ifr\_hwaddr}, che conterrà l'opportuna struttura
+  \struct{sockaddr}; l'operazione è privilegiata. Per una modalità alternativa
   per eseguire la stessa operazione si possono usare i \textit{packet socket},
   vedi sez.~\ref{sec:packet_socket}.
 
 \item[\const{SIOCDELMULTI}] rimuove un indirizzo di \itindex{multicast}
   \textit{multicast} ai filtri del livello di collegamento dell'interfaccia,
   vuole un indirizzo hardware specificato come per \const{SIOCADDMULTI}. Anche
-  questa operazione è privilegiata e può essere eseguita in forma alternativa
+  questa operazione è privilegiata e può essere eseguita in forma alternativa
   con i \textit{packet socket}.
 
 \item[\const{SIOCGIFTXQLEN}] permette di leggere la lunghezza della coda di
@@ -3812,7 +3812,7 @@ sono le seguenti:
 
 \item[\const{SIOCSIFTXQLEN}] permette di impostare il valore della lunghezza
   della coda di trasmissione del dispositivo associato all'interfaccia, questo
-  deve essere specificato nel campo \var{ifr\_qlen}. L'operazione è
+  deve essere specificato nel campo \var{ifr\_qlen}. L'operazione è
   privilegiata. 
 
 \item[\const{SIOCSIFNAME}] consente di cambiare il nome dell'interfaccia
@@ -3822,9 +3822,9 @@ sono le seguenti:
 \end{basedescript}
 
 Una ulteriore operazione, che consente di ricavare le caratteristiche delle
-interfacce di rete, è \const{SIOCGIFCONF}; però per ragioni di compatibilità
-questa operazione è disponibile soltanto per i socket della famiglia
-\const{AF\_INET} (vale ad dire per socket IPv4). In questo caso l'utente dovrà
+interfacce di rete, è \const{SIOCGIFCONF}; però per ragioni di compatibilità
+questa operazione è disponibile soltanto per i socket della famiglia
+\const{AF\_INET} (vale ad dire per socket IPv4). In questo caso l'utente dovrà
 passare come argomento una struttura \struct{ifconf}, definita in
 fig.~\ref{fig:netdevice_ifconf_struct}.
 
@@ -3837,30 +3837,30 @@ fig.~\ref{fig:netdevice_ifconf_struct}.
   \label{fig:netdevice_ifconf_struct}
 \end{figure}
 
-Per eseguire questa operazione occorrerà allocare preventivamente un buffer di
+Per eseguire questa operazione occorrerà allocare preventivamente un buffer di
 contenente un vettore di strutture \struct{ifreq}. La dimensione (in byte) di
 questo buffer deve essere specificata nel campo \var{ifc\_len} di
-\struct{ifconf}, mentre il suo indirizzo andrà specificato nel campo
+\struct{ifconf}, mentre il suo indirizzo andrà specificato nel campo
 \var{ifc\_req}. Qualora il buffer sia stato allocato come una stringa, il suo
-indirizzo potrà essere fornito usando il campo \var{ifc\_buf}.\footnote{si
-  noti che l'indirizzo del buffer è definito in \struct{ifconf} con una
+indirizzo potrà essere fornito usando il campo \var{ifc\_buf}.\footnote{si
+  noti che l'indirizzo del buffer è definito in \struct{ifconf} con una
   \ctyp{union}, questo consente di utilizzare una delle due forme a piacere.}
 
 La funzione restituisce nel buffer indicato una serie di strutture
 \struct{ifreq} contenenti nel campo \var{ifr\_name} il nome dell'interfaccia e
 nel campo \var{ifr\_addr} il relativo indirizzo IP.  Se lo spazio allocato nel
-buffer è sufficiente il kernel scriverà una struttura \struct{ifreq} per
+buffer è sufficiente il kernel scriverà una struttura \struct{ifreq} per
 ciascuna interfaccia attiva, restituendo nel campo \var{ifc\_len} il totale
-dei byte effettivamente scritti. Il valore di ritorno è 0 se l'operazione ha
+dei byte effettivamente scritti. Il valore di ritorno è 0 se l'operazione ha
 avuto successo e negativo in caso contrario. 
 
-Si tenga presente che il kernel non scriverà mai sul buffer di uscita dati
+Si tenga presente che il kernel non scriverà mai sul buffer di uscita dati
 eccedenti numero di byte specificato col valore di \var{ifc\_len} impostato
 alla chiamata della funzione, troncando il risultato se questi non dovessero
 essere sufficienti. Questa condizione non viene segnalata come errore per cui
 occorre controllare il valore di \var{ifc\_len} all'uscita della funzione, e
-verificare che esso sia inferiore a quello di ingresso. In caso contrario si è
-probabilmente\footnote{probabilmente perché si potrebbe essere nella
+verificare che esso sia inferiore a quello di ingresso. In caso contrario si è
+probabilmente\footnote{probabilmente perché si potrebbe essere nella
   condizione in cui sono stati usati esattamente quel numero di byte.} avuta
 una situazione di troncamento dei dati.
 
@@ -3873,31 +3873,31 @@ una situazione di troncamento dei dati.
   \label{fig:netdevice_iflist}
 \end{figure}
 
-Come esempio dell'uso di queste funzioni si è riportato in
+Come esempio dell'uso di queste funzioni si è riportato in
 fig.~\ref{fig:netdevice_iflist} il corpo principale del programma
 \texttt{iflist} in cui si utilizza l'operazione \const{SIOCGIFCONF} per
 ottenere una lista delle interfacce attive e dei relativi indirizzi. Al solito
-il codice completo è fornito nei sorgenti allegati alla guida.
+il codice completo è fornito nei sorgenti allegati alla guida.
 
 Il programma inizia (\texttt{\small 7--11}) con la creazione del socket
 necessario ad eseguire l'operazione, dopo di che si inizializzano
 opportunamente (\texttt{\small 13--14}) i valori della struttura
 \struct{ifconf} indicando la dimensione del buffer ed il suo
 indirizzo;\footnote{si noti come in questo caso si sia specificato l'indirizzo
-  usando il campo \var{ifc\_buf}, mentre nel seguito del programma si accederà
+  usando il campo \var{ifc\_buf}, mentre nel seguito del programma si accederà
   ai valori contenuti nel buffer usando \var{ifc\_req}.} si esegue poi
 l'operazione invocando \func{ioctl}, controllando come sempre la corretta
 esecuzione, ed uscendo in caso di errore (\texttt{\small 15--19}).
 
-Si esegue poi un controllo sulla quantità di dati restituiti segnalando un
-eventuale overflow del buffer (\texttt{\small 21--23}); se invece è tutto a
+Si esegue poi un controllo sulla quantità di dati restituiti segnalando un
+eventuale overflow del buffer (\texttt{\small 21--23}); se invece è tutto a
 posto (\texttt{\small 24--27}) si calcola e si stampa a video il numero di
 interfacce attive trovate.  L'ultima parte del programma (\texttt{\small
-  28--33}) è il ciclo sul contenuto delle varie strutture \struct{ifreq}
+  28--33}) è il ciclo sul contenuto delle varie strutture \struct{ifreq}
 restituite in cui si estrae (\texttt{\small 30}) l'indirizzo ad esse
-assegnato\footnote{si è definito \var{access} come puntatore ad una struttura
+assegnato\footnote{si è definito \var{access} come puntatore ad una struttura
   di tipo \struct{sockaddr\_in} per poter eseguire un \textit{casting}
-  dell'indirizzo del valore restituito nei vari campi \var{ifr\_addr}, così
+  dell'indirizzo del valore restituito nei vari campi \var{ifr\_addr}, così
   poi da poterlo poi usare come argomento di \func{inet\_ntoa}.}  e lo si
 stampa (\texttt{\small 31--32}) insieme al nome dell'interfaccia.
 
@@ -3907,18 +3907,18 @@ stampa (\texttt{\small 31--32}) insieme al nome dell'interfaccia.
 \label{sec:sock_ioctl_IP}
 
 Non esistono operazioni specifiche per i socket IP in quanto tali,\footnote{a
-  parte forse \const{SIOCGIFCONF}, che però resta attinente alle proprietà
+  parte forse \const{SIOCGIFCONF}, che però resta attinente alle proprietà
   delle interfacce di rete, per cui l'abbiamo trattata in
   sez.~\ref{sec:sock_ioctl_netdevice} insieme alle altre che comunque si
   applicano anche ai socket IP.} mentre per i pacchetti di altri protocolli
-trasportati su IP, qualora li si gestisca attraverso dei socket, si dovrà fare
+trasportati su IP, qualora li si gestisca attraverso dei socket, si dovrà fare
 riferimento direttamente all'eventuale supporto presente per il tipo di socket
 usato: ad esempio si possono ricevere pacchetti ICMP con socket di tipo
-\texttt{raw}, nel qual caso si dovrà fare riferimento alle operazioni di
+\texttt{raw}, nel qual caso si dovrà fare riferimento alle operazioni di
 quest'ultimo.
 
 Tuttavia la gran parte dei socket utilizzati nella programmazione di rete
-utilizza proprio il protocollo IP, e quello che succede è che in realtà la
+utilizza proprio il protocollo IP, e quello che succede è che in realtà la
 funzione \func{ioctl} consente di effettuare alcune operazioni specifiche per
 i socket che usano questo protocollo, ma queste vendono eseguite, invece che a
 livello di IP, al successivo livello di trasporto, vale a dire in maniera
@@ -3931,30 +3931,30 @@ illustrate nell'elenco seguente; il terzo argomento della funzione, gestito
 come \itindex{value~result~argument} \textit{value result argument}, deve
 essere sempre il puntatore ad una variabile di tipo \ctyp{int}:
 \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
-\item[\const{SIOCINQ}] restituisce la quantità di dati non ancora letti
+\item[\const{SIOCINQ}] restituisce la quantità di dati non ancora letti
   presenti nel buffer di ricezione; il socket non deve essere in stato
-  \texttt{LISTEN}, altrimenti si avrà un errore di \errval{EINVAL}.
+  \texttt{LISTEN}, altrimenti si avrà un errore di \errval{EINVAL}.
 \item[\const{SIOCATMARK}] ritorna un intero non nullo, da intendere come
-  valore logico, se il flusso di dati letti sul socket è arrivato sulla
+  valore logico, se il flusso di dati letti sul socket è arrivato sulla
   posizione (detta anche \textit{urgent mark}) in cui sono stati ricevuti
   \itindex{out-of-band} dati urgenti (vedi sez.~\ref{sec:TCP_urgent_data}).
   Una operazione di lettura da un socket non attraversa mai questa posizione,
-  per cui è possibile controllare se la si è raggiunta o meno con questa
+  per cui è possibile controllare se la si è raggiunta o meno con questa
   operazione.
 
-  Questo è utile quando si attiva l'opzione \const{SO\_OOBINLINE} (vedi
+  Questo è utile quando si attiva l'opzione \const{SO\_OOBINLINE} (vedi
   sez.~\ref{sec:sock_generic_options}) per ricevere i dati urgenti all'interno
   del flusso dei dati ordinari del socket;\footnote{vedremo in
     sez.~\ref{sec:TCP_urgent_data} che in genere i dati urgenti presenti su un
     socket si leggono \textit{out-of-band} usando un opportuno flag per
     \func{recvmsg}.}  in tal caso quando \const{SIOCATMARK} restituisce un
-  valore non nullo si saprà che la successiva lettura dal socket restituirà i
+  valore non nullo si saprà che la successiva lettura dal socket restituirà i
   dati urgenti e non il normale traffico; torneremo su questo in maggior
   dettaglio in sez.~\ref{sec:TCP_urgent_data}.
 
-\item[\const{SIOCOUTQ}] restituisce la quantità di dati non ancora inviati
+\item[\const{SIOCOUTQ}] restituisce la quantità di dati non ancora inviati
   presenti nel buffer di spedizione; come per \const{SIOCINQ} il socket non
-  deve essere in stato \texttt{LISTEN}, altrimenti si avrà un errore di
+  deve essere in stato \texttt{LISTEN}, altrimenti si avrà un errore di
   \errval{EINVAL}.
 \end{basedescript}
 
@@ -3968,7 +3968,7 @@ tipo \ctyp{int}:
 \item[\const{FIONREAD}] restituisce la dimensione in byte del primo pacchetto
   in attesa di ricezione, o 0 qualora non ci sia nessun pacchetto.
 \item[\const{TIOCOUTQ}] restituisce il numero di byte presenti nella coda di
-  invio locale; questa opzione è supportata soltanto a partire dal kernel 2.4
+  invio locale; questa opzione è supportata soltanto a partire dal kernel 2.4
 \end{basedescript}
 
 
@@ -3977,33 +3977,33 @@ tipo \ctyp{int}:
 \label{sec:sock_sysctl_proc}
 
 Come ultimo argomento di questo capitolo tratteremo l'uso della funzione
-\func{sysctl} (che è stata introdotta nelle sue funzionalità generiche in
-sez.~\ref{sec:sys_sysctl}) per quanto riguarda le sue capacità di effettuare
-impostazioni relative alle proprietà dei socket.  Dato che le stesse
-funzionalità sono controllabili direttamente attraverso il filesystem
+\func{sysctl} (che è stata introdotta nelle sue funzionalità generiche in
+sez.~\ref{sec:sys_sysctl}) per quanto riguarda le sue capacità di effettuare
+impostazioni relative alle proprietà dei socket.  Dato che le stesse
+funzionalità sono controllabili direttamente attraverso il filesystem
 \texttt{/proc}, le tratteremo attraverso i file presenti in quest'ultimo.
 
 
-\subsection{L'uso di \func{sysctl} e \texttt{/proc} per le proprietà della
+\subsection{L'uso di \func{sysctl} e \texttt{/proc} per le proprietà della
   rete}
 \label{sec:sock_sysctl}
 
 La differenza nell'uso di \func{sysctl} e del filesystem \texttt{/proc}
 rispetto a quello delle funzioni \func{ioctl} e \func{fcntl} visto in
 sez.~\ref{sec:sock_ctrl_func} o all'uso di \func{getsockopt} e
-\func{setsockopt} è che queste funzioni consentono di controllare le proprietà
+\func{setsockopt} è che queste funzioni consentono di controllare le proprietà
 di un singolo socket, mentre con \func{sysctl} e con \texttt{/proc} si
-impostano proprietà (o valori di default) validi a livello dell'intero
-sistema, e cioè per tutti i socket.
+impostano proprietà (o valori di default) validi a livello dell'intero
+sistema, e cioè per tutti i socket.
 
-Le opzioni disponibili per le proprietà della rete, nella gerarchia dei valori
+Le opzioni disponibili per le proprietà della rete, nella gerarchia dei valori
 impostabili con \func{sysctl}, sono riportate sotto il nodo \texttt{net}, o,
 se acceduti tramite l'interfaccia del filesystem \texttt{/proc}, sotto
 \texttt{/proc/sys/net}. In genere sotto questa directory compaiono le
 sottodirectory (corrispondenti ad altrettanti sotto-nodi per \func{sysctl})
-relative ai vari protocolli e tipi di interfacce su cui è possibile
+relative ai vari protocolli e tipi di interfacce su cui è possibile
 intervenire per effettuare impostazioni; un contenuto tipico di questa
-directory è il seguente:
+directory è il seguente:
 \begin{verbatim}
 /proc/sys/net/
 |-- core
@@ -4015,13 +4015,13 @@ directory 
 `-- unix
 \end{verbatim}
 e sono presenti varie centinaia di parametri, molti dei quali non sono neanche
-documentati; nel nostro caso ci limiteremo ad illustrare quelli più
+documentati; nel nostro caso ci limiteremo ad illustrare quelli più
 significativi.
 
-Si tenga presente infine che se è sempre possibile utilizzare il filesystem
+Si tenga presente infine che se è sempre possibile utilizzare il filesystem
 \texttt{/proc} come sostituto di \func{sysctl}, dato che i valori di nodi e
 sotto-nodi di quest'ultima sono mappati come file e directory sotto
-\texttt{/proc/sys/}, non è vero il contrario, ed in particolare Linux consente
+\texttt{/proc/sys/}, non è vero il contrario, ed in particolare Linux consente
 di impostare alcuni parametri o leggere lo stato della rete a livello di
 sistema sotto \texttt{/proc/net}, dove sono presenti dei file che non
 corrispondono a nessun nodo di \func{sysctl}.
@@ -4037,15 +4037,15 @@ socket.  Quelli descritti anche nella pagina di manuale, accessibile con
 
 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
 \item[\procrelfile{/proc/sys/net/core}{rmem\_default}] imposta la dimensione
-  di default del buffer di ricezione (cioè per i dati in ingresso) dei socket.
+  di default del buffer di ricezione (cioè per i dati in ingresso) dei socket.
 \item[\procrelfile{/proc/sys/net/core}{rmem\_max}] imposta la dimensione
-  massima che si può assegnare al buffer di ricezione dei socket attraverso
+  massima che si può assegnare al buffer di ricezione dei socket attraverso
   l'uso dell'opzione \const{SO\_RCVBUF}.
 \item[\procrelfile{/proc/sys/net/core}{wmem\_default}] imposta la dimensione
-  di default del buffer di trasmissione (cioè per i dati in uscita) dei
+  di default del buffer di trasmissione (cioè per i dati in uscita) dei
   socket.
 \item[\procrelfile{/proc/sys/net/core}{wmem\_max}] imposta la dimensione
-  massima che si può assegnare al buffer di trasmissione dei socket attraverso
+  massima che si può assegnare al buffer di trasmissione dei socket attraverso
   l'uso dell'opzione \const{SO\_SNDBUF}.
 \item[\procrelfile{/proc/sys/net/core}{message\_cost},
   \procrelfile{/proc/sys/net/core}{message\_burst}] contengono le impostazioni
@@ -4057,8 +4057,8 @@ socket.  Quelli descritti anche nella pagina di manuale, accessibile con
     traffico che generi intenzionalmente messaggi di errore, per saturare il
     sistema dei log.}
 
-  Il \itindex{bucket~filter} \textit{bucket filter} è un algoritmo generico
-  che permette di impostare dei limiti di flusso su una quantità\footnote{uno
+  Il \itindex{bucket~filter} \textit{bucket filter} è un algoritmo generico
+  che permette di impostare dei limiti di flusso su una quantità\footnote{uno
     analogo viene usato nel \itindex{netfilter} \textit{netfilter} per imporre
     dei limiti sul flusso dei pacchetti.}  senza dovere eseguire medie
   temporali, che verrebbero a dipendere in misura non controllabile dalla
@@ -4067,13 +4067,13 @@ socket.  Quelli descritti anche nella pagina di manuale, accessibile con
     \textit{burst}) il flusso medio verrebbe a dipendere in maniera esclusiva
     dalla dimensione dell'intervallo di tempo su cui calcola la media.} in
   questo caso si definisce la dimensione di un ``\textsl{bidone}'' (il
-  \textit{bucket}) e del flusso che da esso può uscire, la presenza di una
+  \textit{bucket}) e del flusso che da esso può uscire, la presenza di una
   dimensione iniziale consente di assorbire eventuali picchi di emissione,
-  l'aver fissato un flusso di uscita garantisce che a regime questo sarà il
+  l'aver fissato un flusso di uscita garantisce che a regime questo sarà il
   valore medio del flusso ottenibile dal \textit{bucket}.
 
-  I due valori indicano rispettivamente il flusso a regime (non sarà inviato
-  più di un messaggio per il numero di secondi specificato da
+  I due valori indicano rispettivamente il flusso a regime (non sarà inviato
+  più di un messaggio per il numero di secondi specificato da
   \texttt{message\_cost}) e la dimensione iniziale per in caso di picco di
   emissione (verranno accettati inizialmente fino ad un massimo di
   \texttt{message\_cost/message\_burst} messaggi).
@@ -4088,7 +4088,7 @@ socket.  Quelli descritti anche nella pagina di manuale, accessibile con
 Oltre a questi nella directory \texttt{/proc/sys/net/core} si trovano altri
 file, la cui documentazione dovrebbe essere mantenuta nei sorgenti del kernel,
 nel file \texttt{Documentation/networking/ip-sysctl.txt}; la maggior parte di
-questi però non è documentato:
+questi però non è documentato:
 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
 \item[\procrelfile{/proc/sys/net/core}{dev\_weight}] blocco di lavoro
   (\textit{work quantum}) dello scheduler di processo dei pacchetti.
@@ -4110,14 +4110,14 @@ questi per
 \item[\procrelfile{/proc/sys/net/core}{no\_cong\_thresh}] valore minimo
   (\textit{low water mark}) per il riavvio dei dispositivi congestionati.
 
-  % \item[\procrelfile{/proc/sys/net/core}{netdev\_fastroute}] è presente
-  %   soltanto quando si è compilato il kernel con l'apposita opzione di
+  % \item[\procrelfile{/proc/sys/net/core}{netdev\_fastroute}] è presente
+  %   soltanto quando si è compilato il kernel con l'apposita opzione di
   %   ottimizzazione per l'uso come router.
 
 \item[\procrelfile{/proc/sys/net/core}{somaxconn}] imposta la dimensione
   massima utilizzabile per il \textit{backlog} della funzione \func{listen}
   (vedi sez.~\ref{sec:TCP_func_listen}), e corrisponde al valore della
-  costante \const{SOMAXCONN}; il suo valore di default è 128.
+  costante \const{SOMAXCONN}; il suo valore di default è 128.
 
 \end{basedescript}
 
@@ -4138,45 +4138,45 @@ di manuale accessibile con \texttt{man 7 ip}, sono i seguenti:
 
 \item[\procrelfile{/proc/sys/net/ipv4}{ip\_default\_ttl}] imposta il valore di
   default per il campo TTL (vedi sez.~\ref{sec:IP_header}) di tutti i
-  pacchetti uscenti, stabilendo così il numero massimo di router che i
-  pacchetti possono attraversare. Il valore può essere modificato anche per il
+  pacchetti uscenti, stabilendo così il numero massimo di router che i
+  pacchetti possono attraversare. Il valore può essere modificato anche per il
   singolo socket con l'opzione \const{IP\_TTL}.  Prende un valore intero, ma
-  dato che il campo citato è di 8 bit hanno senso solo valori fra 0 e 255. Il
-  valore di default è 64, e normalmente non c'è nessuna necessità di
+  dato che il campo citato è di 8 bit hanno senso solo valori fra 0 e 255. Il
+  valore di default è 64, e normalmente non c'è nessuna necessità di
   modificarlo.\footnote{l'unico motivo sarebbe per raggiungere macchine
-    estremamente ``{lontane}'' in termini di \textit{hop}, ma è praticamente
-    impossibile trovarne.} Aumentare il valore è una pratica poco gentile, in
+    estremamente ``{lontane}'' in termini di \textit{hop}, ma è praticamente
+    impossibile trovarne.} Aumentare il valore è una pratica poco gentile, in
   quanto in caso di problemi di routing si allunga inutilmente il numero di
   ritrasmissioni.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{ip\_forward}] abilita l'inoltro dei
-  pacchetti da una interfaccia ad un altra, e può essere impostato anche per
+  pacchetti da una interfaccia ad un altra, e può essere impostato anche per
   la singola interfaccia. Prende un valore logico (0 disabilita, diverso da
-  zero abilita), di default è disabilitato.
+  zero abilita), di default è disabilitato.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{ip\_dynaddr}] abilita la riscrittura
   automatica degli indirizzi associati ad un socket quando una interfaccia
   cambia indirizzo. Viene usato per le interfacce usate nei collegamenti in
   dial-up, il cui indirizzo IP viene assegnato dinamicamente dal provider, e
-  può essere modificato. Prende un valore intero, con 0 si disabilita la
-  funzionalità, con 1 la si abilita, con 2 (o con qualunque altro valore
-  diverso dai precedenti) la si abilità in modalità \textsl{prolissa}; di
-  default la funzionalità è disabilitata.
+  può essere modificato. Prende un valore intero, con 0 si disabilita la
+  funzionalità, con 1 la si abilita, con 2 (o con qualunque altro valore
+  diverso dai precedenti) la si abilità in modalità \textsl{prolissa}; di
+  default la funzionalità è disabilitata.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{ip\_autoconfig}] specifica se
-  l'indirizzo IP è stato configurato automaticamente dal kernel all'avvio
+  l'indirizzo IP è stato configurato automaticamente dal kernel all'avvio
   attraverso DHCP, BOOTP o RARP. Riporta un valore logico (0 falso, 1 vero)
-  accessibile solo in lettura, è inutilizzato nei kernel recenti ed eliminato
+  accessibile solo in lettura, è inutilizzato nei kernel recenti ed eliminato
   a partire dal kernel 2.6.18.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{ip\_local\_port\_range}] imposta
   l'intervallo dei valori usati per l'assegnazione delle porte effimere,
-  permette cioè di modificare i valori illustrati in
+  permette cioè di modificare i valori illustrati in
   fig.~\ref{fig:TCP_port_alloc}; prende due valori interi separati da spazi,
   che indicano gli estremi dell'intervallo. Si abbia cura di non definire un
   intervallo che si sovrappone a quello delle porte usate per il
-  \itindex{masquerading} \textit{masquerading}, il kernel può gestire la
-  sovrapposizione, ma si avrà una perdita di prestazioni. Si imposti sempre un
+  \itindex{masquerading} \textit{masquerading}, il kernel può gestire la
+  sovrapposizione, ma si avrà una perdita di prestazioni. Si imposti sempre un
   valore iniziale maggiore di 1024 (o meglio ancora di 4096) per evitare
   conflitti con le porte usate dai servizi noti.
 
@@ -4184,16 +4184,16 @@ di manuale accessibile con \texttt{man 7 ip}, sono i seguenti:
   disabilitare per i socket \const{SOCK\_STREAM} la ricerca automatica della
   \itindex{Maximum~Transfer~Unit} \textit{Path MTU} (vedi
   sez.~\ref{sec:net_lim_dim} e sez.~\ref{sec:sock_ipv4_options}). Prende un
-  valore logico, e di default è disabilitato (cioè la ricerca viene eseguita).
+  valore logico, e di default è disabilitato (cioè la ricerca viene eseguita).
 
   In genere si abilita questo parametro quando per qualche motivo il
   procedimento del \itindex{Maximum~Transfer~Unit} \textit{Path MTU discovery}
-  fallisce; dato che questo può avvenire a causa di router\footnote{ad
-    esempio se si scartano tutti i pacchetti ICMP, il problema è affrontato
+  fallisce; dato che questo può avvenire a causa di router\footnote{ad
+    esempio se si scartano tutti i pacchetti ICMP, il problema è affrontato
     anche in sez.~1.4.4 di \cite{FwGL}.} o interfacce\footnote{ad esempio se i
     due capi di un collegamento \textit{point-to-point} non si accordano sulla
-    stessa MTU.}  mal configurate è opportuno correggere le configurazioni,
-  perché disabilitare globalmente il procedimento con questo parametro ha
+    stessa MTU.}  mal configurate è opportuno correggere le configurazioni,
+  perché disabilitare globalmente il procedimento con questo parametro ha
   pesanti ripercussioni in termini di prestazioni di rete.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{ip\_always\_defrag}] fa si che tutti i
@@ -4202,9 +4202,9 @@ di manuale accessibile con \texttt{man 7 ip}, sono i seguenti:
     precedenti questo comportamento poteva essere solo stabilito un volta per
     tutte in fase di compilazione del kernel con l'opzione
     \texttt{CONFIG\_IP\_ALWAYS\_DEFRAG}.} Prende un valore logico e di default
-  è disabilitato. Con i kernel dalla serie 2.4 in poi la deframmentazione
+  è disabilitato. Con i kernel dalla serie 2.4 in poi la deframmentazione
   viene attivata automaticamente quando si utilizza il sistema del
-  \itindex{netfilter} \textit{netfilter}, e questo parametro non è più
+  \itindex{netfilter} \textit{netfilter}, e questo parametro non è più
   presente.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{ipfrag\_high\_thresh}] indica il limite
@@ -4219,17 +4219,17 @@ di manuale accessibile con \texttt{man 7 ip}, sono i seguenti:
 
 \item[\procrelfile{/proc/sys/net/ipv4}{ip\_nonlocal\_bind}] se abilitato rende
   possibile ad una applicazione eseguire \func{bind} anche su un indirizzo che
-  non è presente su nessuna interfaccia locale. Prende un valore logico e di
-  default è disabilitato.
+  non è presente su nessuna interfaccia locale. Prende un valore logico e di
+  default è disabilitato.
 
-  Questo può risultare utile per applicazioni particolari (come gli
-  \textit{sniffer}) che hanno la necessità di ricevere pacchetti anche non
+  Questo può risultare utile per applicazioni particolari (come gli
+  \textit{sniffer}) che hanno la necessità di ricevere pacchetti anche non
   diretti agli indirizzi presenti sulla macchina, ad esempio per intercettare
   il traffico per uno specifico indirizzo che si vuole tenere sotto
-  controllo. Il suo uso però può creare problemi ad alcune applicazioni.
+  controllo. Il suo uso però può creare problemi ad alcune applicazioni.
 
 % \item[\texttt{neigh/*}] La directory contiene i valori 
-% TODO trattare neigh/* nella parte su arp, da capire dove sarà.
+% TODO trattare neigh/* nella parte su arp, da capire dove sarà.
 
 \end{basedescript}
 
@@ -4239,13 +4239,13 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_abort\_on\_overflow}] indica al
-  kernel di azzerare le connessioni quando il programma che le riceve è troppo
-  lento ed incapace di accettarle. Prende un valore logico ed è disabilitato
-  di default.  Questo consente di recuperare le connessioni se si è avuto un
+  kernel di azzerare le connessioni quando il programma che le riceve è troppo
+  lento ed incapace di accettarle. Prende un valore logico ed è disabilitato
+  di default.  Questo consente di recuperare le connessioni se si è avuto un
   eccesso dovuto ad un qualche picco di traffico, ma ovviamente va a discapito
-  dei client che interrogano il server. Pertanto è da abilitare soltanto
-  quando si è sicuri che non è possibile ottimizzare il server in modo che sia
-  in grado di accettare connessioni più rapidamente.
+  dei client che interrogano il server. Pertanto è da abilitare soltanto
+  quando si è sicuri che non è possibile ottimizzare il server in modo che sia
+  in grado di accettare connessioni più rapidamente.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_adv\_win\_scale}] indica al kernel
   quale frazione del buffer associato ad un socket\footnote{quello impostato
@@ -4257,7 +4257,7 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
   che determina la suddetta frazione secondo la formula
   $\texttt{buffer}/2^\texttt{tcp\_adv\_win\_scale}$ se positivo o con
   $\texttt{buffer}-\texttt{buffer}/2^\texttt{tcp\_adv\_win\_scale}$ se
-  negativo.  Il default è 2 che significa che al buffer dell'applicazione
+  negativo.  Il default è 2 che significa che al buffer dell'applicazione
   viene riservato un quarto del totale.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_app\_win}] indica la frazione
@@ -4265,7 +4265,7 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
   bufferizzazione. Prende un valore valore intero che consente di calcolare la
   dimensione in byte come il massimo fra la \itindex{Maximum~Segment~Size}
   MSS e $\texttt{window}/2^\texttt{tcp\_app\_win}$. Un valore nullo significa
-  che non viene riservato nessuno spazio; il valore di default è 31.
+  che non viene riservato nessuno spazio; il valore di default è 31.
 
 % vecchi, presumibilmente usati quando gli algoritmi di congestione non erano
 % modularizzabili 
@@ -4280,20 +4280,20 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
     nell'\href{http://www.ietf.org/rfc/rfc2018.txt}{RFC~2018}, usata per dare
     un \textit{acknowledgement} unico su blocchi di pacchetti non contigui,
     che consente di diminuire il numero di pacchetti scambiati.} Prende un
-  valore logico e di default è abilitato.
-% TODO documentare o descrivere che cos'è il Duplicate SACK o
+  valore logico e di default è abilitato.
+% TODO documentare o descrivere che cos'è il Duplicate SACK o
 % mettere riferimento nelle appendici
 
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_ecn}] abilita il meccanismo della
   \textit{Explicit Congestion Notification} (in breve ECN) nelle connessioni
-  TCP. Prende valore logico che di default è disabilitato. La \textit{Explicit
-    Congestion Notification} \itindex{Explicit~Congestion~Notification} è un
-  meccanismo che consente di notificare quando una rotta o una rete è
-  congestionata da un eccesso di traffico,\footnote{il meccanismo è descritto
+  TCP. Prende valore logico che di default è disabilitato. La \textit{Explicit
+    Congestion Notification} \itindex{Explicit~Congestion~Notification} è un
+  meccanismo che consente di notificare quando una rotta o una rete è
+  congestionata da un eccesso di traffico,\footnote{il meccanismo è descritto
     in dettaglio nell'\href{http://www.ietf.org/rfc/rfc3168.txt}{RFC~3168}
     mentre gli effetti sulle prestazioni del suo utilizzo sono documentate
-    nell'\href{http://www.ietf.org/rfc/rfc2884.txt}{RFC~2884}.} si può così
+    nell'\href{http://www.ietf.org/rfc/rfc2884.txt}{RFC~2884}.} si può così
   essere avvisati e cercare rotte alternative oppure diminuire l'emissione di
   pacchetti (in modo da non aumentare la congestione).
 
@@ -4302,61 +4302,61 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
   dovuti al fatto che alcuni vecchi router non supportano il meccanismo ed
   alla sua attivazione scartano i relativi pacchetti, bloccando completamente
   il traffico.
-% TODO documentare o descrivere che cos'è l'Explicit Congestion Notification o
+% TODO documentare o descrivere che cos'è l'Explicit Congestion Notification o
 % mettere riferimento nelle appendici
 
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_fack}] abilita il supporto per il
   \textit{TCP Forward Acknowledgement}, un algoritmo per il controllo della
-  congestione del traffico. Prende un valore logico e di default è abilitato.
+  congestione del traffico. Prende un valore logico e di default è abilitato.
 
-% TODO documentare o descrivere che cos'è il TCP Forward Acknowledgement o
+% TODO documentare o descrivere che cos'è il TCP Forward Acknowledgement o
 % mettere riferimento nelle appendici
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_fin\_timeout}] specifica il numero
   di secondi da passare in stato \texttt{FIN\_WAIT2} nell'attesa delle
   ricezione del pacchetto FIN conclusivo, passati quali il socket viene
   comunque chiuso forzatamente.  Prende un valore intero che indica i secondi
-  e di default è 60.\footnote{nei kernel della serie 2.2.x era il valore
+  e di default è 60.\footnote{nei kernel della serie 2.2.x era il valore
     utilizzato era invece di 120 secondi.} L'uso di questa opzione realizza
-  quella che in sostanza è una violazione delle specifiche del protocollo TCP,
-  ma è utile per fronteggiare alcuni attacchi di
+  quella che in sostanza è una violazione delle specifiche del protocollo TCP,
+  ma è utile per fronteggiare alcuni attacchi di
   \itindex{Denial~of~Service~(DoS)} \textit{Denial of Service}.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_frto}] abilita il supporto per
   l'algoritmo F-RTO, un algoritmo usato per la ritrasmissione dei timeout del
   protocollo TCP, che diventa molto utile per le reti wireless dove la perdita
-  di pacchetti è usualmente dovuta a delle interferenze radio, piuttosto che
-  alla congestione dei router. Prende un valore logico e di default è
+  di pacchetti è usualmente dovuta a delle interferenze radio, piuttosto che
+  alla congestione dei router. Prende un valore logico e di default è
   disabilitato.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_keepalive\_intvl}] indica il
   numero di secondi che deve trascorrere fra l'emissione di due successivi
-  pacchetti di test quando è abilitata la funzionalità del \textit{keepalive}
+  pacchetti di test quando è abilitata la funzionalità del \textit{keepalive}
   (vedi sez.~\ref{sec:sock_options_main}). Prende un valore intero che di
-  default è 75.
+  default è 75.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_keepalive\_probes}] indica il
   massimo numero pacchetti di \textit{keepalive} (vedi
   sez.~\ref{sec:sock_options_main}) che devono essere inviati senza ricevere
-  risposta prima che il kernel decida che la connessione è caduta e la
-  termini. Prende un valore intero che di default è 9.
+  risposta prima che il kernel decida che la connessione è caduta e la
+  termini. Prende un valore intero che di default è 9.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_keepalive\_time}] indica il numero
   di secondi che devono passare senza traffico sulla connessione prima che il
   kernel inizi ad inviare pacchetti di pacchetti di
-  \textit{keepalive}.\footnote{ha effetto solo per i socket per cui si è
+  \textit{keepalive}.\footnote{ha effetto solo per i socket per cui si è
     impostata l'opzione \const{SO\_KEEPALIVE} (vedi
     sez.~\ref{sec:sock_options_main}.}  Prende un valore intero che di default
-  è 7200, pari a due ore.
+  è 7200, pari a due ore.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_low\_latency}] indica allo stack
   TCP del kernel di ottimizzare il comportamento per ottenere tempi di latenza
-  più bassi a scapito di valori più alti per l'utilizzo della banda. Prende un
-  valore logico che di default è disabilitato in quanto un maggior utilizzo
-  della banda è preferito, ma esistono applicazioni particolari in cui la
-  riduzione della latenza è più importante (ad esempio per i cluster di
-  calcolo parallelo) nelle quali lo si può abilitare.
+  più bassi a scapito di valori più alti per l'utilizzo della banda. Prende un
+  valore logico che di default è disabilitato in quanto un maggior utilizzo
+  della banda è preferito, ma esistono applicazioni particolari in cui la
+  riduzione della latenza è più importante (ad esempio per i cluster di
+  calcolo parallelo) nelle quali lo si può abilitare.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_max\_orphans}] indica il numero
   massimo di socket TCP ``\textsl{orfani}'' (vale a dire non associati a
@@ -4365,9 +4365,9 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
     processo di chiusura.}  Quando il limite viene ecceduto la connessione
   orfana viene resettata e viene stampato un avvertimento. Questo limite viene
   usato per contrastare alcuni elementari attacchi di \textit{denial of
-    service}.  Diminuire il valore non è mai raccomandato, in certe condizioni
-  di rete può essere opportuno aumentarlo, ma si deve tenere conto del fatto
-  che ciascuna connessione orfana può consumare fino a 64K di memoria del
+    service}.  Diminuire il valore non è mai raccomandato, in certe condizioni
+  di rete può essere opportuno aumentarlo, ma si deve tenere conto del fatto
+  che ciascuna connessione orfana può consumare fino a 64K di memoria del
   kernel. Prende un valore intero, il valore di default viene impostato
   inizialmente al valore del parametro del kernel \texttt{NR\_FILE}, e viene
   aggiustato a seconda della memoria disponibile.
@@ -4375,14 +4375,14 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
 % TODO verificare la spiegazione di connessione orfana.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_max\_syn\_backlog}] indica la
-  lunghezza della coda delle connessioni incomplete, cioè delle connessioni
-  per le quali si è ricevuto un SYN di richiesta ma non l'ACK finale del
+  lunghezza della coda delle connessioni incomplete, cioè delle connessioni
+  per le quali si è ricevuto un SYN di richiesta ma non l'ACK finale del
   \itindex{three~way~handshake} \textit{three way handshake} (si riveda quanto
   illustrato in sez.~\ref{sec:TCP_func_listen}).
 
-  Quando questo valore è superato il kernel scarterà immediatamente ogni
+  Quando questo valore è superato il kernel scarterà immediatamente ogni
   ulteriore richiesta di connessione. Prende un valore intero; il default, che
-  è 256, viene automaticamente portato a 1024 qualora nel sistema ci sia
+  è 256, viene automaticamente portato a 1024 qualora nel sistema ci sia
   sufficiente memoria (se maggiore di 128Mb) e ridotto a 128 qualora la
   memoria sia poca (inferiore a 32Mb).\footnote{si raccomanda, qualora si
     voglia aumentare il valore oltre 1024, di seguire la procedura citata
@@ -4393,15 +4393,15 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_max\_tw\_buckets}] indica il
   numero massimo di socket in stato \texttt{TIME\_WAIT} consentito nel
-  sistema. Prende un valore intero di default è impostato al doppio del valore
+  sistema. Prende un valore intero di default è impostato al doppio del valore
   del parametro \texttt{NR\_FILE}, ma che viene aggiustato automaticamente a
   seconda della memoria presente. Se il valore viene superato il socket viene
-  chiuso con la stampa di un avviso; l'uso di questa funzionalità consente di
+  chiuso con la stampa di un avviso; l'uso di questa funzionalità consente di
   prevenire alcuni semplici attacchi di \textit{denial of service}.
   
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_mem}] viene usato dallo stack TCP
-  per gestire le modalità con cui esso utilizzerà la memoria. Prende una
+  per gestire le modalità con cui esso utilizzerà la memoria. Prende una
   tripletta di valori interi, che indicano un numero di pagine:
 
   \begin{itemize*}
@@ -4422,16 +4422,16 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_orphan\_retries}] indica il numero
   massimo di volte che si esegue un tentativo di controllo sull'altro capo di
-  una connessione che è stata già chiusa dalla nostra parte. Prende un valore
-  intero che di default è 8.
+  una connessione che è stata già chiusa dalla nostra parte. Prende un valore
+  intero che di default è 8.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_reordering}] indica il numero
-  massimo di volte che un pacchetto può essere riordinato nel flusso di dati,
-  prima che lo stack TCP assuma che è andato perso e si ponga nello stato di
+  massimo di volte che un pacchetto può essere riordinato nel flusso di dati,
+  prima che lo stack TCP assuma che è andato perso e si ponga nello stato di
   \textit{slow start} (si veda sez.~\ref{sec:tcp_protocol_xxx}) viene usata
   questa metrica di riconoscimento dei riordinamenti per evitare inutili
   ritrasmissioni provocate dal riordinamento. Prende un valore intero che di
-  default che è 3, e che non è opportuno modificare.
+  default che è 3, e che non è opportuno modificare.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_retrans\_collapse}] in caso di
   pacchetti persi durante una connessione, per ottimizzare l'uso della banda
@@ -4439,29 +4439,29 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
   massima dimensione possibile; in sostanza dati che in precedenza erano stati
   trasmessi su pacchetti diversi possono essere ritrasmessi riuniti su un solo
   pacchetto (o su un numero minore di pacchetti di dimensione
-  maggiore). Prende un valore logico e di default è abilitato.
+  maggiore). Prende un valore logico e di default è abilitato.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_retries1}] imposta il massimo
-  numero di volte che protocollo tenterà la ritrasmissione si un pacchetto su
+  numero di volte che protocollo tenterà la ritrasmissione si un pacchetto su
   una connessione stabilita prima di fare ricorso ad ulteriori sforzi che
   coinvolgano anche il livello di rete. Passato questo numero di
-  ritrasmissioni verrà fatto eseguire al livello di rete un tentativo di
+  ritrasmissioni verrà fatto eseguire al livello di rete un tentativo di
   aggiornamento della rotta verso la destinazione prima di eseguire ogni
-  successiva ritrasmissione. Prende un valore intero che di default è 3.
+  successiva ritrasmissione. Prende un valore intero che di default è 3.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_retries2}] imposta il numero di
-  tentativi di ritrasmissione di un pacchetto inviato su una connessione già
+  tentativi di ritrasmissione di un pacchetto inviato su una connessione già
   stabilita per il quale non si sia ricevuto una risposta di ACK (si veda
   anche quanto illustrato in sez.~\ref{sec:TCP_server_crash}). Prende un
-  valore intero che di default è 15, il che comporta un tempo variabile fra 13
+  valore intero che di default è 15, il che comporta un tempo variabile fra 13
   e 30 minuti; questo non corrisponde a quanto richiesto
-  nell'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} dove è indicato un
-  massimo di 100 secondi, che però è un valore considerato troppo basso.
+  nell'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} dove è indicato un
+  massimo di 100 secondi, che però è un valore considerato troppo basso.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_rfc1337}] indica al kernel di
   abilitare il comportamento richiesto
   nell'\href{http://www.ietf.org/rfc/rfc1337.txt}{RFC~1337}. Prende un valore
-  logico e di default è disabilitato, il che significa che alla ricezione di
+  logico e di default è disabilitato, il che significa che alla ricezione di
   un segmento RST in stato \texttt{TIME\_WAIT} il socket viene chiuso
   immediatamente senza attendere la conclusione del periodo di
   \texttt{TIME\_WAIT}.
@@ -4473,7 +4473,7 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
 
   \begin{itemize}
   \item il primo valore, chiamato \textit{min} nelle pagine di manuale, indica
-    la dimensione minima in byte del buffer di ricezione; il default è 4Kb, ma
+    la dimensione minima in byte del buffer di ricezione; il default è 4Kb, ma
     in sistemi con poca memoria viene automaticamente ridotto a
     \const{PAGE\_SIZE}.  Questo valore viene usato per assicurare che anche in
     situazioni di pressione sulla memoria (vedi quanto detto per
@@ -4486,18 +4486,18 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
     manuale, indica la dimensione di default, in byte, del buffer di ricezione
     di un socket TCP.  Questo valore sovrascrive il default iniziale impostato
     per tutti i socket con \procfile{/proc/sys/net/core/mem\_default} che vale
-    per qualunque protocollo. Il default è 87380 byte, ridotto a 43689 per
-    sistemi con poca memoria. Se si desiderano dimensioni più ampie per tutti
-    i socket si può aumentare questo valore, ma se si vuole che in
+    per qualunque protocollo. Il default è 87380 byte, ridotto a 43689 per
+    sistemi con poca memoria. Se si desiderano dimensioni più ampie per tutti
+    i socket si può aumentare questo valore, ma se si vuole che in
     corrispondenza aumentino anche le dimensioni usate per la finestra TCP si
     deve abilitare il \itindex{TCP~window~scaling} \textit{TCP window scaling}
-    (di default è abilitato, vedi più avanti
+    (di default è abilitato, vedi più avanti
     \procrelfile{/proc/sys/net/ipv4}{tcp\_window\_scaling}).
 
   \item il terzo valore, denominato \textit{max} nelle pagine di manuale,
     indica la dimensione massima in byte del buffer di ricezione di un socket
-    TCP; il default è 174760 byte, che viene ridotto automaticamente a 87380
-    per sistemi con poca memoria. Il valore non può comunque eccedere il
+    TCP; il default è 174760 byte, che viene ridotto automaticamente a 87380
+    per sistemi con poca memoria. Il valore non può comunque eccedere il
     limite generale per tutti i socket posto con
     \procfile{/proc/sys/net/core/rmem\_max}. Questo valore non viene ad
     incidere sulla dimensione del buffer di ricezione di un singolo socket
@@ -4507,7 +4507,7 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_sack}] indica al kernel di
   utilizzare il meccanismo del \textit{TCP selective acknowledgement} definito
   nell'\href{http://www.ietf.org/rfc/rfc2018.txt}{RFC~2018}. Prende un valore
-  logico e di default è abilitato.
+  logico e di default è abilitato.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_stdurg}] indica al kernel di
   utilizzare l'interpretazione che viene data
@@ -4515,58 +4515,58 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
   \textit{dati urgenti} (vedi sez.~\ref{sec:TCP_urgent_data}) in cui questo
   punta all'ultimo byte degli stessi; se disabilitato viene usata
   l'interpretazione usata da BSD per cui esso punta al primo byte successivo.
-  Prende un valore logico e di default è disabilitato, perché abilitarlo può
-  dar luogo a problemi di interoperabilità.
+  Prende un valore logico e di default è disabilitato, perché abilitarlo può
+  dar luogo a problemi di interoperabilità.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_synack\_retries}] indica il numero
-  massimo di volte che verrà ritrasmesso il segmento SYN/ACK nella creazione di
+  massimo di volte che verrà ritrasmesso il segmento SYN/ACK nella creazione di
   una connessione (vedi sez.~\ref{sec:TCP_conn_cre}). Prende un valore intero
-  ed il valore di default è 5; non si deve superare il valore massimo di 255.
+  ed il valore di default è 5; non si deve superare il valore massimo di 255.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_syncookies}] abilita i \textit{TCP
-    syncookies}.\footnote{per poter usare questa funzionalità è necessario
+    syncookies}.\footnote{per poter usare questa funzionalità è necessario
     avere abilitato l'opzione \texttt{CONFIG\_SYN\_COOKIES} nella compilazione
-    del kernel.} Prende un valore logico, e di default è disabilitato. Questa
-  funzionalità serve a fornire una protezione in caso di un attacco di tipo
+    del kernel.} Prende un valore logico, e di default è disabilitato. Questa
+  funzionalità serve a fornire una protezione in caso di un attacco di tipo
   \index{SYN~flood} \textit{SYN flood}, e deve essere utilizzato come ultima
   risorsa dato che costituisce una violazione del protocollo TCP e confligge
-  con altre funzionalità come le estensioni e può causare problemi per i
+  con altre funzionalità come le estensioni e può causare problemi per i
   client ed il reinoltro dei pacchetti.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_syn\_retries}] imposta il numero
   di tentativi di ritrasmissione dei pacchetti SYN di inizio connessione del
   \itindex{three~way~handshake} \textit{three way handshake} (si ricordi
   quanto illustrato in sez.~\ref{sec:TCP_func_connect}). Prende un valore
-  intero che di default è 5; non si deve superare il valore massimo di 255.
+  intero che di default è 5; non si deve superare il valore massimo di 255.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_timestamps}] abilita l'uso dei
   \textit{TCP timestamps}, come definiti
   nell'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}. Prende un valore
-  logico e di default è abilitato.
+  logico e di default è abilitato.
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_tw\_recycle}] abilita il
   riutilizzo rapido dei socket in stato \texttt{TIME\_WAIT}. Prende un valore
-  logico e di default è disabilitato. Non è opportuno abilitare questa opzione
-  che può causare problemi con il NAT.\footnote{il \textit{Network Address
-      Translation} è una tecnica, impiegata nei firewall e nei router, che
+  logico e di default è disabilitato. Non è opportuno abilitare questa opzione
+  che può causare problemi con il NAT.\footnote{il \textit{Network Address
+      Translation} è una tecnica, impiegata nei firewall e nei router, che
     consente di modificare al volo gli indirizzi dei pacchetti che transitano
     per una macchina, Linux la supporta con il \itindex{netfilter}
     \textit{netfilter}, per maggiori dettagli si consulti il cap.~2 di
     \cite{FwGL}.}
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_tw\_reuse}] abilita il riutilizzo
-  dello stato \texttt{TIME\_WAIT} quando questo è sicuro dal punto di vista
-  del protocollo. Prende un valore logico e di default è disabilitato. 
+  dello stato \texttt{TIME\_WAIT} quando questo è sicuro dal punto di vista
+  del protocollo. Prende un valore logico e di default è disabilitato. 
 
 \item[\procrelfile{/proc/sys/net/ipv4}{tcp\_window\_scaling}] un valore
-  logico, attivo di default, che abilita la funzionalità del
+  logico, attivo di default, che abilita la funzionalità del
   \itindex{TCP~window~scaling} \textit{TCP window scaling} definita
   dall'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}. Prende un valore
-  logico e di default è abilitato. Come accennato in
+  logico e di default è abilitato. Come accennato in
   sez.~\ref{sec:TCP_TCP_opt} i 16 bit della finestra TCP comportano un limite
   massimo di dimensione di 64Kb, ma esiste una opportuna opzione del
   protocollo che permette di applicare un fattore di scale che consente di
-  aumentarne le dimensioni. Questa è pienamente supportata dallo stack TCP di
+  aumentarne le dimensioni. Questa è pienamente supportata dallo stack TCP di
   Linux, ma se lo si disabilita la negoziazione del
   \itindex{TCP~window~scaling} \textit{TCP window scaling} con l'altro capo
   della connessione non viene effettuata.
@@ -4584,7 +4584,7 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
 
   \begin{itemize}
   \item il primo valore, chiamato \textit{min}, indica la dimensione minima in
-    byte del buffer di spedizione; il default è 4Kb. Come per l'analogo di
+    byte del buffer di spedizione; il default è 4Kb. Come per l'analogo di
     \procrelfile{/proc/sys/net/ipv4}{tcp\_rmem}) viene usato per assicurare
     che anche in situazioni di pressione sulla memoria (vedi
     \procrelfile{/proc/sys/net/ipv4}{tcp\_mem}) le allocazioni al di sotto di
@@ -4595,9 +4595,9 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
   \item il secondo valore, denominato \textit{default}, indica la dimensione
     di default in byte del buffer di spedizione di un socket TCP.  Questo
     valore sovrascrive il default iniziale impostato per tutti i tipi di
-    socket con \procfile{/proc/sys/net/core/wmem\_default}. Il default è 87380
-    byte, ridotto a 43689 per sistemi con poca memoria. Si può aumentare
-    questo valore quando si desiderano dimensioni più ampie del buffer di
+    socket con \procfile{/proc/sys/net/core/wmem\_default}. Il default è 87380
+    byte, ridotto a 43689 per sistemi con poca memoria. Si può aumentare
+    questo valore quando si desiderano dimensioni più ampie del buffer di
     trasmissione per i socket TCP, ma come per il precedente
     \procrelfile{/proc/sys/net/ipv4}{tcp\_rmem}) se si vuole che in
     corrispondenza aumentino anche le dimensioni usate per la finestra TCP si
@@ -4605,9 +4605,9 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
     con \procrelfile{/proc/sys/net/ipv4}{tcp\_window\_scaling}.
 
   \item il terzo valore, denominato \textit{max}, indica la dimensione massima
-    in byte del buffer di spedizione di un socket TCP; il default è 128Kb, che
+    in byte del buffer di spedizione di un socket TCP; il default è 128Kb, che
     viene ridotto automaticamente a 64Kb per sistemi con poca memoria. Il
-    valore non può comunque eccedere il limite generale per tutti i socket
+    valore non può comunque eccedere il limite generale per tutti i socket
     posto con \procfile{/proc/sys/net/core/wmem\_max}. Questo valore non viene
     ad incidere sulla dimensione del buffer di trasmissione di un singolo
     socket dichiarata con l'opzione \const{SO\_SNDBUF}.
diff --git a/socket.tex b/socket.tex
index 6c1bb08..efca2ca 100644
--- a/socket.tex
+++ b/socket.tex
@@ -14,12 +14,12 @@
 
 In questo capitolo inizieremo a spiegare le caratteristiche salienti della
 principale interfaccia per la programmazione di rete, quella dei
-\textit{socket}, che, pur essendo nata in ambiente Unix, è usata ormai da
+\textit{socket}, che, pur essendo nata in ambiente Unix, è usata ormai da
 tutti i sistemi operativi.
 
 Dopo una breve panoramica sulle caratteristiche di questa interfaccia vedremo
 come creare un socket e come collegarlo allo specifico protocollo di rete che
-si utilizzerà per la comunicazione. Per evitare un'introduzione puramente
+si utilizzerà per la comunicazione. Per evitare un'introduzione puramente
 teorica concluderemo il capitolo con un primo esempio di applicazione.
 
 \section{Una panoramica}
@@ -48,32 +48,32 @@ possono realizzare la comunicazione anche attraverso la rete.
 
 Quella dei socket costituisce infatti la principale interfaccia usata nella
 programmazione di rete.  La loro origine risale al 1983, quando furono
-introdotti in BSD 4.2; l'interfaccia è rimasta sostanzialmente la stessa, con
-piccole modifiche, negli anni successivi. Benché siano state sviluppate
+introdotti in BSD 4.2; l'interfaccia è rimasta sostanzialmente la stessa, con
+piccole modifiche, negli anni successivi. Benché siano state sviluppate
 interfacce alternative, originate dai sistemi SVr4 come la XTI (\textit{X/Open
-  Transport Interface}) nessuna ha mai raggiunto la diffusione e la popolarità
-di quella dei socket (né tantomeno la stessa usabilità e flessibilità).
+  Transport Interface}) nessuna ha mai raggiunto la diffusione e la popolarità
+di quella dei socket (né tantomeno la stessa usabilità e flessibilità).
 
-La flessibilità e la genericità dell'interfaccia inoltre consente di
-utilizzare i socket con i più disparati meccanismi di comunicazione, e non
-solo con l'insieme dei protocolli TCP/IP, anche se questa sarà comunque quella
-di cui tratteremo in maniera più estesa.
+La flessibilità e la genericità dell'interfaccia inoltre consente di
+utilizzare i socket con i più disparati meccanismi di comunicazione, e non
+solo con l'insieme dei protocolli TCP/IP, anche se questa sarà comunque quella
+di cui tratteremo in maniera più estesa.
 
 
 \subsection{Concetti base}
 \label{sec:sock_gen}
 
 Per capire il funzionamento dei socket occorre avere presente il funzionamento
-dei protocolli di rete (vedi cap.~\ref{cha:network}), ma l'interfaccia è del
-tutto generale e benché le problematiche (e quindi le modalità di risolvere i
+dei protocolli di rete (vedi cap.~\ref{cha:network}), ma l'interfaccia è del
+tutto generale e benché le problematiche (e quindi le modalità di risolvere i
 problemi) siano diverse a seconda del tipo di protocollo di comunicazione
 usato, le funzioni da usare restano le stesse.
 
-Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
+Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
 inutile, in quanto il comportamento di quest'ultima e le problematiche da
 affrontare cambiano radicalmente a seconda dello \textsl{stile} di
 comunicazione usato.  La scelta di questo stile va infatti ad incidere sulla
-semantica che verrà utilizzata a livello utente per gestire la comunicazione
+semantica che verrà utilizzata a livello utente per gestire la comunicazione
 (su come inviare e ricevere i dati) e sul comportamento effettivo delle
 funzioni utilizzate.
 
@@ -84,30 +84,30 @@ che viene chiamato un \textsl{flusso} (in inglese \textit{stream}), mentre
 altri invece li raggruppano in \textsl{pacchetti} (in inglese
 \textit{datagram}) che vengono inviati in blocchi separati.
 
-Un altro esempio di stile concerne la possibilità che la comunicazione possa o
+Un altro esempio di stile concerne la possibilità che la comunicazione possa o
 meno perdere dati, possa o meno non rispettare l'ordine in cui essi non sono
-inviati, o inviare dei pacchetti più volte (come nel caso di TCP e UDP).
+inviati, o inviare dei pacchetti più volte (come nel caso di TCP e UDP).
 
-Un terzo esempio di stile di comunicazione concerne le modalità in cui essa
-avviene, in certi casi essa può essere condotta con una connessione diretta
+Un terzo esempio di stile di comunicazione concerne le modalità in cui essa
+avviene, in certi casi essa può essere condotta con una connessione diretta
 con un solo corrispondente, come per una telefonata; altri casi possono
 prevedere una comunicazione come per lettera, in cui si scrive l'indirizzo su
 ogni pacchetto, altri ancora una comunicazione \itindex{broadcast}
 \textit{broadcast} come per la radio, in cui i pacchetti vengono emessi su
 appositi ``\textsl{canali}'' dove chiunque si collega possa riceverli.
 
-É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire
-la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
-gestire la perdita o il rimescolamento dei dati, se è a pacchetti questi
+É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire
+la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
+gestire la perdita o il rimescolamento dei dati, se è a pacchetti questi
 dovranno essere opportunamente trattati, ecc.
 
 
 \section{La creazione di un socket}
 \label{sec:sock_creation}
 
-Come accennato l'interfaccia dei socket è estremamente flessibile e permette
+Come accennato l'interfaccia dei socket è estremamente flessibile e permette
 di interagire con protocolli di comunicazione anche molto diversi fra di loro;
-in questa sezione vedremo come è possibile creare un socket e come specificare
+in questa sezione vedremo come è possibile creare un socket e come specificare
 il tipo di comunicazione che esso deve utilizzare.
 
 \subsection{La funzione \func{socket}}
@@ -117,35 +117,35 @@ La creazione di un socket avviene attraverso l'uso della funzione
 \funcd{socket}; essa restituisce un \textit{file descriptor}\footnote{del
   tutto analogo a quelli che si ottengono per i file di dati e le pipe,
   descritti in sez.~\ref{sec:file_fd}.} che serve come riferimento al socket;
-il suo prototipo è:
+il suo prototipo è:
 \begin{prototype}{sys/socket.h}{int socket(int domain, int type, int protocol)}
 
   Apre un socket.
   
   \bodydesc{La funzione restituisce un intero positivo in caso di successo, e
-    -1 in caso di fallimento, nel qual caso la variabile \var{errno} assumerà
+    -1 in caso di fallimento, nel qual caso la variabile \var{errno} assumerà
   i valori:
   \begin{errlist}
   \item[\errcode{EPROTONOSUPPORT}] il tipo di socket o il protocollo scelto
     non sono supportati nel dominio.
   \item[\errcode{ENFILE}] il kernel non ha memoria sufficiente a creare una
     nuova struttura per il socket.
-  \item[\errcode{EMFILE}] si è ecceduta la tabella dei file.
+  \item[\errcode{EMFILE}] si è ecceduta la tabella dei file.
   \item[\errcode{EACCES}] non si hanno privilegi per creare un socket nel
     dominio o con il protocollo specificato.
   \item[\errcode{EINVAL}] protocollo sconosciuto o dominio non disponibile.
-  \item[\errcode{ENOBUFS}] non c'è sufficiente memoria per creare il socket
-    (può essere anche \errval{ENOMEM}).
+  \item[\errcode{ENOBUFS}] non c'è sufficiente memoria per creare il socket
+    (può essere anche \errval{ENOMEM}).
   \end{errlist}
   inoltre, a seconda del protocollo usato, potranno essere generati altri
   errori, che sono riportati nelle relative pagine di manuale.}
 \end{prototype}
 
 La funzione ha tre argomenti, \param{domain} specifica il dominio del socket
-(definisce cioè, come vedremo in sez.~\ref{sec:sock_domain}, la famiglia di
-protocolli usata), \param{type} specifica il tipo di socket (definisce cioè,
+(definisce cioè, come vedremo in sez.~\ref{sec:sock_domain}, la famiglia di
+protocolli usata), \param{type} specifica il tipo di socket (definisce cioè,
 come vedremo in sez.~\ref{sec:sock_type}, lo stile di comunicazione) e
-\param{protocol} il protocollo; in genere quest'ultimo è indicato
+\param{protocol} il protocollo; in genere quest'ultimo è indicato
 implicitamente dal tipo di socket, per cui di norma questo valore viene messo
 a zero (con l'eccezione dei \textit{raw socket}).
 
@@ -163,7 +163,7 @@ tipi di socket, che vengono classificati raggruppandoli in quelli che si
 chiamano \textsl{domini}.  La scelta di un dominio equivale in sostanza alla
 scelta di una famiglia di protocolli, e viene effettuata attraverso
 l'argomento \param{domain} della funzione \func{socket}. Ciascun dominio ha un
-suo nome simbolico che convenzionalmente è indicato da una costante che inizia
+suo nome simbolico che convenzionalmente è indicato da una costante che inizia
 per \texttt{PF\_}, sigla che sta per \textit{protocol family}, altro nome con
 cui si indicano i domini.
 
@@ -224,20 +224,20 @@ i capi della comunicazione.
 L'idea alla base della distinzione fra questi due insiemi di costanti era che
 una famiglia di protocolli potesse supportare vari tipi di indirizzi, per cui
 il prefisso \texttt{PF\_} si sarebbe dovuto usare nella creazione dei socket e
-il prefisso \texttt{AF\_} in quello delle strutture degli indirizzi; questo è
+il prefisso \texttt{AF\_} in quello delle strutture degli indirizzi; questo è
 quanto specificato anche dallo standard POSIX.1g, ma non esistono a tuttora
 famiglie di protocolli che supportino diverse strutture di indirizzi, per cui
 nella pratica questi due nomi sono equivalenti e corrispondono agli stessi
-valori numerici.\footnote{in Linux, come si può verificare andando a guardare
+valori numerici.\footnote{in Linux, come si può verificare andando a guardare
   il contenuto di \file{bits/socket.h}, le costanti sono esattamente le stesse
-  e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
+  e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
   lo stesso nome.}
 
-I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
+I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
 indirizzi, sono definiti dall'header \texttt{socket.h}. Un elenco delle
-famiglie di protocolli disponibili in Linux è riportato in
+famiglie di protocolli disponibili in Linux è riportato in
 tab.~\ref{tab:net_pf_names}.\footnote{l'elenco indica tutti i protocolli
-  definiti; fra questi però saranno utilizzabili solo quelli per i quali si è
+  definiti; fra questi però saranno utilizzabili solo quelli per i quali si è
   compilato il supporto nel kernel (o si sono caricati gli opportuni moduli),
   viene definita anche una costante \const{PF\_MAX} che indica il valore
   massimo associabile ad un dominio (nel caso il suo valore 32).}
@@ -245,22 +245,22 @@ tab.~\ref{tab:net_pf_names}.\footnote{l'elenco indica tutti i protocolli
 Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili
 dall'utente generico, ad esempio in generale tutti i socket di tipo
 \const{SOCK\_RAW} possono essere creati solo da processi che hanno i privilegi
-di amministratore (cioè con user-ID effettivo uguale a zero) o dotati della
+di amministratore (cioè con user-ID effettivo uguale a zero) o dotati della
 \itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}.
 
 
 \subsection{Il tipo di socket}
 \label{sec:sock_type}
 
-La scelta di un dominio non comporta però la scelta dello stile di
-comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
+La scelta di un dominio non comporta però la scelta dello stile di
+comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
 utilizzare fra quelli disponibili nella famiglia scelta. L'interfaccia dei
 socket permette di scegliere lo stile di comunicazione indicando il tipo di
 socket con l'argomento \param{type} di \func{socket}. Linux mette a
 disposizione vari tipi di socket (che corrispondono a quelli che il manuale
 della \acr{glibc} \cite{glibc} chiama \textit{styles}) identificati dalle
 seguenti costanti:\footnote{le pagine di manuale POSIX riportano solo i primi
-  tre tipi, Linux supporta anche gli altri, come si può verificare nel file
+  tre tipi, Linux supporta anche gli altri, come si può verificare nel file
   \texttt{include/linux/net.h} dei sorgenti del kernel.}
 
 \begin{basedescript}{\desclabelwidth{2.9cm}\desclabelstyle{\nextlinelabel}}
@@ -268,12 +268,12 @@ seguenti costanti:\footnote{le pagine di manuale POSIX riportano solo i primi
   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
   altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
   byte (da cui il nome \textit{stream}) e possono essere letti in blocchi di
-  dimensioni qualunque. Può supportare la trasmissione dei cosiddetti dati
+  dimensioni qualunque. Può supportare la trasmissione dei cosiddetti dati
   urgenti (o \itindex{out-of-band} \textit{out-of-band}, vedi
   sez.~\ref{sec:TCP_urgent_data}).
 \item[\const{SOCK\_DGRAM}] Viene usato per trasmettere pacchetti di dati
   (\textit{datagram}) di lunghezza massima prefissata, indirizzati
-  singolarmente. Non esiste una connessione e la trasmissione è effettuata in
+  singolarmente. Non esiste una connessione e la trasmissione è effettuata in
   maniera non affidabile.
 \item[\const{SOCK\_SEQPACKET}] Provvede un canale di trasmissione di dati
   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
@@ -282,15 +282,15 @@ seguenti costanti:\footnote{le pagine di manuale POSIX riportano solo i primi
   \func{read}.
 \item[\const{SOCK\_RAW}] Provvede l'accesso a basso livello ai protocolli di
   rete e alle varie interfacce. I normali programmi di comunicazione non
-  devono usarlo, è riservato all'uso di sistema.
+  devono usarlo, è riservato all'uso di sistema.
 \item[\const{SOCK\_RDM}] Provvede un canale di trasmissione di dati
-  affidabile, ma in cui non è garantito l'ordine di arrivo dei pacchetti.
-\item[\const{SOCK\_PACKET}] Obsoleto, non deve essere più usato.\footnote{e
+  affidabile, ma in cui non è garantito l'ordine di arrivo dei pacchetti.
+\item[\const{SOCK\_PACKET}] Obsoleto, non deve essere più usato.\footnote{e
     pertanto non ne parleremo ulteriormente.}
 \end{basedescript}
 
 Si tenga presente che non tutte le combinazioni fra una famiglia di protocolli
-e un tipo di socket sono valide, in quanto non è detto che in una famiglia
+e un tipo di socket sono valide, in quanto non è detto che in una famiglia
 esista un protocollo per ciascuno dei diversi stili di comunicazione appena
 elencati.
 
@@ -336,7 +336,7 @@ elencati.
 
 In tab.~\ref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni
 valide possibili per le principali famiglie di protocolli. Per ogni
-combinazione valida si è indicato il tipo di protocollo, o la parola
+combinazione valida si è indicato il tipo di protocollo, o la parola
 \textsl{si} qualora non il protocollo non abbia un nome definito, mentre si
 sono lasciate vuote le caselle per le combinazioni non supportate.
 
@@ -344,7 +344,7 @@ sono lasciate vuote le caselle per le combinazioni non supportate.
 \section{Le strutture degli indirizzi dei socket}
 \label{sec:sock_sockaddr}
 
-Come si è visto nella creazione di un socket non si specifica nulla oltre al
+Come si è visto nella creazione di un socket non si specifica nulla oltre al
 tipo di famiglia di protocolli che si vuole utilizzare, in particolare nessun
 indirizzo che identifichi i due capi della comunicazione. La funzione infatti
 si limita ad allocare nel kernel quanto necessario per poter poi realizzare la
@@ -363,14 +363,14 @@ identificati dal suffisso finale, aggiunto al nome precedente.
 \label{sec:sock_sa_gen}
 
 Le strutture degli indirizzi vengono sempre passate alle varie funzioni
-attraverso puntatori (cioè \textit{by reference}), ma le funzioni devono poter
+attraverso puntatori (cioè \textit{by reference}), ma le funzioni devono poter
 maneggiare puntatori a strutture relative a tutti gli indirizzi possibili
 nelle varie famiglie di protocolli; questo pone il problema di come passare
 questi puntatori, il C moderno risolve questo problema coi i puntatori
-generici (i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla
+generici (i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla
 definizione dello standard ANSI C, e per questo nel 1982 fu scelto di definire
 una struttura generica per gli indirizzi dei socket, \struct{sockaddr}, che si
-è riportata in fig.~\ref{fig:sock_sa_gen_struct}.
+è riportata in fig.~\ref{fig:sock_sa_gen_struct}.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -385,11 +385,11 @@ una struttura generica per gli indirizzi dei socket, \struct{sockaddr}, che si
 Tutte le funzioni dei socket che usano gli indirizzi sono definite usando nel
 prototipo un puntatore a questa struttura; per questo motivo quando si
 invocano dette funzioni passando l'indirizzo di un protocollo specifico
-occorrerà eseguire una conversione del relativo puntatore.
+occorrerà eseguire una conversione del relativo puntatore.
 
 I tipi di dati che compongono la struttura sono stabiliti dallo standard
 POSIX.1g e li abbiamo riassunti in tab.~\ref{tab:sock_data_types} con i
-rispettivi file di include in cui sono definiti; la struttura è invece
+rispettivi file di include in cui sono definiti; la struttura è invece
 definita nell'include file \file{sys/socket.h}.
 
 \begin{table}[!htb]
@@ -424,19 +424,19 @@ definita nell'include file \file{sys/socket.h}.
   \label{tab:sock_data_types}
 \end{table}
 
-In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
+In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
 aggiuntivo \code{uint8\_t sin\_len} (come riportato da R. Stevens in
 \cite{UNP1}). Questo campo non verrebbe usato direttamente dal programmatore e
-non è richiesto dallo standard POSIX.1g, in Linux pertanto non esiste. Il
+non è richiesto dallo standard POSIX.1g, in Linux pertanto non esiste. Il
 campo \type{sa\_family\_t} era storicamente un \ctyp{unsigned short}.
 
-Dal punto di vista del programmatore l'unico uso di questa struttura è quello
+Dal punto di vista del programmatore l'unico uso di questa struttura è quello
 di fare da riferimento per il casting, per il kernel le cose sono un po'
 diverse, in quanto esso usa il puntatore per recuperare il campo
 \var{sa\_family}, comune a tutte le famiglie, con cui determinare il tipo di
 indirizzo; per questo motivo, anche se l'uso di un puntatore \ctyp{void *}
-sarebbe più immediato per l'utente (che non dovrebbe più eseguire il casting),
-è stato mantenuto l'uso di questa struttura.
+sarebbe più immediato per l'utente (che non dovrebbe più eseguire il casting),
+è stato mantenuto l'uso di questa struttura.
 
 
 \subsection{La struttura degli indirizzi IPv4}
@@ -444,7 +444,7 @@ sarebbe pi
 
 I socket di tipo \const{PF\_INET} vengono usati per la comunicazione
 attraverso internet; la struttura per gli indirizzi per un socket internet (se
-si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file
+si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file
 \file{netinet/in.h} ed ha la forma mostrata in
 fig.~\ref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
 
@@ -459,15 +459,15 @@ fig.~\ref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
 \end{figure}
 
 L'indirizzo di un socket internet (secondo IPv4) comprende l'indirizzo
-internet di un'interfaccia più un \textsl{numero di porta} (affronteremo in
+internet di un'interfaccia più un \textsl{numero di porta} (affronteremo in
 dettaglio il significato di questi numeri in sez.~\ref{sec:TCP_port_num}).  Il
 protocollo IP non prevede numeri di porta, che sono utilizzati solo dai
-protocolli di livello superiore come TCP e UDP. Questa struttura però viene
+protocolli di livello superiore come TCP e UDP. Questa struttura però viene
 usata anche per i socket RAW che accedono direttamente al livello di IP, nel
 qual caso il numero della porta viene impostato al numero di protocollo.
 
 Il membro \var{sin\_family} deve essere sempre impostato a \const{AF\_INET},
-altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
+altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
 specifica il \textsl{numero di porta}. I numeri di porta sotto il 1024 sono
 chiamati \textsl{riservati} in quanto utilizzati da servizi standard e
 soltanto processi con i privilegi di amministratore (con user-ID effettivo
@@ -480,13 +480,13 @@ come struttura (un resto di una implementazione precedente in cui questa era
 una \direct{union} usata per accedere alle diverse classi di indirizzi) che
 direttamente come intero. In \file{netinet/in.h} vengono definite anche alcune
 costanti che identificano alcuni indirizzi speciali, riportati in
-tab.~\ref{tab:TCP_ipv4_addr}, che rincontreremo più avanti.
+tab.~\ref{tab:TCP_ipv4_addr}, che rincontreremo più avanti.
 
 Infine occorre sottolineare che sia gli indirizzi che i numeri di porta devono
-essere specificati in quello che viene chiamato \textit{network order}, cioè
+essere specificati in quello che viene chiamato \textit{network order}, cioè
 con i bit ordinati in formato \textit{big endian}, questo comporta la
-necessità di usare apposite funzioni di conversione per mantenere la
-portabilità del codice (vedi sez.~\ref{sec:sock_addr_func} per i dettagli del
+necessità di usare apposite funzioni di conversione per mantenere la
+portabilità del codice (vedi sez.~\ref{sec:sock_addr_func} per i dettagli del
 problema e le relative soluzioni).
 
 
@@ -495,8 +495,8 @@ problema e le relative soluzioni).
 
 Essendo IPv6 un'estensione di IPv4, i socket di tipo \const{PF\_INET6} sono
 sostanzialmente identici ai precedenti; la parte in cui si trovano
-praticamente tutte le differenze fra i due socket è quella della struttura
-degli indirizzi; la sua definizione, presa da \file{netinet/in.h}, è riportata
+praticamente tutte le differenze fra i due socket è quella della struttura
+degli indirizzi; la sua definizione, presa da \file{netinet/in.h}, è riportata
 in fig.~\ref{fig:sock_sa_ipv6_struct}.
 
 \begin{figure}[!htb]
@@ -510,20 +510,20 @@ in fig.~\ref{fig:sock_sa_ipv6_struct}.
 \end{figure}
 
 Il campo \var{sin6\_family} deve essere sempre impostato ad \const{AF\_INET6},
-il campo \var{sin6\_port} è analogo a quello di IPv4 e segue le stesse regole;
-il campo \var{sin6\_flowinfo} è a sua volta diviso in tre parti di cui i 24
-bit inferiori indicano l'etichetta di flusso, i successivi 4 bit la priorità e
+il campo \var{sin6\_port} è analogo a quello di IPv4 e segue le stesse regole;
+il campo \var{sin6\_flowinfo} è a sua volta diviso in tre parti di cui i 24
+bit inferiori indicano l'etichetta di flusso, i successivi 4 bit la priorità e
 gli ultimi 4 sono riservati. Questi valori fanno riferimento ad alcuni campi
 specifici dell'header dei pacchetti IPv6 (vedi sez.~\ref{sec:IP_ipv6head}) ed
-il loro uso è sperimentale.
+il loro uso è sperimentale.
 
 Il campo \var{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6,
-espresso da un vettore di 16 byte. Infine il campo \var{sin6\_scope\_id} è un
+espresso da un vettore di 16 byte. Infine il campo \var{sin6\_scope\_id} è un
 campo introdotto in Linux con il kernel 2.4, per gestire alcune operazioni
 riguardanti il \itindex{multicast} \textit{multicasting}.  Si noti infine che
 \struct{sockaddr\_in6} ha una dimensione maggiore della struttura
 \struct{sockaddr} generica di fig.~\ref{fig:sock_sa_gen_struct}, quindi
-occorre stare attenti a non avere fatto assunzioni riguardo alla possibilità
+occorre stare attenti a non avere fatto assunzioni riguardo alla possibilità
 di contenere i dati nelle dimensioni di quest'ultima.
 
 
@@ -535,9 +535,9 @@ comunicazione fra processi che stanno sulla stessa macchina (per questo
 vengono chiamati \textit{local domain} o anche \textit{Unix domain}); essi
 hanno la caratteristica ulteriore di poter essere creati anche in maniera
 anonima attraverso la funzione \func{socketpair} (che abbiamo trattato in
-sez.~\ref{sec:ipc_socketpair}).  Quando però si vuole fare riferimento
+sez.~\ref{sec:ipc_socketpair}).  Quando però si vuole fare riferimento
 esplicito ad uno di questi socket si deve usare una struttura degli indirizzi
-di tipo \struct{sockaddr\_un}, la cui definizione si è riportata in
+di tipo \struct{sockaddr\_un}, la cui definizione si è riportata in
 fig.~\ref{fig:sock_sa_local_struct}.
 
 \begin{figure}[!htb]
@@ -552,7 +552,7 @@ fig.~\ref{fig:sock_sa_local_struct}.
 
 In questo caso il campo \var{sun\_family} deve essere \const{AF\_UNIX}, mentre
 il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due forme;
-può essere un file (di tipo socket) nel filesystem o una stringa univoca
+può essere un file (di tipo socket) nel filesystem o una stringa univoca
 (mantenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene
 specificato come una stringa (terminata da uno zero) corrispondente al
 \itindex{pathname} \textit{pathname} del file; nel secondo invece
@@ -567,19 +567,19 @@ I socket di tipo \const{PF\_APPLETALK} sono usati dalla libreria
 \file{netatalk} per implementare la comunicazione secondo il protocollo
 AppleTalk, uno dei primi protocolli di rete usato nel mondo dei personal
 computer, usato dalla Apple per connettere fra loro computer e stampanti. Il
-kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è
+kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è
 opportuno usare le funzioni della libreria \texttt{netatalk}, tratteremo qui
 questo argomento principalmente per mostrare l'uso di un protocollo
 alternativo.
 
-I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo
+I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo
 a pacchetto, di tipo \const{SOCK\_DGRAM}; l'argomento \param{protocol} di
-\func{socket} deve essere nullo. È altresì possibile usare i socket raw
+\func{socket} deve essere nullo. È altresì possibile usare i socket raw
 specificando un tipo \const{SOCK\_RAW}, nel qual caso l'unico valore valido
-per \param{protocol} è \const{ATPROTO\_DDP}.
+per \param{protocol} è \const{ATPROTO\_DDP}.
 
 Gli indirizzi AppleTalk devono essere specificati tramite una struttura
-\struct{sockaddr\_atalk}, la cui definizione è riportata in
+\struct{sockaddr\_atalk}, la cui definizione è riportata in
 fig.~\ref{fig:sock_sa_atalk_struct}; la struttura viene dichiarata includendo
 il file \file{netatalk/at.h}.
 
@@ -598,12 +598,12 @@ campo \var{sat\_port} specifica la porta che identifica i vari servizi. Valori
 inferiori a 129 sono usati per le \textsl{porte riservate}, e possono essere
 usati solo da processi con i privilegi di amministratore o con la
 \itindex{capabilities} \textit{capability} \const{CAP\_NET\_BIND\_SERVICE}.
-L'indirizzo remoto è specificato nella struttura \var{sat\_addr}, e deve
-essere in \textit{network order} (vedi sez.~\ref{sec:sock_endianess}); esso è
-composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
+L'indirizzo remoto è specificato nella struttura \var{sat\_addr}, e deve
+essere in \textit{network order} (vedi sez.~\ref{sec:sock_endianess}); esso è
+composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
 valore \const{AT\_ANYNET}, che indica una rete generica e vale anche per
-indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e
-può prendere il valore generico \const{AT\_ANYNODE} che indica anche il nodo
+indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e
+può prendere il valore generico \const{AT\_ANYNODE} che indica anche il nodo
 corrente, ed il valore \const{ATADDR\_BCAST} che indica tutti i nodi della
 rete.
 
@@ -614,17 +614,17 @@ rete.
 I \textit{packet socket}, identificati dal dominio \const{PF\_PACKET}, sono
 un'interfaccia specifica di Linux per inviare e ricevere pacchetti
 direttamente su un'interfaccia di rete, senza passare per le funzioni di
-gestione dei protocolli di livello superiore. In questo modo è possibile
+gestione dei protocolli di livello superiore. In questo modo è possibile
 implementare dei protocolli in user space, agendo direttamente sul livello
 fisico. In genere comunque si preferisce usare la libreria
-\file{pcap},\footnote{la libreria è mantenuta insieme al comando
+\file{pcap},\footnote{la libreria è mantenuta insieme al comando
   \cmd{tcpdump}, informazioni e documentazione si possono trovare sul sito del
   progetto \href{http://www.tcpdump.org/}{\textsf{http://www.tcpdump.org/}}.}
-che assicura la portabilità su altre piattaforme, anche se con funzionalità
+che assicura la portabilità su altre piattaforme, anche se con funzionalità
 ridotte.
 
 Questi socket possono essere di tipo \const{SOCK\_RAW} o \const{SOCK\_DGRAM}.
-Con socket di tipo \const{SOCK\_RAW} si può operare sul livello di
+Con socket di tipo \const{SOCK\_RAW} si può operare sul livello di
 collegamento, ed i pacchetti vengono passati direttamente dal socket al driver
 del dispositivo e viceversa.  In questo modo, in fase di trasmissione, il
 contenuto completo dei pacchetti, comprese le varie intestazioni, deve essere
@@ -649,7 +649,7 @@ quelli disponibili in Linux sono accessibili attraverso opportune costanti
 simboliche definite nel file \file{linux/if\_ether.h}. Se si usa il valore
 speciale \const{ETH\_P\_ALL} passeranno sul \textit{packet socket} tutti i
 pacchetti, qualunque sia il loro protocollo di collegamento. Ovviamente l'uso
-di questi socket è una operazione privilegiata e può essere effettuati solo da
+di questi socket è una operazione privilegiata e può essere effettuati solo da
 un processo con i privilegi di amministratore (user-ID effettivo nullo) o con
 la \itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}.
 
@@ -668,12 +668,12 @@ occorre usare la funzione \func{bind} per agganciare il socket a quest'ultima.
   \label{fig:sock_sa_packet_struct}
 \end{figure}
 
-Nel caso dei \textit{packet socket} la struttura degli indirizzi è di tipo
-\struct{sockaddr\_ll}, e la sua definizione è riportata in
-fig.~\ref{fig:sock_sa_packet_struct}; essa però viene ad assumere un ruolo
+Nel caso dei \textit{packet socket} la struttura degli indirizzi è di tipo
+\struct{sockaddr\_ll}, e la sua definizione è riportata in
+fig.~\ref{fig:sock_sa_packet_struct}; essa però viene ad assumere un ruolo
 leggermente diverso rispetto a quanto visto finora per gli altri tipi di
-socket.  Infatti se il socket è di tipo \const{SOCK\_RAW} si deve comunque
-scrivere tutto direttamente nel pacchetto, quindi la struttura non serve più a
+socket.  Infatti se il socket è di tipo \const{SOCK\_RAW} si deve comunque
+scrivere tutto direttamente nel pacchetto, quindi la struttura non serve più a
 specificare gli indirizzi. Essa mantiene questo ruolo solo per i socket di
 tipo \const{SOCK\_DGRAM}, per i quali permette di specificare i dati necessari
 al protocollo di collegamento, mentre viene sempre utilizzata in lettura (per
@@ -683,9 +683,9 @@ pacchetto.
 Al solito il campo \var{sll\_family} deve essere sempre impostato al valore
 \const{AF\_PACKET}. Il campo \var{sll\_protocol} indica il protocollo scelto,
 e deve essere indicato in \textit{network order}, facendo uso delle costanti
-simboliche definite in \file{linux/if\_ether.h}. Il campo \var{sll\_ifindex} è
-l'indice dell'interfaccia, che, in caso di presenza di più interfacce dello
-stesso tipo (se ad esempio si hanno più schede ethernet), permette di
+simboliche definite in \file{linux/if\_ether.h}. Il campo \var{sll\_ifindex} è
+l'indice dell'interfaccia, che, in caso di presenza di più interfacce dello
+stesso tipo (se ad esempio si hanno più schede ethernet), permette di
 selezionare quella con cui si vuole operare (un valore nullo indica qualunque
 interfaccia).  Questi sono i due soli campi che devono essere specificati
 quando si vuole selezionare una interfaccia specifica, usando questa struttura
@@ -702,7 +702,7 @@ pacchetti, in questo caso tutti gli altri campi devono essere nulli.
 Il campo \var{sll\_hatype} indica il tipo ARP, come definito in
 \file{linux/if\_arp.h}, mentre il campo \var{sll\_pkttype} indica il tipo di
 pacchetto; entrambi vengono impostati alla ricezione di un pacchetto ed han
-senso solo in questo caso. In particolare \var{sll\_pkttype} può assumere i
+senso solo in questo caso. In particolare \var{sll\_pkttype} può assumere i
 seguenti valori: \const{PACKET\_HOST} per un pacchetto indirizzato alla
 macchina ricevente, \const{PACKET\_BROADCAST} per un pacchetto di
 \itindex{broadcast} \textit{broadcast}, \const{PACKET\_MULTICAST} per un
@@ -716,14 +716,14 @@ macchina che torna indietro sul socket.
 Si tenga presente infine che in fase di ricezione, anche se si richiede il
 troncamento del pacchetto, le funzioni \func{recv}, \func{recvfrom} e
 \func{recvmsg} (vedi sez.~\ref{sec:net_sendmsg}) restituiranno comunque la
-lunghezza effettiva del pacchetto così come arrivato sulla linea.
+lunghezza effettiva del pacchetto così come arrivato sulla linea.
 
 %% \subsection{La struttura degli indirizzi DECnet}
 %% \label{sec:sock_sa_decnet}
  
 %% I socket di tipo \const{PF\_DECnet} usano il protocollo DECnet, usato dai VAX
 %% Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di
-%% fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è limitato
+%% fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è limitato
 %% alla comunicazione con macchine che stanno comunque scomparendo. Lo si riporta
 %% solo come esempio 
 
@@ -737,10 +737,10 @@ lunghezza effettiva del pacchetto cos
 \label{sec:sock_addr_func}
 
 In questa sezione tratteremo delle varie funzioni usate per manipolare gli
-indirizzi, limitandoci però agli indirizzi internet.  Come accennato gli
+indirizzi, limitandoci però agli indirizzi internet.  Come accennato gli
 indirizzi e i numeri di porta usati nella rete devono essere forniti in
 formato opportuno (il \textit{network order}). Per capire cosa significa tutto
-ciò occorre introdurre un concetto generale che tornerà utile anche in
+ciò occorre introdurre un concetto generale che tornerà utile anche in
 seguito.
 
 
@@ -748,11 +748,11 @@ seguito.
 \label{sec:sock_endianess}
 
 \itindbeg{endianess}
-La rappresentazione di un numero binario in un computer può essere fatta in
+La rappresentazione di un numero binario in un computer può essere fatta in
 due modi, chiamati rispettivamente \textit{big endian} e \textit{little
   endian} a seconda di come i singoli bit vengono aggregati per formare le
 variabili intere (ed in genere in diretta corrispondenza a come sono poi in
-realtà cablati sui bus interni del computer).
+realtà cablati sui bus interni del computer).
 
 \begin{figure}[htb]
   \centering
@@ -765,18 +765,18 @@ realt
 Per capire meglio il problema si consideri un intero a 32 bit scritto in una
 locazione di memoria posta ad un certo indirizzo. Come illustrato in
 fig.~\ref{fig:sock_endianess} i singoli bit possono essere disposti in memoria
-in due modi: a partire dal più significativo o a partire dal meno
-significativo.  Così nel primo caso si troverà il byte che contiene i bit più
+in due modi: a partire dal più significativo o a partire dal meno
+significativo.  Così nel primo caso si troverà il byte che contiene i bit più
 significativi all'indirizzo menzionato e il byte con i bit meno significativi
-nell'indirizzo successivo; questo ordinamento è detto \textit{big endian},
-dato che si trova per prima la parte più grande. Il caso opposto, in cui si
-parte dal bit meno significativo è detto per lo stesso motivo \textit{little
+nell'indirizzo successivo; questo ordinamento è detto \textit{big endian},
+dato che si trova per prima la parte più grande. Il caso opposto, in cui si
+parte dal bit meno significativo è detto per lo stesso motivo \textit{little
   endian}.
 
-Si può allora verificare quale tipo di \textit{endianess} usa il proprio
+Si può allora verificare quale tipo di \textit{endianess} usa il proprio
 computer con un programma elementare che si limita ad assegnare un valore ad
 una variabile per poi ristamparne il contenuto leggendolo un byte alla volta.
-Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
+Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
 allora se lo eseguiamo su un PC otterremo:
 \begin{verbatim}
 [piccardi@gont sources]$ ./endtest
@@ -800,15 +800,15 @@ val[3]= 1
 La \textit{endianess} di un computer dipende essenzialmente dalla architettura
 hardware usata; Intel e Digital usano il \textit{little endian}, Motorola,
 IBM, Sun (sostanzialmente tutti gli altri) usano il \textit{big endian}. Il
-formato dei dati contenuti nelle intestazioni dei protocolli di rete è
+formato dei dati contenuti nelle intestazioni dei protocolli di rete è
 anch'esso \textit{big endian}; altri esempi di uso di questi due diversi
-formati sono quello del bus PCI, che è \textit{little endian}, o quello del
-bus VME che è \textit{big endian}.
+formati sono quello del bus PCI, che è \textit{little endian}, o quello del
+bus VME che è \textit{big endian}.
 
 Esistono poi anche dei processori che possono scegliere il tipo di formato
 all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
 da un tipo di ordinamento all'altro con una specifica istruzione. In ogni caso
-in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
+in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
 resta sempre lo stesso, anche quando il processore permetterebbe di eseguire
 questi cambiamenti.
 
@@ -823,19 +823,19 @@ questi cambiamenti.
   \label{fig:sock_endian_code}
 \end{figure}
 
-Per controllare quale tipo di ordinamento si ha sul proprio computer si è
-scritta una piccola funzione di controllo, il cui codice è riportato
+Per controllare quale tipo di ordinamento si ha sul proprio computer si è
+scritta una piccola funzione di controllo, il cui codice è riportato
 fig.~\ref{fig:sock_endian_code}, che restituisce un valore nullo (falso) se
-l'architettura è \textit{big endian} ed uno non nullo (vero) se l'architettura
-è \textit{little endian}.
+l'architettura è \textit{big endian} ed uno non nullo (vero) se l'architettura
+è \textit{little endian}.
 
-Come si vede la funzione è molto semplice, e si limita, una volta assegnato
+Come si vede la funzione è molto semplice, e si limita, una volta assegnato
 (\texttt{\small 9}) un valore di test pari a \texttt{0xABCD} ad una variabile
-di tipo \ctyp{short} (cioè a 16 bit), a ricostruirne una copia byte a byte.
+di tipo \ctyp{short} (cioè a 16 bit), a ricostruirne una copia byte a byte.
 Per questo prima (\texttt{\small 10}) si definisce il puntatore \var{ptr} per
 accedere al contenuto della prima variabile, ed infine calcola (\texttt{\small
   11}) il valore della seconda assumendo che il primo byte sia quello meno
-significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianess}, che sia
+significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianess}, che sia
 \textit{little endian}). Infine la funzione restituisce (\texttt{\small 12})
 il valore del confronto delle due variabili. 
 \itindend{endianess}
@@ -845,10 +845,10 @@ il valore del confronto delle due variabili.
 \subsection{Le funzioni per il riordinamento}
 \label{sec:sock_func_ord}
 
-Il problema connesso \itindex{endianess} all'endianess è che quando si passano
+Il problema connesso \itindex{endianess} all'endianess è che quando si passano
 dei dati da un tipo di architettura all'altra i dati vengono interpretati in
-maniera diversa, e ad esempio nel caso dell'intero a 16 bit ci si ritroverà
-con i due byte in cui è suddiviso scambiati di posto.  Per questo motivo si
+maniera diversa, e ad esempio nel caso dell'intero a 16 bit ci si ritroverà
+con i due byte in cui è suddiviso scambiati di posto.  Per questo motivo si
 usano delle funzioni di conversione che servono a tener conto automaticamente
 della possibile differenza fra l'ordinamento usato sul computer e quello che
 viene usato nelle trasmissione sulla rete; queste funzioni sono \funcd{htonl},
@@ -886,7 +886,7 @@ Usando queste funzioni si ha la conversione automatica: nel caso in cui la
 macchina che si sta usando abbia una architettura \textit{big endian} queste
 funzioni sono definite come macro che non fanno nulla. Per questo motivo vanno
 sempre utilizzate, anche quando potrebbero non essere necessarie, in modo da
-assicurare la portabilità del codice su tutte le architetture.
+assicurare la portabilità del codice su tutte le architetture.
 
 
 \subsection{Le funzioni \func{inet\_aton}, \func{inet\_addr} e 
@@ -898,8 +898,8 @@ binario usato nelle strutture degli indirizzi alla rappresentazione simbolica
 dei numeri IP che si usa normalmente.
 
 Le prime tre funzioni di manipolazione riguardano la conversione degli
-indirizzi IPv4 da una stringa in cui il numero di IP è espresso secondo la
-cosiddetta notazione \textit{dotted-decimal}, (cioè nella forma
+indirizzi IPv4 da una stringa in cui il numero di IP è espresso secondo la
+cosiddetta notazione \textit{dotted-decimal}, (cioè nella forma
 \texttt{192.168.0.1}) al formato binario (direttamente in \textit{network
   order}) e viceversa; in questo caso si usa la lettera \texttt{a} come
 mnemonico per indicare la stringa. Dette funzioni sono \funcd{inet\_addr},
@@ -923,15 +923,15 @@ La prima funzione, \func{inet\_addr}, restituisce l'indirizzo a 32 bit in
 network order (del tipo \type{in\_addr\_t}) a partire dalla stringa passata
 nell'argomento \param{strptr}. In caso di errore (quando la stringa non esprime
 un indirizzo valido) restituisce invece il valore \const{INADDR\_NONE} che
-tipicamente sono trentadue bit a uno.  Questo però comporta che la stringa
-\texttt{255.255.255.255}, che pure è un indirizzo valido, non può essere usata
-con questa funzione; per questo motivo essa è generalmente deprecata in favore
+tipicamente sono trentadue bit a uno.  Questo però comporta che la stringa
+\texttt{255.255.255.255}, che pure è un indirizzo valido, non può essere usata
+con questa funzione; per questo motivo essa è generalmente deprecata in favore
 di \func{inet\_aton}.
 
 La funzione \func{inet\_aton} converte la stringa puntata da \param{src}
 nell'indirizzo binario che viene memorizzato nell'opportuna struttura
 \struct{in\_addr} (si veda fig.~\ref{fig:sock_sa_ipv4_struct}) situata
-all'indirizzo dato dall'argomento \param{dest} (è espressa in questa forma in
+all'indirizzo dato dall'argomento \param{dest} (è espressa in questa forma in
 modo da poterla usare direttamente con il puntatore usato per passare la
 struttura degli indirizzi). La funzione restituisce 0 in caso di successo e 1
 in caso di fallimento.  Se usata con \param{dest} inizializzato a \val{NULL}
@@ -941,23 +941,23 @@ L'ultima funzione, \func{inet\_ntoa}, converte il valore a 32 bit
 dell'indirizzo (espresso in \textit{network order}) restituendo il puntatore
 alla stringa che contiene l'espressione in formato dotted decimal. Si deve
 tenere presente che la stringa risiede in memoria statica, per cui questa
-funzione non è \index{funzioni!rientranti} rientrante.
+funzione non è \index{funzioni!rientranti} rientrante.
 
 
 \subsection{Le funzioni \func{inet\_pton} e \func{inet\_ntop}}
 \label{sec:sock_conv_func_gen}
 
 Le tre funzioni precedenti sono limitate solo ad indirizzi IPv4, per questo
-motivo è preferibile usare le due nuove funzioni \func{inet\_pton} e
+motivo è preferibile usare le due nuove funzioni \func{inet\_pton} e
 \func{inet\_ntop} che possono convertire anche gli indirizzi IPv6. Anche in
 questo caso le lettere \texttt{n} e \texttt{p} sono degli mnemonici per
 ricordare il tipo di conversione effettuata e stanno per \textit{presentation}
 e \textit{numeric}.
 
 Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di
-indirizzo, e che può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La
+indirizzo, e che può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La
 prima funzione, \funcd{inet\_pton}, serve a convertire una stringa in un
-indirizzo; il suo prototipo è:
+indirizzo; il suo prototipo è:
 \begin{prototype}{sys/socket.h}
 {int inet\_pton(int af, const char *src, void *addr\_ptr)} 
 
@@ -976,8 +976,8 @@ restituisce un valore positivo in caso di successo, nullo se la stringa non
 rappresenta un indirizzo valido, e negativo se \param{af} specifica una
 famiglia di indirizzi non valida.
 
-La seconda funzione di conversione è \funcd{inet\_ntop} che converte un
-indirizzo in una stringa; il suo prototipo è:
+La seconda funzione di conversione è \funcd{inet\_ntop} che converte un
+indirizzo in una stringa; il suo prototipo è:
 \begin{prototype}{sys/socket.h}
   {char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)}
   Converte l'indirizzo dalla relativa struttura in una stringa simbolica.
@@ -988,7 +988,7 @@ indirizzo in una stringa; il suo prototipo 
     \begin{errlist}
     \item[\errcode{ENOSPC}] le dimensioni della stringa con la conversione
       dell'indirizzo eccedono la lunghezza specificata da \param{len}.
-    \item[\errcode{ENOAFSUPPORT}] la famiglia di indirizzi \param{af} non è
+    \item[\errcode{ENOAFSUPPORT}] la famiglia di indirizzi \param{af} non è
       una valida.
   \end{errlist}}
 \end{prototype}
@@ -1004,9 +1004,9 @@ Gli indirizzi vengono convertiti da/alle rispettive strutture di indirizzo
 (una struttura \struct{in\_addr} per IPv4, e una struttura \struct{in6\_addr}
 per IPv6), che devono essere precedentemente allocate e passate attraverso il
 puntatore \param{addr\_ptr}; l'argomento \param{dest} di \func{inet\_ntop} non
-può essere nullo e deve essere allocato precedentemente.
+può essere nullo e deve essere allocato precedentemente.
 
-Il formato usato per gli indirizzi in formato di presentazione è la notazione
+Il formato usato per gli indirizzi in formato di presentazione è la notazione
 \textit{dotted decimal} per IPv4 e quello descritto in
 sez.~\ref{sec:IP_ipv6_notation} per IPv6.
 
diff --git a/system.tex b/system.tex
index c2b177d..45e13e0 100644
--- a/system.tex
+++ b/system.tex
@@ -12,7 +12,7 @@
 \chapter{La gestione del sistema, del tempo e degli errori}
 \label{cha:system}
 
-In questo capitolo tratteremo varie interfacce che attengono agli aspetti più
+In questo capitolo tratteremo varie interfacce che attengono agli aspetti più
 generali del sistema, come quelle per la gestione dei parametri e della
 configurazione dello stesso, quelle per la lettura dei limiti e delle
 caratteristiche, quelle per il controllo dell'uso delle risorse dei processi,
@@ -21,19 +21,19 @@ e degli errori.
 
 
 
-\section{Capacità e caratteristiche del sistema}
+\section{Capacità e caratteristiche del sistema}
 \label{sec:sys_characteristics}
 
-In questa sezione tratteremo le varie modalità con cui un programma può
-ottenere informazioni riguardo alle capacità del sistema. Ogni sistema
-unix-like infatti è contraddistinto da un gran numero di limiti e costanti che
+In questa sezione tratteremo le varie modalità con cui un programma può
+ottenere informazioni riguardo alle capacità del sistema. Ogni sistema
+unix-like infatti è contraddistinto da un gran numero di limiti e costanti che
 lo caratterizzano, e che possono dipendere da fattori molteplici, come
 l'architettura hardware, l'implementazione del kernel e delle librerie, le
 opzioni di configurazione.
 
 La definizione di queste caratteristiche ed il tentativo di provvedere dei
-meccanismi generali che i programmi possono usare per ricavarle è uno degli
-aspetti più complessi e controversi con cui le diverse standardizzazioni si
+meccanismi generali che i programmi possono usare per ricavarle è uno degli
+aspetti più complessi e controversi con cui le diverse standardizzazioni si
 sono dovute confrontare, spesso con risultati spesso tutt'altro che chiari.
 Daremo comunque una descrizione dei principali metodi previsti dai vari
 standard per ricavare sia le caratteristiche specifiche del sistema, che
@@ -44,39 +44,39 @@ quelle della gestione dei file.
 \label{sec:sys_limits}
 
 Quando si devono determinare le caratteristiche generali del sistema ci si
-trova di fronte a diverse possibilità; alcune di queste infatti possono
+trova di fronte a diverse possibilità; alcune di queste infatti possono
 dipendere dall'architettura dell'hardware (come le dimensioni dei tipi
 interi), o dal sistema operativo (come la presenza o meno del gruppo degli
 identificatori \textit{saved}), altre invece possono dipendere dalle opzioni
-con cui si è costruito il sistema (ad esempio da come si è compilato il
+con cui si è costruito il sistema (ad esempio da come si è compilato il
 kernel), o dalla configurazione del medesimo; per questo motivo in generale
-sono necessari due tipi diversi di funzionalità:
+sono necessari due tipi diversi di funzionalità:
 \begin{itemize*}
-\item la possibilità di determinare limiti ed opzioni al momento della
+\item la possibilità di determinare limiti ed opzioni al momento della
   compilazione.
-\item la possibilità di determinare limiti ed opzioni durante l'esecuzione.
+\item la possibilità di determinare limiti ed opzioni durante l'esecuzione.
 \end{itemize*}
 
-La prima funzionalità si può ottenere includendo gli opportuni header file che
+La prima funzionalità si può ottenere includendo gli opportuni header file che
 contengono le costanti necessarie definite come macro di preprocessore, per la
-seconda invece sono ovviamente necessarie delle funzioni. La situazione è
+seconda invece sono ovviamente necessarie delle funzioni. La situazione è
 complicata dal fatto che ci sono molti casi in cui alcuni di questi limiti
 sono fissi in un'implementazione mentre possono variare in un altra. Tutto
-questo crea una ambiguità che non è sempre possibile risolvere in maniera
-chiara; in generale quello che succede è che quando i limiti del sistema sono
+questo crea una ambiguità che non è sempre possibile risolvere in maniera
+chiara; in generale quello che succede è che quando i limiti del sistema sono
 fissi essi vengono definiti come macro di preprocessore nel file
-\file{limits.h}, se invece possono variare, il loro valore sarà ottenibile
+\file{limits.h}, se invece possono variare, il loro valore sarà ottenibile
 tramite la funzione \func{sysconf} (che esamineremo in
 sez.~\ref{sec:sys_sysconf}).
 
 Lo standard ANSI C definisce dei limiti che sono tutti fissi, pertanto questo
 saranno sempre disponibili al momento della compilazione. Un elenco, ripreso
-da \file{limits.h}, è riportato in tab.~\ref{tab:sys_ansic_macro}. Come si può
+da \file{limits.h}, è riportato in tab.~\ref{tab:sys_ansic_macro}. Come si può
 vedere per la maggior parte questi limiti attengono alle dimensioni dei dati
 interi, che sono in genere fissati dall'architettura hardware (le analoghe
 informazioni per i dati in virgola mobile sono definite a parte, ed
 accessibili includendo \file{float.h}). Lo standard prevede anche un'altra
-costante, \const{FOPEN\_MAX}, che può non essere fissa e che pertanto non è
+costante, \const{FOPEN\_MAX}, che può non essere fissa e che pertanto non è
 definita in \file{limits.h}; essa deve essere definita in \file{stdio.h} ed
 avere un valore minimo di 8.
 
@@ -107,15 +107,15 @@ avere un valore minimo di 8.
     \const{ULONG\_MAX}& 4294967295  & Massimo di \ctyp{unsigned long}.\\
     \hline                
   \end{tabular}
-  \caption{Costanti definite in \file{limits.h} in conformità allo standard
+  \caption{Costanti definite in \file{limits.h} in conformità allo standard
     ANSI C.}
   \label{tab:sys_ansic_macro}
 \end{table}
 
-\footnotetext[1]{il valore può essere 0 o \const{SCHAR\_MIN} a seconda che il
+\footnotetext[1]{il valore può essere 0 o \const{SCHAR\_MIN} a seconda che il
   sistema usi caratteri con segno o meno.} 
 
-\footnotetext[2]{il valore può essere \const{UCHAR\_MAX} o \const{SCHAR\_MAX}
+\footnotetext[2]{il valore può essere \const{UCHAR\_MAX} o \const{SCHAR\_MAX}
   a seconda che il sistema usi caratteri con segno o meno.}
 
 A questi valori lo standard ISO C90 ne aggiunge altri tre, relativi al tipo
@@ -136,7 +136,7 @@ tab.~\ref{tab:sys_isoc90_macro}.
                                     Massimo di \ctyp{unsigned long long}.\\
     \hline                
   \end{tabular}
-  \caption{Macro definite in \file{limits.h} in conformità allo standard
+  \caption{Macro definite in \file{limits.h} in conformità allo standard
     ISO C90.}
   \label{tab:sys_isoc90_macro}
 \end{table}
@@ -148,7 +148,7 @@ sono state definite in gran parte dallo standard POSIX.1, che tratta anche i
 limiti relativi alle caratteristiche dei file che vedremo in
 sez.~\ref{sec:sys_file_limits}.
 
-Purtroppo la sezione dello standard che tratta questi argomenti è una delle
+Purtroppo la sezione dello standard che tratta questi argomenti è una delle
 meno chiare\footnote{tanto che Stevens, in \cite{APUE}, la porta come esempio
   di ``\textsl{standardese}''.}. Lo standard prevede che ci siano 13 macro che
 descrivono le caratteristiche del sistema (7 per le caratteristiche generiche,
@@ -167,9 +167,9 @@ file, riportate in tab.~\ref{tab:sys_file_macro}).
                               passati ad una funzione della famiglia
                               \func{exec}.\\ 
     \const{CHILD\_MAX} & 999& Numero massimo di processi contemporanei
-                              che un utente può eseguire.\\
+                              che un utente può eseguire.\\
     \const{OPEN\_MAX}  & 256& Numero massimo di file che un processo
-                              può mantenere aperti in contemporanea.\\
+                              può mantenere aperti in contemporanea.\\
     \const{STREAM\_MAX}&   8& Massimo numero di stream aperti per
                               processo in contemporanea.\\
     \const{TZNAME\_MAX}&   6& Dimensione massima del nome di una
@@ -187,14 +187,14 @@ file, riportate in tab.~\ref{tab:sys_file_macro}).
 Lo standard dice che queste macro devono essere definite in \file{limits.h}
 quando i valori a cui fanno riferimento sono fissi, e altrimenti devono essere
 lasciate indefinite, ed i loro valori dei limiti devono essere accessibili
-solo attraverso \func{sysconf}.  In realtà queste vengono sempre definite ad
+solo attraverso \func{sysconf}.  In realtà queste vengono sempre definite ad
 un valore generico. Si tenga presente poi che alcuni di questi limiti possono
-assumere valori molto elevati (come \const{CHILD\_MAX}), e non è pertanto il
+assumere valori molto elevati (come \const{CHILD\_MAX}), e non è pertanto il
 caso di utilizzarli per allocare staticamente della memoria.
 
 A complicare la faccenda si aggiunge il fatto che POSIX.1 prevede una serie di
 altre costanti (il cui nome inizia sempre con \code{\_POSIX\_}) che
-definiscono i valori minimi le stesse caratteristiche devono avere, perché una
+definiscono i valori minimi le stesse caratteristiche devono avere, perché una
 implementazione possa dichiararsi conforme allo standard; detti valori sono
 riportati in tab.~\ref{tab:sys_posix1_general}.
 
@@ -210,10 +210,10 @@ riportati in tab.~\ref{tab:sys_posix1_general}.
                                          passati ad una funzione della famiglia
                                          \func{exec}.\\ 
     \const{\_POSIX\_CHILD\_MAX}  &    6& Numero massimo di processi
-                                         contemporanei che un utente può 
+                                         contemporanei che un utente può 
                                          eseguire.\\
     \const{\_POSIX\_OPEN\_MAX}   &   16& Numero massimo di file che un processo
-                                         può mantenere aperti in 
+                                         può mantenere aperti in 
                                          contemporanea.\\
     \const{\_POSIX\_STREAM\_MAX} &    8& Massimo numero di stream aperti per
                                          processo in contemporanea.\\
@@ -230,14 +230,14 @@ riportati in tab.~\ref{tab:sys_posix1_general}.
     \hline                
   \end{tabular}
   \caption{Macro dei valori minimi delle caratteristiche generali del sistema
-    per la conformità allo standard POSIX.1.}
+    per la conformità allo standard POSIX.1.}
   \label{tab:sys_posix1_general}
 \end{table}
 
-In genere questi valori non servono a molto, la loro unica utilità è quella di
-indicare un limite superiore che assicura la portabilità senza necessità di
+In genere questi valori non servono a molto, la loro unica utilità è quella di
+indicare un limite superiore che assicura la portabilità senza necessità di
 ulteriori controlli. Tuttavia molti di essi sono ampiamente superati in tutti
-i sistemi POSIX in uso oggigiorno. Per questo è sempre meglio utilizzare i
+i sistemi POSIX in uso oggigiorno. Per questo è sempre meglio utilizzare i
 valori ottenuti da \func{sysconf}.
 
 \begin{table}[htb]
@@ -260,7 +260,7 @@ valori ottenuti da \func{sysconf}.
                                    199009L).\\
     \hline
   \end{tabular}
-  \caption{Alcune macro definite in \file{limits.h} in conformità allo standard
+  \caption{Alcune macro definite in \file{limits.h} in conformità allo standard
     POSIX.1.}
   \label{tab:sys_posix1_other}
 \end{table}
@@ -268,11 +268,11 @@ valori ottenuti da \func{sysconf}.
 Oltre ai precedenti valori (e a quelli relativi ai file elencati in
 tab.~\ref{tab:sys_posix1_file}), che devono essere obbligatoriamente definiti,
 lo standard POSIX.1 ne prevede parecchi altri.  La lista completa si trova
-dall'header file \file{bits/posix1\_lim.h} (da non usare mai direttamente, è
+dall'header file \file{bits/posix1\_lim.h} (da non usare mai direttamente, è
 incluso automaticamente all'interno di \file{limits.h}). Di questi vale la
 pena menzionare alcune macro di uso comune, (riportate in
 tab.~\ref{tab:sys_posix1_other}), che non indicano un valore specifico, ma
-denotano la presenza di alcune funzionalità nel sistema (come il supporto del
+denotano la presenza di alcune funzionalità nel sistema (come il supporto del
 \textit{job control} o degli identificatori del gruppo \textit{saved}).
 
 Oltre allo standard POSIX.1, anche lo standard POSIX.2 definisce una serie di
@@ -288,24 +288,24 @@ manuale di \func{sysconf} e nel manuale delle \acr{glibc}.
 \label{sec:sys_sysconf}
 
 Come accennato in sez.~\ref{sec:sys_limits} quando uno dei limiti o delle
-caratteristiche del sistema può variare, per non dover essere costretti a
-ricompilare un programma tutte le volte che si cambiano le opzioni con cui è
-compilato il kernel, o alcuni dei parametri modificabili a run time, è
+caratteristiche del sistema può variare, per non dover essere costretti a
+ricompilare un programma tutte le volte che si cambiano le opzioni con cui è
+compilato il kernel, o alcuni dei parametri modificabili a run time, è
 necessario ottenerne il valore attraverso la funzione \funcd{sysconf}. Il
-prototipo di questa funzione è:
+prototipo di questa funzione è:
 \begin{prototype}{unistd.h}{long sysconf(int name)}
   Restituisce il valore del parametro di sistema \param{name}.
   
   \bodydesc{La funzione restituisce indietro il valore del parametro
     richiesto, o 1 se si tratta di un'opzione disponibile, 0 se l'opzione non
-    è disponibile e -1 in caso di errore (ma \var{errno} non viene impostata).}
+    è disponibile e -1 in caso di errore (ma \var{errno} non viene impostata).}
 \end{prototype}
 
 La funzione prende come argomento un intero che specifica quale dei limiti si
 vuole conoscere; uno specchietto contenente i principali valori disponibili in
-Linux è riportato in tab.~\ref{tab:sys_sysconf_par}; l'elenco completo è
-contenuto in \file{bits/confname.h}, ed una lista più esaustiva, con le
-relative spiegazioni, si può trovare nel manuale delle \acr{glibc}.
+Linux è riportato in tab.~\ref{tab:sys_sysconf_par}; l'elenco completo è
+contenuto in \file{bits/confname.h}, ed una lista più esaustiva, con le
+relative spiegazioni, si può trovare nel manuale delle \acr{glibc}.
 
 \begin{table}[htb]
   \centering
@@ -320,13 +320,13 @@ relative spiegazioni, si pu
                                   ad una funzione della famiglia \func{exec}.\\
       \texttt{\_SC\_CHILD\_MAX} & \const{\_CHILD\_MAX}&
                                   Il numero massimo di processi contemporanei
-                                  che un utente può eseguire.\\
+                                  che un utente può eseguire.\\
       \texttt{\_SC\_OPEN\_MAX}  & \const{\_OPEN\_MAX}&
-                                  Il numero massimo di file che un processo può
+                                  Il numero massimo di file che un processo può
                                   mantenere aperti in contemporanea.\\
       \texttt{\_SC\_STREAM\_MAX}& \const{STREAM\_MAX}&
                                   Il massimo numero di stream che un processo
-                                  può mantenere aperti in contemporanea. Questo
+                                  può mantenere aperti in contemporanea. Questo
                                   limite previsto anche dallo standard ANSI C,
                                   che specifica la macro {FOPEN\_MAX}.\\
       \texttt{\_SC\_TZNAME\_MAX}& \const{TZNAME\_MAX}&
@@ -335,7 +335,7 @@ relative spiegazioni, si pu
                                   sez.~\ref{sec:sys_date}).\\
       \texttt{\_SC\_NGROUPS\_MAX}&\const{NGROUP\_MAX}&
                                   Massimo numero di gruppi supplementari che
-                                  può avere un processo (vedi
+                                  può avere un processo (vedi
                                   sez.~\ref{sec:proc_access_id}).\\
       \texttt{\_SC\_SSIZE\_MAX} & \const{SSIZE\_MAX}& 
                                   Valore massimo del tipo di dato
@@ -343,12 +343,12 @@ relative spiegazioni, si pu
       \texttt{\_SC\_CLK\_TCK}   & \const{CLK\_TCK} &
                                   Il numero di \itindex{clock~tick}
                                   \textit{clock tick} al secondo, 
-                                  cioè l'unità di misura del
+                                  cioè l'unità di misura del
                                   \itindex{process~time} \textit{process
                                     time} (vedi
                                   sez.~\ref{sec:sys_unix_time}).\\  
       \texttt{\_SC\_JOB\_CONTROL}&\macro{\_POSIX\_JOB\_CONTROL}&
-                                  Indica se è supportato il \textit{job
+                                  Indica se è supportato il \textit{job
                                     control} (vedi
                                   sez.~\ref{sec:sess_job_control}) in stile
                                   POSIX.\\ 
@@ -360,7 +360,7 @@ relative spiegazioni, si pu
                                   Indica il mese e l'anno di approvazione
                                   della revisione dello standard POSIX.1 a cui
                                   il sistema fa riferimento, nel formato
-                                  YYYYMML, la revisione più recente è 199009L,
+                                  YYYYMML, la revisione più recente è 199009L,
                                   che indica il Settembre 1990.\\ 
      \hline
     \end{tabular}
@@ -368,18 +368,18 @@ relative spiegazioni, si pu
   \label{tab:sys_sysconf_par}
 \end{table}
 
-In generale ogni limite o caratteristica del sistema per cui è definita una
-macro, sia dagli standard ANSI C e ISO C90, che da POSIX.1 e POSIX.2, può
-essere ottenuto attraverso una chiamata a \func{sysconf}. Il valore si otterrà
+In generale ogni limite o caratteristica del sistema per cui è definita una
+macro, sia dagli standard ANSI C e ISO C90, che da POSIX.1 e POSIX.2, può
+essere ottenuto attraverso una chiamata a \func{sysconf}. Il valore si otterrà
 specificando come valore dell'argomento \param{name} il nome ottenuto
 aggiungendo \code{\_SC\_} ai nomi delle macro definite dai primi due, o
 sostituendolo a \code{\_POSIX\_} per le macro definite dagli gli altri due.
 
 In generale si dovrebbe fare uso di \func{sysconf} solo quando la relativa
-macro non è definita, quindi con un codice analogo al seguente:
+macro non è definita, quindi con un codice analogo al seguente:
 \includecodesnip{listati/get_child_max.c}
-ma in realtà in Linux queste macro sono comunque definite, indicando però un
-limite generico. Per questo motivo è sempre meglio usare i valori restituiti
+ma in realtà in Linux queste macro sono comunque definite, indicando però un
+limite generico. Per questo motivo è sempre meglio usare i valori restituiti
 da \func{sysconf}.
 
 
@@ -448,23 +448,23 @@ le analoghe di tab.~\ref{tab:sys_posix1_general}.
     \hline
   \end{tabular}
   \caption{Costanti dei valori minimi delle caratteristiche dei file per la
-    conformità allo standard POSIX.1.}
+    conformità allo standard POSIX.1.}
   \label{tab:sys_posix1_file}
 \end{table}
 
 Tutti questi limiti sono definiti in \file{limits.h}; come nel caso precedente
-il loro uso è di scarsa utilità in quanto ampiamente superati in tutte le
+il loro uso è di scarsa utilità in quanto ampiamente superati in tutte le
 implementazioni moderne.
 
 
 \subsection{La funzione \func{pathconf}}
 \label{sec:sys_pathconf}
 
-In generale i limiti per i file sono molto più soggetti ad essere variabili
+In generale i limiti per i file sono molto più soggetti ad essere variabili
 rispetto ai limiti generali del sistema; ad esempio parametri come la
 lunghezza del nome del file o il numero di link possono variare da filesystem
 a filesystem; per questo motivo questi limiti devono essere sempre controllati
-con la funzione \funcd{pathconf}, il cui prototipo è:
+con la funzione \funcd{pathconf}, il cui prototipo è:
 \begin{prototype}{unistd.h}{long pathconf(char *path, int name)}
   Restituisce il valore del parametro \param{name} per il file \param{path}.
   
@@ -474,35 +474,35 @@ con la funzione \funcd{pathconf}, il cui prototipo 
 \end{prototype}
 
 E si noti come la funzione in questo caso richieda un argomento che specifichi
-a quale file si fa riferimento, dato che il valore del limite cercato può
+a quale file si fa riferimento, dato che il valore del limite cercato può
 variare a seconda del filesystem. Una seconda versione della funzione,
 \funcd{fpathconf}, opera su un file descriptor invece che su un
-\itindex{pathname} \textit{pathname}. Il suo prototipo è:
+\itindex{pathname} \textit{pathname}. Il suo prototipo è:
 \begin{prototype}{unistd.h}{long fpathconf(int fd, int name)}
   Restituisce il valore del parametro \param{name} per il file \param{fd}.
   
-  \bodydesc{È identica a \func{pathconf} solo che utilizza un file descriptor
+  \bodydesc{È identica a \func{pathconf} solo che utilizza un file descriptor
     invece di un \itindex{pathname} \textit{pathname}; pertanto gli errori
     restituiti cambiano di conseguenza.}
 \end{prototype}
-\noindent ed il suo comportamento è identico a quello di \func{pathconf}.
+\noindent ed il suo comportamento è identico a quello di \func{pathconf}.
 
 
 \subsection{La funzione \func{uname}}
 \label{sec:sys_uname}
 
-Un'altra funzione che si può utilizzare per raccogliere informazioni sia
-riguardo al sistema che al computer su cui esso sta girando è \funcd{uname};
-il suo prototipo è:
+Un'altra funzione che si può utilizzare per raccogliere informazioni sia
+riguardo al sistema che al computer su cui esso sta girando è \funcd{uname};
+il suo prototipo è:
 \begin{prototype}{sys/utsname.h}{int uname(struct utsname *info)}
   Restituisce informazioni sul sistema nella struttura \param{info}.
   
   \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di
-    fallimento, nel qual caso \var{errno} assumerà il valore \errval{EFAULT}.}
+    fallimento, nel qual caso \var{errno} assumerà il valore \errval{EFAULT}.}
 \end{prototype}
 
 La funzione, che viene usata dal comando \cmd{uname}, restituisce le
-informazioni richieste nella struttura \param{info}; anche questa struttura è
+informazioni richieste nella struttura \param{info}; anche questa struttura è
 definita in \file{sys/utsname.h}, secondo quanto mostrato in
 fig.~\ref{fig:sys_utsname}, e le informazioni memorizzate nei suoi membri
 indicano rispettivamente:
@@ -514,8 +514,8 @@ indicano rispettivamente:
 \item il nome della stazione;
 \item il nome del domino.
 \end{itemize*}
-l'ultima informazione è stata aggiunta di recente e non è prevista dallo
-standard POSIX, essa è accessibile, come mostrato in
+l'ultima informazione è stata aggiunta di recente e non è prevista dallo
+standard POSIX, essa è accessibile, come mostrato in
 fig.~\ref{fig:sys_utsname}, solo definendo \macro{\_GNU\_SOURCE}.
 
 \begin{figure}[!htb]
@@ -529,13 +529,13 @@ fig.~\ref{fig:sys_utsname}, solo definendo \macro{\_GNU\_SOURCE}.
 \end{figure}
 
 In generale si tenga presente che le dimensioni delle stringhe di una
-struttura \struct{utsname} non è specificata, e che esse sono sempre terminate
+struttura \struct{utsname} non è specificata, e che esse sono sempre terminate
 con NUL; il manuale delle \acr{glibc} indica due diverse dimensioni,
 \const{\_UTSNAME\_LENGTH} per i campi standard e
 \const{\_UTSNAME\_DOMAIN\_LENGTH} per quello specifico per il nome di dominio;
 altri sistemi usano nomi diversi come \const{SYS\_NMLN} o \const{\_SYS\_NMLN}
 o \const{UTSLEN} che possono avere valori diversi.\footnote{nel caso di Linux
-  \func{uname} corrisponde in realtà a 3 system call diverse, le prime due
+  \func{uname} corrisponde in realtà a 3 system call diverse, le prime due
   usano rispettivamente delle lunghezze delle stringhe di 9 e 65 byte; la
   terza usa anch'essa 65 byte, ma restituisce anche l'ultimo campo,
   \var{domainname}, con una lunghezza di 257 byte.}
@@ -546,12 +546,12 @@ o \const{UTSLEN} che possono avere valori diversi.\footnote{nel caso di Linux
 
 Come abbiamo accennato nella sezione precedente, non tutti i limiti che
 caratterizzano il sistema sono fissi, o perlomeno non lo sono in tutte le
-implementazioni. Finora abbiamo visto come si può fare per leggerli, ci manca
+implementazioni. Finora abbiamo visto come si può fare per leggerli, ci manca
 di esaminare il meccanismo che permette, quando questi possono variare durante
 l'esecuzione del sistema, di modificarli.
 
 Inoltre, al di la di quelli che possono essere limiti caratteristici previsti
-da uno standard, ogni sistema può avere una sua serie di altri parametri di
+da uno standard, ogni sistema può avere una sua serie di altri parametri di
 configurazione, che, non essendo mai fissi e variando da sistema a sistema,
 non sono stati inclusi nella standardizzazione della sezione precedente. Per
 questi occorre, oltre al meccanismo di impostazione, pure un meccanismo di
@@ -565,8 +565,8 @@ sistema, come quelle per la gestione dei filesystem e di utenti e gruppi.
 \label{sec:sys_sysctl}
 
 La funzione che permette la lettura ed l'impostazione dei parametri del
-sistema è \funcd{sysctl}; è una funzione derivata da BSD4.4, ma
-l'implementazione è specifica di Linux; il suo prototipo è:
+sistema è \funcd{sysctl}; è una funzione derivata da BSD4.4, ma
+l'implementazione è specifica di Linux; il suo prototipo è:
 \begin{functions}
 \headdecl{unistd.h}
 \funcdecl{int sysctl(int *name, int nlen, void *oldval, size\_t *oldlenp, void
@@ -575,20 +575,20 @@ l'implementazione 
 Legge o scrive uno dei parametri di sistema.
 
 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-  errore, nel qual caso \var{errno} assumerà uno dei valori:
+  errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
   \item[\errcode{EPERM}] non si ha il permesso di accedere ad uno dei
     componenti nel cammino specificato per il parametro, o di accedere al
-    parametro nella modalità scelta.
+    parametro nella modalità scelta.
   \item[\errcode{ENOTDIR}] non esiste un parametro corrispondente al nome
     \param{name}.
-%  \item[\errcode{EFAULT}] si è specificato \param{oldlenp} zero quando
-%    \param{oldval} è non nullo. 
-  \item[\errcode{EINVAL}] o si è specificato un valore non valido per il
+%  \item[\errcode{EFAULT}] si è specificato \param{oldlenp} zero quando
+%    \param{oldval} è non nullo. 
+  \item[\errcode{EINVAL}] o si è specificato un valore non valido per il
     parametro che si vuole impostare o lo spazio provvisto per il ritorno di un
-    valore non è delle giuste dimensioni.
-  \item[\errcode{ENOMEM}] talvolta viene usato più correttamente questo errore
-    quando non si è specificato sufficiente spazio per ricevere il valore di un
+    valore non è delle giuste dimensioni.
+  \item[\errcode{ENOMEM}] talvolta viene usato più correttamente questo errore
+    quando non si è specificato sufficiente spazio per ricevere il valore di un
     parametro.
   \end{errlist}
   ed inoltre \errval{EFAULT}.
@@ -599,35 +599,35 @@ I parametri a cui la funzione permettere di accedere sono organizzati in
 maniera gerarchica all'interno di un albero;\footnote{si tenga presente che
   includendo solo \file{unistd.h}, saranno definiti solo i parametri generici;
   dato che ce ne sono molti specifici dell'implementazione, nel caso di Linux
-  occorrerà includere anche i file \file{linux/unistd.h} e
+  occorrerà includere anche i file \file{linux/unistd.h} e
   \file{linux/sysctl.h}.} per accedere ad uno di essi occorre specificare un
 cammino attraverso i vari nodi dell'albero, in maniera analoga a come avviene
 per la risoluzione di un \itindex{pathname} \textit{pathname} (da cui l'uso
 alternativo del filesystem \file{/proc}, che vedremo dopo).
 
-Ciascun nodo dell'albero è identificato da un valore intero, ed il cammino che
-arriva ad identificare un parametro specifico è passato alla funzione
+Ciascun nodo dell'albero è identificato da un valore intero, ed il cammino che
+arriva ad identificare un parametro specifico è passato alla funzione
 attraverso l'array \param{name}, di lunghezza \param{nlen}, che contiene la
 sequenza dei vari nodi da attraversare. Ogni parametro ha un valore in un
-formato specifico che può essere un intero, una stringa o anche una struttura
+formato specifico che può essere un intero, una stringa o anche una struttura
 complessa, per questo motivo i valori vengono passati come puntatori
 \ctyp{void}.
 
-L'indirizzo a cui il valore corrente del parametro deve essere letto è
-specificato da \param{oldvalue}, e lo spazio ivi disponibile è specificato da
+L'indirizzo a cui il valore corrente del parametro deve essere letto è
+specificato da \param{oldvalue}, e lo spazio ivi disponibile è specificato da
 \param{oldlenp} (passato come puntatore per avere indietro la dimensione
-effettiva di quanto letto); il valore che si vuole impostare nel sistema è
+effettiva di quanto letto); il valore che si vuole impostare nel sistema è
 passato in \param{newval} e la sua dimensione in \param{newlen}.
 
-Si può effettuare anche una lettura e scrittura simultanea, nel qual caso il
-valore letto restituito dalla funzione è quello precedente alla scrittura.
+Si può effettuare anche una lettura e scrittura simultanea, nel qual caso il
+valore letto restituito dalla funzione è quello precedente alla scrittura.
 
 I parametri accessibili attraverso questa funzione sono moltissimi, e possono
 essere trovati in \file{sysctl.h}, essi inoltre dipendono anche dallo stato
 corrente del kernel (ad esempio dai moduli che sono stati caricati nel
 sistema) e in genere i loro nomi possono variare da una versione di kernel
-all'altra; per questo è sempre il caso di evitare l'uso di \func{sysctl}
-quando esistono modalità alternative per ottenere le stesse informazioni.
+all'altra; per questo è sempre il caso di evitare l'uso di \func{sysctl}
+quando esistono modalità alternative per ottenere le stesse informazioni.
 Alcuni esempi di parametri ottenibili sono:
 \begin{itemize}
 \item il nome di dominio
@@ -638,14 +638,14 @@ Alcuni esempi di parametri ottenibili sono:
 \item il numero massimo di file aperti
 \end{itemize}
 
-Come accennato in Linux si ha una modalità alternativa per accedere alle
+Come accennato in Linux si ha una modalità alternativa per accedere alle
 stesse informazioni di \func{sysctl} attraverso l'uso del filesystem
-\file{/proc}. Questo è un filesystem virtuale, generato direttamente dal
+\file{/proc}. Questo è un filesystem virtuale, generato direttamente dal
 kernel, che non fa riferimento a nessun dispositivo fisico, ma presenta in
 forma di file alcune delle strutture interne del kernel stesso.
 
 In particolare l'albero dei valori di \func{sysctl} viene presentato in forma
-di file nella directory \file{/proc/sys}, cosicché è possibile accedervi
+di file nella directory \file{/proc/sys}, cosicché è possibile accedervi
 specificando un \itindex{pathname} \textit{pathname} e leggendo e scrivendo sul
 file corrispondente al parametro scelto.  Il kernel si occupa di generare al
 volo il contenuto ed i nomi dei file corrispondenti, e questo ha il grande
@@ -653,11 +653,11 @@ vantaggio di rendere accessibili i vari parametri a qualunque comando di shell
 e di permettere la navigazione dell'albero dei valori.
 
 Alcune delle corrispondenze dei file presenti in \file{/proc/sys} con i valori
-di \func{sysctl} sono riportate nei commenti del codice che può essere trovato
+di \func{sysctl} sono riportate nei commenti del codice che può essere trovato
 in \file{linux/sysctl.h},\footnote{indicando un file di definizioni si fa
   riferimento alla directory standard dei file di include, che in ogni
-  distribuzione che si rispetti è \file{/usr/include}.} la informazione
-disponibile in \file{/proc/sys} è riportata inoltre nella documentazione
+  distribuzione che si rispetti è \file{/usr/include}.} la informazione
+disponibile in \file{/proc/sys} è riportata inoltre nella documentazione
 inclusa nei sorgenti del kernel, nella directory \file{Documentation/sysctl}.
 
 Ma oltre alle informazioni ottenibili da \func{sysctl} dentro \file{proc} sono
@@ -671,15 +671,15 @@ file \procrelfile{/proc/sys/kernel}{ostype},
 
 
 
-\subsection{La gestione delle proprietà dei filesystem}
+\subsection{La gestione delle proprietà dei filesystem}
 \label{sec:sys_file_config}
 
 Come accennato in sez.~\ref{sec:file_organization} per poter accedere ai file
 occorre prima rendere disponibile al sistema il filesystem su cui essi sono
-memorizzati; l'operazione di attivazione del filesystem è chiamata
-\textsl{montaggio}, per far questo in Linux\footnote{la funzione è specifica
-  di Linux e non è portabile.} si usa la funzione \funcd{mount} il cui
-prototipo è:
+memorizzati; l'operazione di attivazione del filesystem è chiamata
+\textsl{montaggio}, per far questo in Linux\footnote{la funzione è specifica
+  di Linux e non è portabile.} si usa la funzione \funcd{mount} il cui
+prototipo è:
 \begin{prototype}{sys/mount.h}
 {mount(const char *source, const char *target, const char *filesystemtype, 
   unsigned long mountflags, const void *data)}
@@ -692,46 +692,46 @@ sulla directory \param{target}.
   essere restituiti in \var{errno} sono:
   \begin{errlist}
   \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
-  \item[\errcode{ENODEV}] \param{filesystemtype} non esiste o non è configurato
+  \item[\errcode{ENODEV}] \param{filesystemtype} non esiste o non è configurato
     nel kernel.
-  \item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per
+  \item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per
     \param{source} quando era richiesto.
-  \item[\errcode{EBUSY}] \param{source} è già montato, o non può essere
-    rimontato in read-only perché ci sono ancora file aperti in scrittura, o
-    \param{target} è ancora in uso.
+  \item[\errcode{EBUSY}] \param{source} è già montato, o non può essere
+    rimontato in read-only perché ci sono ancora file aperti in scrittura, o
+    \param{target} è ancora in uso.
   \item[\errcode{EINVAL}] il device \param{source} presenta un
-    \textit{superblock} non valido, o si è cercato di rimontare un filesystem
+    \textit{superblock} non valido, o si è cercato di rimontare un filesystem
     non ancora montato, o di montarlo senza che \param{target} sia un
-    \textit{mount point} o di spostarlo quando \param{target} non è un
-    \textit{mount point} o è \file{/}.
+    \textit{mount point} o di spostarlo quando \param{target} non è un
+    \textit{mount point} o è \file{/}.
   \item[\errcode{EACCES}] non si ha il permesso di accesso su uno dei
-    componenti del \itindex{pathname} \textit{pathname}, o si è cercato
+    componenti del \itindex{pathname} \textit{pathname}, o si è cercato
     di montare un filesystem disponibile in sola lettura senza averlo
-    specificato o il device \param{source} è su un filesystem montato con
+    specificato o il device \param{source} è su un filesystem montato con
     l'opzione \const{MS\_NODEV}.
   \item[\errcode{ENXIO}] il \itindex{major~number} \textit{major number} del
-    device \param{source} è sbagliato.
-  \item[\errcode{EMFILE}] la tabella dei device \textit{dummy} è piena.
+    device \param{source} è sbagliato.
+  \item[\errcode{EMFILE}] la tabella dei device \textit{dummy} è piena.
   \end{errlist}
   ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM},
   \errval{ENAMETOOLONG}, \errval{ENOENT} o \errval{ELOOP}.}
 \end{prototype}
 
 La funzione monta sulla directory \param{target}, detta \textit{mount point},
-il filesystem contenuto in \param{source}. In generale un filesystem è
+il filesystem contenuto in \param{source}. In generale un filesystem è
 contenuto su un disco, e l'operazione di montaggio corrisponde a rendere
 visibile al sistema il contenuto del suddetto disco, identificato attraverso
 il file di dispositivo ad esso associato.
 
-Ma la struttura del virtual filesystem vista in sez.~\ref{sec:file_vfs} è molto
-più flessibile e può essere usata anche per oggetti diversi da un disco. Ad
-esempio usando il \textit{loop device} si può montare un file qualunque (come
+Ma la struttura del virtual filesystem vista in sez.~\ref{sec:file_vfs} è molto
+più flessibile e può essere usata anche per oggetti diversi da un disco. Ad
+esempio usando il \textit{loop device} si può montare un file qualunque (come
 l'immagine di un CD-ROM o di un floppy) che contiene un filesystem, inoltre
 alcuni filesystem, come \file{proc} o \file{devfs} sono del tutto virtuali, i
 loro dati sono generati al volo ad ogni lettura, e passati al kernel ad ogni
 scrittura. 
 
-Il tipo di filesystem è specificato da \param{filesystemtype}, che deve essere
+Il tipo di filesystem è specificato da \param{filesystemtype}, che deve essere
 una delle stringhe riportate nel file \procfile{/proc/filesystems}, che
 contiene l'elenco dei filesystem supportati dal kernel; nel caso si sia
 indicato uno dei filesystem virtuali, il contenuto di \param{source} viene
@@ -742,20 +742,20 @@ disponibile nella directory specificata come \textit{mount point}, il
 precedente contenuto di detta directory viene mascherato dal contenuto della
 directory radice del filesystem montato.
 
-Dal kernel 2.4.x inoltre è divenuto possibile sia spostare atomicamente un
+Dal kernel 2.4.x inoltre è divenuto possibile sia spostare atomicamente un
 \textit{mount point} da una directory ad un'altra, sia montare in diversi
-\textit{mount point} lo stesso filesystem, sia montare più filesystem sullo
+\textit{mount point} lo stesso filesystem, sia montare più filesystem sullo
 stesso \textit{mount point} (nel qual caso vale quanto appena detto, e solo il
-contenuto dell'ultimo filesystem montato sarà visibile).
+contenuto dell'ultimo filesystem montato sarà visibile).
 
-Ciascun filesystem è dotato di caratteristiche specifiche che possono essere
-attivate o meno, alcune di queste sono generali (anche se non è detto siano
+Ciascun filesystem è dotato di caratteristiche specifiche che possono essere
+attivate o meno, alcune di queste sono generali (anche se non è detto siano
 disponibili in ogni filesystem), e vengono specificate come opzioni di
 montaggio con l'argomento \param{mountflags}.  
 
-In Linux \param{mountflags} deve essere un intero a 32 bit i cui 16 più
-significativi sono un \textit{magic number}\footnote{cioè un numero speciale
-  usato come identificativo, che nel caso è \code{0xC0ED}; si può usare la
+In Linux \param{mountflags} deve essere un intero a 32 bit i cui 16 più
+significativi sono un \textit{magic number}\footnote{cioè un numero speciale
+  usato come identificativo, che nel caso è \code{0xC0ED}; si può usare la
   costante \const{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags}
   riservata al \textit{magic number}.} mentre i 16 meno significativi sono
 usati per specificare le opzioni; essi sono usati come maschera binaria e
@@ -798,66 +798,66 @@ valori riportati in tab.~\ref{tab:sys_mount_flags}.
 \end{table}
 
 % TODO aggiornare con i nuovi flag di man mount
-% gli S_* non esistono più come segnalato da Alessio...
+% gli S_* non esistono più come segnalato da Alessio...
 % verificare i readonly mount bind del 2.6.26
 
 Per l'impostazione delle caratteristiche particolari di ciascun filesystem si
 usa invece l'argomento \param{data} che serve per passare le ulteriori
 informazioni necessarie, che ovviamente variano da filesystem a filesystem.
 
-La funzione \func{mount} può essere utilizzata anche per effettuare il
+La funzione \func{mount} può essere utilizzata anche per effettuare il
 \textsl{rimontaggio} di un filesystem, cosa che permette di cambiarne al volo
 alcune delle caratteristiche di funzionamento (ad esempio passare da sola
-lettura a lettura/scrittura). Questa operazione è attivata attraverso uno dei
+lettura a lettura/scrittura). Questa operazione è attivata attraverso uno dei
 bit di \param{mountflags}, \const{MS\_REMOUNT}, che se impostato specifica che
 deve essere effettuato il rimontaggio del filesystem (con le opzioni
 specificate dagli altri bit), anche in questo caso il valore di \param{source}
 viene ignorato.
 
-Una volta che non si voglia più utilizzare un certo filesystem è possibile
-\textsl{smontarlo} usando la funzione \funcd{umount}, il cui prototipo è:
+Una volta che non si voglia più utilizzare un certo filesystem è possibile
+\textsl{smontarlo} usando la funzione \funcd{umount}, il cui prototipo è:
 \begin{prototype}{sys/mount.h}{umount(const char *target)}
   
   Smonta il filesystem montato sulla directory \param{target}.
   
   \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di
-    fallimento, nel qual caso \var{errno} assumerà uno dei valori:
+    fallimento, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
   \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
-  \item[\errcode{EBUSY}]  \param{target} è la directory di lavoro di qualche
+  \item[\errcode{EBUSY}]  \param{target} è la directory di lavoro di qualche
   processo, o contiene dei file aperti, o un altro mount point.
   \end{errlist}
   ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM},
   \errval{ENAMETOOLONG}, \errval{ENOENT} o \errval{ELOOP}.}
 \end{prototype}
-\noindent la funzione prende il nome della directory su cui il filesystem è
-montato e non il file o il dispositivo che è stato montato,\footnote{questo è
+\noindent la funzione prende il nome della directory su cui il filesystem è
+montato e non il file o il dispositivo che è stato montato,\footnote{questo è
   vero a partire dal kernel 2.3.99-pre7, prima esistevano due chiamate
   separate e la funzione poteva essere usata anche specificando il file di
-  dispositivo.} in quanto con il kernel 2.4.x è possibile montare lo stesso
-dispositivo in più punti. Nel caso più di un filesystem sia stato montato
-sullo stesso \textit{mount point} viene smontato quello che è stato montato
+  dispositivo.} in quanto con il kernel 2.4.x è possibile montare lo stesso
+dispositivo in più punti. Nel caso più di un filesystem sia stato montato
+sullo stesso \textit{mount point} viene smontato quello che è stato montato
 per ultimo.
 
-Si tenga presente che la funzione fallisce quando il filesystem è
+Si tenga presente che la funzione fallisce quando il filesystem è
 \textsl{occupato}, questo avviene quando ci sono ancora file aperti sul
 filesystem, se questo contiene la directory di lavoro corrente di un qualunque
 processo o il mount point di un altro filesystem; in questo caso l'errore
-restituito è \errcode{EBUSY}.
+restituito è \errcode{EBUSY}.
 
 Linux provvede inoltre una seconda funzione, \funcd{umount2}, che in alcuni
 casi permette di forzare lo smontaggio di un filesystem, anche quando questo
-risulti occupato; il suo prototipo è:
+risulti occupato; il suo prototipo è:
 \begin{prototype}{sys/mount.h}{umount2(const char *target, int flags)}
   
-  La funzione è identica a \func{umount} per comportamento e codici di errore,
-  ma con \param{flags} si può specificare se forzare lo smontaggio.
+  La funzione è identica a \func{umount} per comportamento e codici di errore,
+  ma con \param{flags} si può specificare se forzare lo smontaggio.
 \end{prototype}
 
-Il valore di \param{flags} è una maschera binaria, e al momento l'unico valore
-definito è il bit \const{MNT\_FORCE}; gli altri bit devono essere nulli.
-Specificando \const{MNT\_FORCE} la funzione cercherà di liberare il filesystem
-anche se è occupato per via di una delle condizioni descritte in precedenza. A
+Il valore di \param{flags} è una maschera binaria, e al momento l'unico valore
+definito è il bit \const{MNT\_FORCE}; gli altri bit devono essere nulli.
+Specificando \const{MNT\_FORCE} la funzione cercherà di liberare il filesystem
+anche se è occupato per via di una delle condizioni descritte in precedenza. A
 seconda del tipo di filesystem alcune (o tutte) possono essere superate,
 evitando l'errore di \errcode{EBUSY}.  In tutti i casi prima dello smontaggio
 viene eseguita una sincronizzazione dei dati. 
@@ -874,11 +874,11 @@ informazioni riguardo al filesystem su cui si trova un certo file, sono
 
   \funcdecl{int fstatfs(int fd, struct statfs *buf)} 
   
-  Restituisce in \param{buf} le informazioni relative al filesystem su cui è
+  Restituisce in \param{buf} le informazioni relative al filesystem su cui è
   posto il file specificato.
   
   \bodydesc{Le funzioni ritornano 0 in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
   \item[\errcode{ENOSYS}] il filesystem su cui si trova il file specificato non
   supporta la funzione.
@@ -895,7 +895,7 @@ come in fig.~\ref{fig:sys_statfs}, ed i campi che sono indefiniti per il
 filesystem in esame sono impostati a zero.  I valori del campo \var{f\_type}
 sono definiti per i vari filesystem nei relativi file di header dei sorgenti
 del kernel da costanti del tipo \var{XXX\_SUPER\_MAGIC}, dove \var{XXX} in
-genere è il nome del filesystem stesso.
+genere è il nome del filesystem stesso.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -918,7 +918,7 @@ opportune strutture \struct{fstab} e \struct{mntent}, e, per
 
 In generale si dovrebbero usare queste funzioni (in particolare quelle
 relative a \conffile{/etc/mtab}), quando si debba scrivere un programma che
-effettua il montaggio di un filesystem; in realtà in questi casi è molto più
+effettua il montaggio di un filesystem; in realtà in questi casi è molto più
 semplice invocare direttamente il programma \cmd{mount}, per cui ne
 tralasceremo la trattazione, rimandando al manuale delle \acr{glibc}
 \cite{glibc} per la documentazione completa.
@@ -940,38 +940,38 @@ tralasceremo la trattazione, rimandando al manuale delle \acr{glibc}
 Tradizionalmente le informazioni utilizzate nella gestione di utenti e gruppi
 (password, corrispondenze fra nomi simbolici e user-id, home directory, ecc.)
 venivano registrate all'interno dei due file di testo \conffile{/etc/passwd}
-ed \conffile{/etc/group},\footnote{in realtà oltre a questi nelle
-  distribuzioni più recenti è stato introdotto il sistema delle \textit{shadow
+ed \conffile{/etc/group},\footnote{in realtà oltre a questi nelle
+  distribuzioni più recenti è stato introdotto il sistema delle \textit{shadow
     password} che prevede anche i due file \conffile{/etc/shadow} e
   \conffile{/etc/gshadow}, in cui sono state spostate le informazioni di
   autenticazione (ed inserite alcune estensioni) per toglierle dagli altri
   file che devono poter essere letti per poter effettuare l'associazione fra
-  username e \acr{uid}.} il cui formato è descritto dalle relative pagine del
+  username e \acr{uid}.} il cui formato è descritto dalle relative pagine del
 manuale\footnote{nella quinta sezione, quella dei file di configurazione,
-  occorre cioè usare \cmd{man 5 passwd} dato che altrimenti si avrebbe la
+  occorre cioè usare \cmd{man 5 passwd} dato che altrimenti si avrebbe la
   pagina di manuale del comando \cmd{passwd}.} e tutte le funzioni che
 richiedevano l'accesso a queste informazione andavano a leggere direttamente
 il contenuto di questi file.
 
-Col tempo però questa impostazione ha incominciato a mostrare dei limiti: da
-una parte il meccanismo classico di autenticazione è stato ampliato, ed oggi
+Col tempo però questa impostazione ha incominciato a mostrare dei limiti: da
+una parte il meccanismo classico di autenticazione è stato ampliato, ed oggi
 la maggior parte delle distribuzioni di GNU/Linux usa la libreria PAM (sigla
 che sta per \textit{Pluggable Authentication Method}) che fornisce una
 interfaccia comune per i processi di autenticazione,\footnote{il
-  \textit{Pluggable Authentication Method} è un sistema modulare, in cui è
-  possibile utilizzare anche più meccanismi insieme, diventa così possibile
+  \textit{Pluggable Authentication Method} è un sistema modulare, in cui è
+  possibile utilizzare anche più meccanismi insieme, diventa così possibile
   avere vari sistemi di riconoscimento (biometria, chiavi hardware, ecc.),
   diversi formati per le password e diversi supporti per le informazioni, il
-  tutto in maniera trasparente per le applicazioni purché per ciascun
+  tutto in maniera trasparente per le applicazioni purché per ciascun
   meccanismo si disponga della opportuna libreria che implementa l'interfaccia
   di PAM.}  svincolando completamente le singole applicazione dai dettagli del
 come questa viene eseguita e di dove vengono mantenuti i dati relativi;
-dall'altra con il diffondersi delle reti la necessità di centralizzare le
+dall'altra con il diffondersi delle reti la necessità di centralizzare le
 informazioni degli utenti e dei gruppi per insiemi di macchine, in modo da
-mantenere coerenti i dati, ha portato anche alla necessità di poter recuperare
+mantenere coerenti i dati, ha portato anche alla necessità di poter recuperare
 e memorizzare dette informazioni su supporti diversi, introducendo il sistema
 del \itindex{Name~Service~Switch} \textit{Name Service Switch} che tratteremo
-brevemente più avanti (in sez.~\ref{sec:sock_resolver}) dato che la maggior
+brevemente più avanti (in sez.~\ref{sec:sock_resolver}) dato che la maggior
 parte delle sua applicazioni sono relative alla risoluzioni di nomi di rete.
 
 In questo paragrafo ci limiteremo comunque a trattare le funzioni classiche
@@ -1005,11 +1005,11 @@ relative ad un utente si possono usare due funzioni, \funcd{getpwuid} e
 \end{functions}
 
 Le due funzioni forniscono le informazioni memorizzate nel registro degli
-utenti (che nelle versioni più recenti possono essere ottenute attraverso PAM)
+utenti (che nelle versioni più recenti possono essere ottenute attraverso PAM)
 relative all'utente specificato attraverso il suo \acr{uid} o il nome di
 login. Entrambe le funzioni restituiscono un puntatore ad una struttura di
-tipo \struct{passwd} la cui definizione (anch'essa eseguita in \file{pwd.h}) è
-riportata in fig.~\ref{fig:sys_passwd_struct}, dove è pure brevemente
+tipo \struct{passwd} la cui definizione (anch'essa eseguita in \file{pwd.h}) è
+riportata in fig.~\ref{fig:sys_passwd_struct}, dove è pure brevemente
 illustrato il significato dei vari campi.
 
 \begin{figure}[!htb]
@@ -1024,7 +1024,7 @@ illustrato il significato dei vari campi.
   \label{fig:sys_passwd_struct}
 \end{figure}
 
-La struttura usata da entrambe le funzioni è allocata staticamente, per questo
+La struttura usata da entrambe le funzioni è allocata staticamente, per questo
 motivo viene sovrascritta ad ogni nuova invocazione, lo stesso dicasi per la
 memoria dove sono scritte le stringhe a cui i puntatori in essa contenuti
 fanno riferimento. Ovviamente questo implica che dette funzioni non possono
@@ -1045,19 +1045,19 @@ i cui prototipi sono:
   Restituiscono le informazioni relative all'utente specificato.
   
   \bodydesc{Le funzioni ritornano 0 in caso di successo e un codice d'errore
-    altrimenti, nel qual caso \var{errno} sarà impostata opportunamente.}
+    altrimenti, nel qual caso \var{errno} sarà impostata opportunamente.}
 \end{functions}
 
-In questo caso l'uso è molto più complesso, in quanto bisogna prima allocare
+In questo caso l'uso è molto più complesso, in quanto bisogna prima allocare
 la memoria necessaria a contenere le informazioni. In particolare i valori
 della struttura \struct{passwd} saranno restituiti all'indirizzo
 \param{password} mentre la memoria allocata all'indirizzo \param{buffer}, per
-un massimo di \param{buflen} byte, sarà utilizzata per contenere le stringhe
+un massimo di \param{buflen} byte, sarà utilizzata per contenere le stringhe
 puntate dai campi di \param{password}. Infine all'indirizzo puntato da
-\param{result} viene restituito il puntatore ai dati ottenuti, cioè
+\param{result} viene restituito il puntatore ai dati ottenuti, cioè
 \param{buffer} nel caso l'utente esista, o \val{NULL} altrimenti.  Qualora i
 dati non possano essere contenuti nei byte specificati da \param{buflen}, la
-funzione fallirà restituendo \errcode{ERANGE} (e \param{result} sarà comunque
+funzione fallirà restituendo \errcode{ERANGE} (e \param{result} sarà comunque
 impostato a \val{NULL}).
 
 Del tutto analoghe alle precedenti sono le funzioni \funcd{getgrnam} e
@@ -1081,13 +1081,13 @@ informazioni relative ai gruppi, i loro prototipi sono:
   Restituiscono le informazioni relative al gruppo specificato.
   
   \bodydesc{Le funzioni ritornano 0 in caso di successo e un codice d'errore
-    altrimenti, nel qual caso \var{errno} sarà impostata opportunamente.}
+    altrimenti, nel qual caso \var{errno} sarà impostata opportunamente.}
 \end{functions}
 
-Il comportamento di tutte queste funzioni è assolutamente identico alle
-precedenti che leggono le informazioni sugli utenti, l'unica differenza è che
+Il comportamento di tutte queste funzioni è assolutamente identico alle
+precedenti che leggono le informazioni sugli utenti, l'unica differenza è che
 in questo caso le informazioni vengono restituite in una struttura di tipo
-\struct{group}, la cui definizione è riportata in
+\struct{group}, la cui definizione è riportata in
 fig.~\ref{fig:sys_group_struct}.
 
 \begin{figure}[!htb]
@@ -1105,12 +1105,12 @@ fig.~\ref{fig:sys_group_struct}.
 Le funzioni viste finora sono in grado di leggere le informazioni sia
 direttamente dal file delle password in \conffile{/etc/passwd} che tramite il
 sistema del \itindex{Name~Service~Switch} \textit{Name Service Switch} e sono
-completamente generiche. Si noti però che non c'è una funzione che permetta di
-impostare direttamente una password.\footnote{in realtà questo può essere
-  fatto ricorrendo a PAM, ma questo è un altro discorso.} Dato che POSIX non
-prevede questa possibilità esiste un'altra interfaccia che lo fa, derivata da
+completamente generiche. Si noti però che non c'è una funzione che permetta di
+impostare direttamente una password.\footnote{in realtà questo può essere
+  fatto ricorrendo a PAM, ma questo è un altro discorso.} Dato che POSIX non
+prevede questa possibilità esiste un'altra interfaccia che lo fa, derivata da
 SVID le cui funzioni sono riportate in tab.~\ref{tab:sys_passwd_func}. Questa
-però funziona soltanto quando le informazioni sono mantenute su un apposito
+però funziona soltanto quando le informazioni sono mantenute su un apposito
 file di \textsl{registro} di utenti e gruppi, con il formato classico di
 \conffile{/etc/passwd} e \conffile{/etc/group}.
 
@@ -1155,23 +1155,23 @@ Dato che oramai la gran parte delle distribuzioni di GNU/Linux utilizzano
 almeno le \textit{shadow password} (quindi con delle modifiche rispetto al
 formato classico del file \conffile{/etc/passwd}), si tenga presente che le
 funzioni di questa interfaccia che permettono di scrivere delle voci in un
-\textsl{registro} degli utenti (cioè \func{putpwent} e \func{putgrent}) non
-hanno la capacità di farlo specificando tutti i contenuti necessari rispetto a
-questa estensione. Per questo motivo l'uso di queste funzioni è deprecato, in
+\textsl{registro} degli utenti (cioè \func{putpwent} e \func{putgrent}) non
+hanno la capacità di farlo specificando tutti i contenuti necessari rispetto a
+questa estensione. Per questo motivo l'uso di queste funzioni è deprecato, in
 quanto comunque non funzionale, pertanto ci limiteremo a fornire soltanto
 l'elenco di tab.~\ref{tab:sys_passwd_func}, senza nessuna spiegazione
-ulteriore.  Chi volesse insistere ad usare questa interfaccia può fare
+ulteriore.  Chi volesse insistere ad usare questa interfaccia può fare
 riferimento alle pagine di manuale delle rispettive funzioni ed al manuale
 delle \acr{glibc} per i dettagli del funzionamento.
 
 
 
-\subsection{Il registro della \textsl{contabilità} degli utenti}
+\subsection{Il registro della \textsl{contabilità} degli utenti}
 \label{sec:sys_accounting}
 
 L'ultimo insieme di funzioni relative alla gestione del sistema che
-esamineremo è quello che permette di accedere ai dati del registro della
-cosiddetta \textsl{contabilità} (o \textit{accounting}) degli utenti.  In esso
+esamineremo è quello che permette di accedere ai dati del registro della
+cosiddetta \textsl{contabilità} (o \textit{accounting}) degli utenti.  In esso
 vengono mantenute una serie di informazioni storiche relative sia agli utenti
 che si sono collegati al sistema, (tanto per quelli correntemente collegati,
 che per la registrazione degli accessi precedenti), sia relative all'intero
@@ -1179,7 +1179,7 @@ sistema, come il momento di lancio di processi da parte di \cmd{init}, il
 cambiamento dell'orologio di sistema, il cambiamento di runlevel o il riavvio
 della macchina.
 
-I dati vengono usualmente\footnote{questa è la locazione specificata dal
+I dati vengono usualmente\footnote{questa è la locazione specificata dal
   \textit{Linux Filesystem Hierarchy Standard}, adottato dalla gran parte
   delle distribuzioni.} memorizzati nei due file \file{/var/run/utmp} e
 \file{/var/log/wtmp}.\footnote{non si confonda quest'ultimo con il simile
@@ -1192,7 +1192,7 @@ al logout, quando viene cancellata e spostata in \file{/var/log/wtmp}.
 
 In questo modo il primo file viene utilizzato per registrare chi sta
 utilizzando il sistema al momento corrente, mentre il secondo mantiene la
-registrazione delle attività degli utenti. A quest'ultimo vengono anche
+registrazione delle attività degli utenti. A quest'ultimo vengono anche
 aggiunte delle voci speciali per tenere conto dei cambiamenti del sistema,
 come la modifica del runlevel, il riavvio della macchina, ecc. Tutte queste
 informazioni sono descritte in dettaglio nel manuale delle \acr{glibc}.
@@ -1201,8 +1201,8 @@ Questi file non devono mai essere letti direttamente, ma le informazioni che
 contengono possono essere ricavate attraverso le opportune funzioni di
 libreria. Queste sono analoghe alle precedenti funzioni (vedi
 tab.~\ref{tab:sys_passwd_func}) usate per accedere al registro degli utenti,
-solo che in questo caso la struttura del registro della \textsl{contabilità} è
-molto più complessa, dato che contiene diversi tipi di informazione.
+solo che in questo caso la struttura del registro della \textsl{contabilità} è
+molto più complessa, dato che contiene diversi tipi di informazione.
 
 Le prime tre funzioni, \funcd{setutent}, \funcd{endutent} e \funcd{utmpname}
 servono rispettivamente a aprire e a chiudere il file che contiene il
@@ -1222,26 +1222,26 @@ sono:
   \bodydesc{Le funzioni non ritornano codici di errore.}
 \end{functions}
 e si tenga presente che le funzioni non restituiscono nessun valore, pertanto
-non è possibile accorgersi di eventuali errori (ad esempio se si è impostato
+non è possibile accorgersi di eventuali errori (ad esempio se si è impostato
 un nome di file sbagliato con \func{utmpname}).
 
 Nel caso non si sia utilizzata \func{utmpname} per specificare un file di
 registro alternativo, sia \func{setutent} che \func{endutent} operano usando
-il default che è \file{/var/run/utmp}. Il nome di questo file, così come una
-serie di altri valori di default per i \textit{pathname} di uso più comune,
+il default che è \file{/var/run/utmp}. Il nome di questo file, così come una
+serie di altri valori di default per i \textit{pathname} di uso più comune,
 viene mantenuto nei valori di una serie di costanti definite includendo
 \file{paths.h}, in particolare quelle che ci interessano sono:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\const{\_PATH\_UTMP}] specifica il file che contiene il registro per gli
-  utenti correntemente collegati; questo è il valore che viene usato se non si
-  è utilizzato \func{utmpname} per modificarlo.
+  utenti correntemente collegati; questo è il valore che viene usato se non si
+  è utilizzato \func{utmpname} per modificarlo.
 \item[\const{\_PATH\_WTMP}] specifica il file che contiene il registro per
   l'archivio storico degli utenti collegati.
 \end{basedescript}
 che nel caso di Linux hanno un valore corrispondente ai file
 \file{/var/run/utmp} e \file{/var/log/wtmp} citati in precedenza.
 
-Una volta aperto il file del registro degli utenti si può eseguire una
+Una volta aperto il file del registro degli utenti si può eseguire una
 scansione leggendo o scrivendo una voce con le funzioni \funcd{getutent},
 \funcd{getutid}, \funcd{getutline} e \funcd{pututline}, i cui prototipi sono:
 \begin{functions}
@@ -1265,7 +1265,7 @@ scansione leggendo o scrivendo una voce con le funzioni \funcd{getutent},
 \end{functions}
 
 Tutte queste funzioni fanno riferimento ad una struttura di tipo
-\struct{utmp}, la cui definizione in Linux è riportata in
+\struct{utmp}, la cui definizione in Linux è riportata in
 fig.~\ref{fig:sys_utmp_struct}. Le prime tre funzioni servono per leggere una
 voce dal registro; \func{getutent} legge semplicemente la prima voce
 disponibile; le altre due permettono di eseguire una ricerca.
@@ -1279,17 +1279,17 @@ disponibile; le altre due permettono di eseguire una ricerca.
   \end{minipage} 
   \normalsize 
   \caption{La struttura \structd{utmp} contenente le informazioni di una voce
-    del registro di \textsl{contabilità}.}
+    del registro di \textsl{contabilità}.}
   \label{fig:sys_utmp_struct}
 \end{figure}
 
-Con \func{getutid} si può cercare una voce specifica, a seconda del valore del
-campo \var{ut\_type} dell'argomento \param{ut}.  Questo può assumere i valori
+Con \func{getutid} si può cercare una voce specifica, a seconda del valore del
+campo \var{ut\_type} dell'argomento \param{ut}.  Questo può assumere i valori
 riportati in tab.~\ref{tab:sys_ut_type}, quando assume i valori
 \const{RUN\_LVL}, \const{BOOT\_TIME}, \const{OLD\_TIME}, \const{NEW\_TIME},
-verrà restituito la prima voce che corrisponde al tipo determinato; quando
+verrà restituito la prima voce che corrisponde al tipo determinato; quando
 invece assume i valori \const{INIT\_PROCESS}, \const{LOGIN\_PROCESS},
-\const{USER\_PROCESS} o \const{DEAD\_PROCESS} verrà restituita la prima voce
+\const{USER\_PROCESS} o \const{DEAD\_PROCESS} verrà restituita la prima voce
 corrispondente al valore del campo \var{ut\_id} specificato in \param{ut}.
 
 \begin{table}[htb]
@@ -1303,9 +1303,9 @@ corrispondente al valore del campo \var{ut\_id} specificato in \param{ut}.
     \const{EMPTY}         & Non contiene informazioni valide.\\
     \const{RUN\_LVL}      & Identica il runlevel del sistema.\\
     \const{BOOT\_TIME}    & Identifica il tempo di avvio del sistema.\\
-    \const{OLD\_TIME}     & Identifica quando è stato modificato l'orologio di
+    \const{OLD\_TIME}     & Identifica quando è stato modificato l'orologio di
                             sistema.\\
-    \const{NEW\_TIME}     & Identifica da quanto è stato modificato il 
+    \const{NEW\_TIME}     & Identifica da quanto è stato modificato il 
                             sistema.\\
     \const{INIT\_PROCESS} & Identifica un processo lanciato da \cmd{init}.\\
     \const{LOGIN\_PROCESS}& Identifica un processo di login.\\
@@ -1323,11 +1323,11 @@ La funzione \func{getutline} esegue la ricerca sulle voci che hanno
 \var{ut\_type} uguale a \const{LOGIN\_PROCESS} o \const{USER\_PROCESS},
 restituendo la prima che corrisponde al valore di \var{ut\_line}, che
 specifica il device\footnote{espresso senza il \file{/dev/} iniziale.} di
-terminale che interessa. Lo stesso criterio di ricerca è usato da
+terminale che interessa. Lo stesso criterio di ricerca è usato da
 \func{pututline} per trovare uno spazio dove inserire la voce specificata,
 qualora non sia trovata la voce viene aggiunta in coda al registro.
 
-In generale occorre però tenere conto che queste funzioni non sono
+In generale occorre però tenere conto che queste funzioni non sono
 completamente standardizzate, e che in sistemi diversi possono esserci
 differenze; ad esempio \func{pututline} restituisce \code{void} in vari
 sistemi (compreso Linux, fino alle \acr{libc5}). Qui seguiremo la sintassi
@@ -1335,7 +1335,7 @@ fornita dalle \acr{glibc}, ma gli standard POSIX 1003.1-2001 e XPG4.2 hanno
 introdotto delle nuove strutture (e relativi file) di tipo \code{utmpx}, che
 sono un sovrainsieme di \code{utmp}. 
 
-Le \acr{glibc} utilizzano già una versione estesa di \code{utmp}, che rende
+Le \acr{glibc} utilizzano già una versione estesa di \code{utmp}, che rende
 inutili queste nuove strutture; pertanto esse e le relative funzioni di
 gestione (\func{getutxent}, \func{getutxid}, \func{getutxline},
 \func{pututxline}, \func{setutxent} e \func{endutxent}) sono ridefinite come
@@ -1377,7 +1377,7 @@ poi aggiunge chiamando \func{updwtmp}.
 
 
 Dopo aver esaminato le funzioni che permettono di controllare le varie
-caratteristiche, capacità e limiti del sistema a livello globale, in questa
+caratteristiche, capacità e limiti del sistema a livello globale, in questa
 sezione tratteremo le varie funzioni che vengono usate per quantificare le
 risorse (CPU, memoria, ecc.) utilizzate da ogni singolo processo e quelle che
 permettono di imporre a ciascuno di essi vincoli e limiti di
@@ -1388,9 +1388,9 @@ utilizzo.
 \label{sec:sys_resource_use}
 
 Come abbiamo accennato in sez.~\ref{sec:proc_wait} le informazioni riguardo
-l'utilizzo delle risorse da parte di un processo è mantenuto in una struttura
+l'utilizzo delle risorse da parte di un processo è mantenuto in una struttura
 di tipo \struct{rusage}, la cui definizione (che si trova in
-\file{sys/resource.h}) è riportata in fig.~\ref{fig:sys_rusage_struct}.
+\file{sys/resource.h}) è riportata in fig.~\ref{fig:sys_rusage_struct}.
 
 \begin{figure}[!htb]
   \footnotesize
@@ -1404,12 +1404,12 @@ di tipo \struct{rusage}, la cui definizione (che si trova in
   \label{fig:sys_rusage_struct}
 \end{figure}
 
-La definizione della struttura in fig.~\ref{fig:sys_rusage_struct} è ripresa
+La definizione della struttura in fig.~\ref{fig:sys_rusage_struct} è ripresa
 da BSD 4.3,\footnote{questo non ha a nulla a che fare con il cosiddetto
   \textit{BSD accounting} (vedi sez. \ref{sec:sys_bsd_accounting}) che si trova
-  nelle opzioni di compilazione del kernel (e di norma è disabilitato) che
-  serve per mantenere una contabilità delle risorse usate da ciascun processo
-  in maniera molto più dettagliata.} ma attualmente (con i kernel della serie
+  nelle opzioni di compilazione del kernel (e di norma è disabilitato) che
+  serve per mantenere una contabilità delle risorse usate da ciascun processo
+  in maniera molto più dettagliata.} ma attualmente (con i kernel della serie
 2.4.x e 2.6.x) i soli campi che sono mantenuti sono: \var{ru\_utime},
 \var{ru\_stime}, \var{ru\_minflt}, \var{ru\_majflt}, e \var{ru\_nswap}. I
 primi due indicano rispettivamente il tempo impiegato dal processo
@@ -1421,37 +1421,37 @@ virtuale\index{memoria~virtuale} e corrispondono rispettivamente al numero di
 \itindex{page~fault} \textit{page fault} (vedi sez.~\ref{sec:proc_mem_gen})
 avvenuti senza richiedere I/O su disco (i cosiddetti \textit{minor page
   fault}), a quelli che invece han richiesto I/O su disco (detti invece
-\textit{major page fault}) ed al numero di volte che il processo è stato
+\textit{major page fault}) ed al numero di volte che il processo è stato
 completamente tolto dalla memoria per essere inserito nello swap.
 
-In genere includere esplicitamente \file{<sys/time.h>} non è più strettamente
-necessario, ma aumenta la portabilità, e serve comunque quando, come nella
+In genere includere esplicitamente \file{<sys/time.h>} non è più strettamente
+necessario, ma aumenta la portabilità, e serve comunque quando, come nella
 maggior parte dei casi, si debba accedere ai campi di \struct{rusage} relativi
 ai tempi di utilizzo del processore, che sono definiti come strutture di tipo
 \struct{timeval} (vedi fig.~\ref{fig:sys_timeval_struct}).
 
-Questa è la stessa struttura utilizzata da \func{wait4} (si ricordi quando
-visto in sez.~\ref{sec:proc_wait}) per ricavare la quantità di risorse
-impiegate dal processo di cui si è letto lo stato di terminazione, ma essa può
+Questa è la stessa struttura utilizzata da \func{wait4} (si ricordi quando
+visto in sez.~\ref{sec:proc_wait}) per ricavare la quantità di risorse
+impiegate dal processo di cui si è letto lo stato di terminazione, ma essa può
 anche essere letta direttamente utilizzando la funzione \funcd{getrusage}, il
-cui prototipo è:
+cui prototipo è:
 \begin{functions}
   \headdecl{sys/time.h} 
   \headdecl{sys/resource.h} 
   \headdecl{unistd.h} 
   
   \funcdecl{int getrusage(int who, struct rusage *usage)} 
-  Legge la quantità di risorse usate da un processo.
+  Legge la quantità di risorse usate da un processo.
 
 
   \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
-  nel qual caso \var{errno} può essere \errval{EINVAL} o \errval{EFAULT}.}
+  nel qual caso \var{errno} può essere \errval{EINVAL} o \errval{EFAULT}.}
 \end{functions}
 
 L'argomento \param{who} permette di specificare il processo di cui si vuole
-leggere l'uso delle risorse; esso può assumere solo i due valori
+leggere l'uso delle risorse; esso può assumere solo i due valori
 \const{RUSAGE\_SELF} per indicare il processo corrente e
-\const{RUSAGE\_CHILDREN} per indicare l'insieme dei processi figli di cui si è
+\const{RUSAGE\_CHILDREN} per indicare l'insieme dei processi figli di cui si è
 ricevuto lo stato di terminazione. 
 
 % TODO previsto in futuro \const{RUSAGE\_THREAD}, verificare.
@@ -1460,18 +1460,18 @@ ricevuto lo stato di terminazione.
 \label{sec:sys_resource_limit}
 
 Come accennato nell'introduzione il kernel mette a disposizione delle
-funzionalità che permettono non solo di mantenere dati statistici relativi
+funzionalità che permettono non solo di mantenere dati statistici relativi
 all'uso delle risorse, ma anche di imporre dei limiti precisi sul loro
 utilizzo da parte dei vari processi o degli utenti.
 
 Per far questo esistono una serie di risorse e ad ogni processo vengono
 associati due diversi limiti per ciascuna di esse; questi sono il
 \textsl{limite corrente} (o \textit{current limit}) che esprime un valore
-massimo che il processo non può superare ad un certo momento, ed il
+massimo che il processo non può superare ad un certo momento, ed il
 \textsl{limite massimo} (o \textit{maximum limit}) che invece esprime il
-valore massimo che può assumere il \textsl{limite corrente}. In generale il
-primo viene chiamato anche \textit{soft limit} dato che il suo valore può
-essere aumentato dal processo stesso durante l'esecuzione, ciò può però essere
+valore massimo che può assumere il \textsl{limite corrente}. In generale il
+primo viene chiamato anche \textit{soft limit} dato che il suo valore può
+essere aumentato dal processo stesso durante l'esecuzione, ciò può però essere
 fatto solo fino al valore del secondo, che per questo viene detto \textit{hard
   limit}.
 
@@ -1491,21 +1491,21 @@ fatto solo fino al valore del secondo, che per questo viene detto \textit{hard
                               esse falliranno con un errore di
                               \errcode{ENOMEM}, mentre se il superamento viene
                               causato dalla crescita dello \itindex{stack}
-                              \textit{stack} il processo riceverà un segnale di
+                              \textit{stack} il processo riceverà un segnale di
                               \const{SIGSEGV}.\\  
     \const{RLIMIT\_CORE}   &  La massima dimensione per di un file di
                               \itindex{core~dump} \textit{core dump} (vedi
                               sez.~\ref{sec:sig_prog_error}) creato nella
                               terminazione di un processo; file di dimensioni 
                               maggiori verranno troncati a questo valore,
-                              mentre con un valore si bloccherà la creazione
+                              mentre con un valore si bloccherà la creazione
                               dei \itindex{core~dump} \textit{core dump}.\\ 
     \const{RLIMIT\_CPU}    &  Il massimo tempo di CPU (vedi
-                              sez.~\ref{sec:sys_cpu_times}) che il processo può
+                              sez.~\ref{sec:sys_cpu_times}) che il processo può
                               usare. Il superamento del limite corrente
                               comporta l'emissione di un segnale di
                               \const{SIGXCPU}, la cui azione predefinita (vedi
-                              sez.~\ref{sec:sig_classification}) è terminare
+                              sez.~\ref{sec:sig_classification}) è terminare
                               il processo, una volta al secondo fino al
                               raggiungimento del limite massimo. Il
                               superamento del limite massimo 
@@ -1514,26 +1514,26 @@ fatto solo fino al valore del secondo, che per questo viene detto \textit{hard
     \const{RLIMIT\_DATA}   &  La massima dimensione del \index{segmento!dati}
                               segmento dati di un 
                               processo (vedi sez.~\ref{sec:proc_mem_layout}).
-                              Il tentativo di allocare più memoria di quanto
+                              Il tentativo di allocare più memoria di quanto
                               indicato dal limite corrente causa il fallimento
                               della funzione di allocazione (\func{brk} o
                               \func{sbrk}) con un errore di \errcode{ENOMEM}.\\
     \const{RLIMIT\_FSIZE}  &  La massima dimensione di un file che un processo
-                              può creare. Se il processo cerca di scrivere
-                              oltre questa dimensione riceverà un segnale di
+                              può creare. Se il processo cerca di scrivere
+                              oltre questa dimensione riceverà un segnale di
                               \const{SIGXFSZ}, che di norma termina il
                               processo; se questo viene intercettato la
-                              system call che ha causato l'errore fallirà con
+                              system call che ha causato l'errore fallirà con
                               un errore di \errcode{EFBIG}.\\
-    \const{RLIMIT\_LOCKS}&    È un limite presente solo nelle prime versioni
+    \const{RLIMIT\_LOCKS}&    È un limite presente solo nelle prime versioni
                               del kernel 2.4 sul numero massimo di
                               \index{file!locking} \textit{file lock} (vedi
                               sez.~\ref{sec:file_locking}) che un
                               processo poteva effettuare.\\ 
-    \const{RLIMIT\_MEMLOCK}&  L'ammontare massimo di memoria che può essere
+    \const{RLIMIT\_MEMLOCK}&  L'ammontare massimo di memoria che può essere
                               bloccata in RAM da un processo (vedi
                               sez.~\ref{sec:proc_mem_lock}). Dal kernel 2.6.9
-                              questo limite comprende anche la memoria che può
+                              questo limite comprende anche la memoria che può
                               essere bloccata da ciascun utente nell'uso della
                               memoria condivisa (vedi
                               sez.~\ref{sec:ipc_sysv_shm}) che viene
@@ -1545,29 +1545,29 @@ fatto solo fino al valore del secondo, che per questo viene detto \textit{hard
 %    \const{RLIMIT\_RTPRIO}& Il numero massimo di \\
 % aggiungere i limiti che mancano come RLIMIT_RTTIME introdotto con il 2.6.25
 % vedi file include/asm-generic/resource.h
-    \const{RLIMIT\_NOFILE} &  Il numero massimo di file che il processo può
-                              aprire. L'apertura di un ulteriore file farà
+    \const{RLIMIT\_NOFILE} &  Il numero massimo di file che il processo può
+                              aprire. L'apertura di un ulteriore file farà
                               fallire la funzione (\func{open}, \func{dup} o
                               \func{pipe}) con un errore \errcode{EMFILE}.\\
     \const{RLIMIT\_NPROC}  &  Il numero massimo di processi che possono essere
                               creati sullo stesso user id real. Se il limite
-                              viene raggiunto \func{fork} fallirà con un
+                              viene raggiunto \func{fork} fallirà con un
                               \errcode{EAGAIN}.\\
     \const{RLIMIT\_SIGPENDING}& Il numero massimo di segnali che possono
                               essere mantenuti in coda per ciascun utente,
                               considerando sia i segnali normali che real-time
-                              (vedi sez.~\ref{sec:sig_real_time}). Il limite è
+                              (vedi sez.~\ref{sec:sig_real_time}). Il limite è
                               attivo solo per \func{sigqueue}, con \func{kill}
-                              si potrà sempre inviare un segnale che non sia
-                              già presente su una coda.\footnotemark\\
+                              si potrà sempre inviare un segnale che non sia
+                              già presente su una coda.\footnotemark\\
     \const{RLIMIT\_STACK}  &  La massima dimensione dello \itindex{stack}
                               \textit{stack} del processo. Se il processo
                               esegue operazioni che estendano lo
                               \textit{stack} oltre questa dimensione 
-                              riceverà un segnale di \const{SIGSEGV}.\\
+                              riceverà un segnale di \const{SIGSEGV}.\\
     \const{RLIMIT\_RSS}    &  L'ammontare massimo di pagine di memoria dato al
                               \index{segmento!testo} testo del processo. Il
-                              limite è solo una indicazione per il kernel,
+                              limite è solo una indicazione per il kernel,
                               qualora ci fosse un surplus di memoria questa
                               verrebbe assegnata.\\ 
 % TODO integrare con la roba di madvise
@@ -1579,13 +1579,13 @@ fatto solo fino al valore del secondo, che per questo viene detto \textit{hard
   \label{tab:sys_rlimit_values}
 \end{table}
 
-\footnotetext[18]{questo è quanto avviene per i kernel dalla serie 2.2 fino ad
+\footnotetext[18]{questo è quanto avviene per i kernel dalla serie 2.2 fino ad
   oggi (la 2.6.x); altri kernel possono avere comportamenti diversi per quanto
-  avviene quando viene superato il \textit{soft limit}; perciò per avere
-  operazioni portabili è sempre opportuno intercettare il primo
+  avviene quando viene superato il \textit{soft limit}; perciò per avere
+  operazioni portabili è sempre opportuno intercettare il primo
   \const{SIGXCPU} e terminare in maniera ordinata il processo.}
 
-\footnotetext{il limite su questa risorsa è stato introdotto con il kernel
+\footnotetext{il limite su questa risorsa è stato introdotto con il kernel
   2.6.8.}
 
 % TODO trattare prlimit64 introdotta con il 2.6.36 che dovrebbe sostituire
@@ -1597,7 +1597,7 @@ In generale il superamento di un limite corrente\footnote{di norma quanto
   avviene al superamento del limite corrente, con l'eccezione
   \const{RLIMIT\_CPU} in cui si ha in comportamento diverso per il superamento
   dei due limiti.}  comporta o l'emissione di un segnale o il fallimento della
-system call che lo ha provocato;\footnote{si nuovo c'è una eccezione per
+system call che lo ha provocato;\footnote{si nuovo c'è una eccezione per
   \const{RLIMIT\_CORE} che influenza soltanto la dimensione (o l'eventuale
   creazione) dei file di \itindex{core~dump} \textit{core dump}.} per
 permettere di leggere e di impostare i limiti di utilizzo delle risorse da
@@ -1617,7 +1617,7 @@ parte di un processo sono previste due funzioni, \funcd{getrlimit} e
   Imposta il limite per la risorsa \param{resource}.
   
   \bodydesc{Le funzioni ritornano 0 in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] i valori per \param{resource} non sono validi.
     \item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
@@ -1632,7 +1632,7 @@ Entrambe le funzioni permettono di specificare, attraverso l'argomento
 questo argomento sono elencati in tab.~\ref{tab:sys_rlimit_values}. L'acceso
 (rispettivamente in lettura e scrittura) ai valori effettivi dei limiti viene
 poi effettuato attraverso la struttura \struct{rlimit} puntata da
-\param{rlim}, la cui definizione è riportata in
+\param{rlim}, la cui definizione è riportata in
 fig.~\ref{fig:sys_rlimit_struct}, ed i cui campi corrispondono appunto a
 limite corrente e limite massimo.
 
@@ -1650,12 +1650,12 @@ limite corrente e limite massimo.
 \end{figure}
 
 
-Nello specificare un limite, oltre a fornire dei valori specifici, si può
+Nello specificare un limite, oltre a fornire dei valori specifici, si può
 anche usare la costante \const{RLIM\_INFINITY} che permette di sbloccare l'uso
 di una risorsa; ma si ricordi che solo un processo con i privilegi di
-amministratore\footnote{per essere precisi in questo caso quello che serve è
+amministratore\footnote{per essere precisi in questo caso quello che serve è
   la \itindex{capabilities} \textit{capability} \const{CAP\_SYS\_RESOURCE}
-  (vedi sez.~\ref{sec:proc_capabilities}).}  può innalzare un limite al di
+  (vedi sez.~\ref{sec:proc_capabilities}).}  può innalzare un limite al di
 sopra del valore corrente del limite massimo ed usare un valore qualsiasi per
 entrambi i limiti. Si tenga conto infine che tutti i limiti vengono ereditati
 dal processo padre attraverso una \func{fork} (vedi sez.~\ref{sec:proc_fork})
@@ -1666,31 +1666,31 @@ sez.~\ref{sec:proc_exec}).
 \subsection{Le risorse di memoria e processore}
 \label{sec:sys_memory_res}
 
-La gestione della memoria è già stata affrontata in dettaglio in
+La gestione della memoria è già stata affrontata in dettaglio in
 sez.~\ref{sec:proc_memory}; abbiamo visto allora che il kernel provvede il
 meccanismo della \index{memoria~virtuale} memoria virtuale attraverso la
 divisione della memoria fisica in pagine.
 
-In genere tutto ciò è del tutto trasparente al singolo processo, ma in certi
+In genere tutto ciò è del tutto trasparente al singolo processo, ma in certi
 casi, come per l'I/O mappato in memoria (vedi sez.~\ref{sec:file_memory_map})
-che usa lo stesso meccanismo per accedere ai file, è necessario conoscere le
+che usa lo stesso meccanismo per accedere ai file, è necessario conoscere le
 dimensioni delle pagine usate dal kernel. Lo stesso vale quando si vuole
 gestire in maniera ottimale l'interazione della memoria che si sta allocando
 con il meccanismo della \index{paginazione} paginazione.
 
-Di solito la dimensione delle pagine di memoria è fissata dall'architettura
+Di solito la dimensione delle pagine di memoria è fissata dall'architettura
 hardware, per cui il suo valore di norma veniva mantenuto in una costante che
 bastava utilizzare in fase di compilazione, ma oggi, con la presenza di alcune
 architetture (ad esempio Sun Sparc) che permettono di variare questa
 dimensione, per non dover ricompilare i programmi per ogni possibile modello e
-scelta di dimensioni, è necessario poter utilizzare una funzione.
+scelta di dimensioni, è necessario poter utilizzare una funzione.
 
 Dato che si tratta di una caratteristica generale del sistema, questa
-dimensione può essere ottenuta come tutte le altre attraverso una chiamata a
+dimensione può essere ottenuta come tutte le altre attraverso una chiamata a
 \func{sysconf}, \footnote{nel caso specifico si dovrebbe utilizzare il
-  parametro \const{\_SC\_PAGESIZE}.}  ma in BSD 4.2 è stata introdotta una
+  parametro \const{\_SC\_PAGESIZE}.}  ma in BSD 4.2 è stata introdotta una
 apposita funzione, \funcd{getpagesize}, che restituisce la dimensione delle
-pagine di memoria; il suo prototipo è:
+pagine di memoria; il suo prototipo è:
 \begin{prototype}{unistd.h}{int getpagesize(void)}
   Legge le dimensioni delle pagine di memoria.
   
@@ -1698,10 +1698,10 @@ pagine di memoria; il suo prototipo 
     sono previsti errori.}
 \end{prototype}
 
-La funzione è prevista in SVr4, BSD 4.4 e SUSv2, anche se questo ultimo
+La funzione è prevista in SVr4, BSD 4.4 e SUSv2, anche se questo ultimo
 standard la etichetta come obsoleta, mentre lo standard POSIX 1003.1-2001 la
-ha eliminata. In Linux è implementata come una system call nelle architetture
-in cui essa è necessaria, ed in genere restituisce il valore del simbolo
+ha eliminata. In Linux è implementata come una system call nelle architetture
+in cui essa è necessaria, ed in genere restituisce il valore del simbolo
 \const{PAGE\_SIZE} del kernel, che dipende dalla architettura hardware, anche
 se le versioni delle librerie del C precedenti le \acr{glibc} 2.1
 implementavano questa funzione restituendo sempre un valore statico.
@@ -1738,9 +1738,9 @@ attivi); anche queste sono informazioni comunque ottenibili attraverso
 \const{\_SC\_NPROCESSORS\_CONF} e \const{\_SC\_NPROCESSORS\_ONLN}.
 
 Infine le \acr{glibc} riprendono da BSD la funzione \funcd{getloadavg} che
-permette di ottenere il carico di processore della macchina, in questo modo è
+permette di ottenere il carico di processore della macchina, in questo modo è
 possibile prendere decisioni su quando far partire eventuali nuovi processi.
-Il suo prototipo è:
+Il suo prototipo è:
 \begin{prototype}{stdlib.h}{int getloadavg(double loadavg[], int nelem)}
   Legge il carico medio della macchina.
   
@@ -1751,31 +1751,31 @@ Il suo prototipo 
 La funzione restituisce in ciascun elemento di \param{loadavg} il numero medio
 di processi attivi sulla coda dello \itindex{scheduler} scheduler, calcolato
 su diversi intervalli di tempo.  Il numero di intervalli che si vogliono
-leggere è specificato da \param{nelem}, dato che nel caso di Linux il carico
+leggere è specificato da \param{nelem}, dato che nel caso di Linux il carico
 viene valutato solo su tre intervalli (corrispondenti a 1, 5 e 15 minuti),
-questo è anche il massimo valore che può essere assegnato a questo argomento.
+questo è anche il massimo valore che può essere assegnato a questo argomento.
 
 
-\subsection{La \textsl{contabilità} in stile BSD}
+\subsection{La \textsl{contabilità} in stile BSD}
 \label{sec:sys_bsd_accounting}
 
-Una ultima modalità per monitorare l'uso delle risorse è, se si è compilato il
-kernel con il relativo supporto,\footnote{se cioè si è abilitata l'opzione di
+Una ultima modalità per monitorare l'uso delle risorse è, se si è compilato il
+kernel con il relativo supporto,\footnote{se cioè si è abilitata l'opzione di
   compilazione \texttt{CONFIG\_BSD\_PROCESS\_ACCT}.} quella di attivare il
 cosiddetto \textit{BSD accounting}, che consente di registrare su file una
 serie di informazioni\footnote{contenute nella struttura \texttt{acct}
   definita nel file \texttt{include/linux/acct.h} dei sorgenti del kernel.}
-riguardo alla \textsl{contabilità} delle risorse utilizzate da ogni processo
+riguardo alla \textsl{contabilità} delle risorse utilizzate da ogni processo
 che viene terminato.
 
-Linux consente di salvare la contabilità delle informazioni relative alle
+Linux consente di salvare la contabilità delle informazioni relative alle
 risorse utilizzate dai processi grazie alla funzione \funcd{acct}, il cui
-prototipo è:
+prototipo è:
 \begin{prototype}{unistd.h}{int acct(const char *filename)}
   Abilita il \textit{BSD accounting}.
   
   \bodydesc{La funzione ritorna 0 in caso di successo o $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
     \begin{errlist}
     \item[\errcode{EACCESS}] non si hanno i permessi per accedere a
       \param{pathname}.
@@ -1783,7 +1783,7 @@ prototipo 
       abilitare il \textit{BSD accounting}.
     \item[\errcode{ENOSYS}] il kernel non supporta il \textit{BSD accounting}.
     \item[\errcode{EUSER}] non sono disponibili nel kernel strutture per il
-      file o si è finita la memoria.
+      file o si è finita la memoria.
     \end{errlist}
     ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
     \errval{ENAMETOOLONG}, \errval{ENFILE}, \errval{ENOENT}, \errval{ENOMEM},
@@ -1792,15 +1792,15 @@ prototipo 
 
 La funzione attiva il salvataggio dei dati sul file indicato dal pathname
 contenuti nella stringa puntata da \param{filename}; la funzione richiede che
-il processo abbia i privilegi di amministratore (è necessaria la
+il processo abbia i privilegi di amministratore (è necessaria la
 \itindex{capabilities} capability \const{CAP\_SYS\_PACCT}, vedi
 sez.~\ref{sec:proc_capabilities}). Se si specifica il valore \const{NULL} per
 \param{filename} il \textit{BSD accounting} viene invece disabilitato. Un
-semplice esempio per l'uso di questa funzione è riportato nel programma
+semplice esempio per l'uso di questa funzione è riportato nel programma
 \texttt{AcctCtrl.c} dei sorgenti allegati alla guida.
 
-Quando si attiva la contabilità, il file che si indica deve esistere; esso
-verrà aperto in sola scrittura;\footnote{si applicano al pathname indicato da
+Quando si attiva la contabilità, il file che si indica deve esistere; esso
+verrà aperto in sola scrittura;\footnote{si applicano al pathname indicato da
   \param{filename} tutte le restrizioni viste in cap.~\ref{cha:file_intro}.}
 le informazioni verranno registrate in \itindex{append~mode} \textit{append}
 in coda al file tutte le volte che un processo termina. Le informazioni
@@ -1843,14 +1843,14 @@ rispettivamente chiamati \itindex{calendar~time} \textit{calendar time} e
 \itindex{process~time} \textit{process time}, secondo le definizioni:
 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
 \item[\textit{calendar time}] \itindex{calendar~time} detto anche
-  \textsl{tempo di calendario}. È il numero di secondi dalla mezzanotte del
+  \textsl{tempo di calendario}. È il numero di secondi dalla mezzanotte del
   primo gennaio 1970, in tempo universale coordinato (o UTC), data che viene
   usualmente indicata con 00:00:00 Jan, 1 1970 (UTC) e chiamata \textit{the
     Epoch}. Questo tempo viene anche chiamato anche GMT (Greenwich Mean Time)
-  dato che l'UTC corrisponde all'ora locale di Greenwich.  È il tempo su cui
+  dato che l'UTC corrisponde all'ora locale di Greenwich.  È il tempo su cui
   viene mantenuto l'orologio del kernel, e viene usato ad esempio per indicare
   le date di modifica dei file o quelle di avvio dei processi. Per memorizzare
-  questo tempo è stato riservato il tipo primitivo \type{time\_t}.
+  questo tempo è stato riservato il tipo primitivo \type{time\_t}.
 \item[\textit{process time}] \itindex{process~time} detto talvolta
   \textsl{tempo di processore}.  Viene misurato in \itindex{clock~tick}
   \textit{clock tick}. Un tempo questo corrispondeva al numero di interruzioni
@@ -1858,12 +1858,12 @@ rispettivamente chiamati \itindex{calendar~time} \textit{calendar time} e
   sia pari al valore della costante \const{CLOCKS\_PER\_SEC}, che deve essere
   definita come 1000000, qualunque sia la risoluzione reale dell'orologio di
   sistema e la frequenza delle interruzioni del timer.\footnote{quest'ultima,
-    come accennato in sez.~\ref{sec:proc_hierarchy}, è invece data dalla
-    costante \const{HZ}.}  Il dato primitivo usato per questo tempo è
+    come accennato in sez.~\ref{sec:proc_hierarchy}, è invece data dalla
+    costante \const{HZ}.}  Il dato primitivo usato per questo tempo è
   \type{clock\_t}, che ha quindi una risoluzione del microsecondo. Il numero
-  di \itindex{clock~tick} \textit{tick} al secondo può essere ricavato anche
+  di \itindex{clock~tick} \textit{tick} al secondo può essere ricavato anche
   attraverso \func{sysconf} (vedi sez.~\ref{sec:sys_sysconf}).  Il vecchio
-  simbolo \const{CLK\_TCK} definito in \file{time.h} è ormai considerato
+  simbolo \const{CLK\_TCK} definito in \file{time.h} è ormai considerato
   obsoleto.
 \end{basedescript}
 
@@ -1875,12 +1875,12 @@ demoni che compiono lavori amministrativi ad ore definite, come \cmd{cron}.
 Di solito questo tempo viene convertito automaticamente dal valore in UTC al
 tempo locale, utilizzando le opportune informazioni di localizzazione
 (specificate in \conffile{/etc/timezone}). E da tenere presente che questo
-tempo è mantenuto dal sistema e non è detto che corrisponda al tempo tenuto
+tempo è mantenuto dal sistema e non è detto che corrisponda al tempo tenuto
 dall'orologio hardware del calcolatore.
 
 Anche il \itindex{process~time} \textit{process time} di solito si esprime in
 secondi, ma fornisce una precisione ovviamente superiore al \textit{calendar
-  time} (che è mantenuto dal sistema con una granularità di un secondo) e
+  time} (che è mantenuto dal sistema con una granularità di un secondo) e
 viene usato per tenere conto dei tempi di esecuzione dei processi. Per ciascun
 processo il kernel calcola tre tempi diversi:
 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
@@ -1890,12 +1890,12 @@ processo il kernel calcola tre tempi diversi:
   quanti altri processi stavano girando nello stesso periodo.
   
 \item[\textit{user time}] il tempo effettivo che il processore ha impiegato
-  nell'esecuzione delle istruzioni del processo in user space. È quello
+  nell'esecuzione delle istruzioni del processo in user space. È quello
   riportato nella risorsa \var{ru\_utime} di \struct{rusage} vista in
   sez.~\ref{sec:sys_resource_use}.
   
 \item[\textit{system time}] il tempo effettivo che il processore ha impiegato
-  per eseguire codice delle system call nel kernel per conto del processo.  È
+  per eseguire codice delle system call nel kernel per conto del processo.  È
   quello riportato nella risorsa \var{ru\_stime} di \struct{rusage} vista in
   sez.~\ref{sec:sys_resource_use}.
 \end{basedescript}
@@ -1903,7 +1903,7 @@ processo il kernel calcola tre tempi diversi:
 In genere la somma di \textit{user time} e \textit{system time} indica il
 tempo di processore totale che il sistema ha effettivamente utilizzato per
 eseguire un certo processo, questo viene chiamato anche \textit{CPU time} o
-\textsl{tempo di CPU}. Si può ottenere un riassunto dei valori di questi tempi
+\textsl{tempo di CPU}. Si può ottenere un riassunto dei valori di questi tempi
 quando si esegue un qualsiasi programma lanciando quest'ultimo come argomento
 del comando \cmd{time}.
 
@@ -1916,15 +1916,15 @@ del comando \cmd{time}.
 
 Di norma tutte le operazioni del sistema fanno sempre riferimento al
 \itindex{calendar~time} \textit{calendar time}, l'uso del \textit{process
-  time} è riservato a quei casi in cui serve conoscere i tempi di esecuzione
+  time} è riservato a quei casi in cui serve conoscere i tempi di esecuzione
 di un processo (ad esempio per valutarne l'efficienza). In tal caso infatti
-fare ricorso al \textit{calendar time} è inutile in quanto il tempo può essere
+fare ricorso al \textit{calendar time} è inutile in quanto il tempo può essere
 trascorso mentre un altro processo era in esecuzione o in attesa del risultato
 di una operazione di I/O.
 
-La funzione più semplice per leggere il \textit{process time} di un processo è
+La funzione più semplice per leggere il \textit{process time} di un processo è
 \funcd{clock}, che da una valutazione approssimativa del tempo di CPU
-utilizzato dallo stesso; il suo prototipo è:
+utilizzato dallo stesso; il suo prototipo è:
 \begin{prototype}{time.h}{clock\_t clock(void)}
   Legge il valore corrente del tempo di CPU.
   
@@ -1939,12 +1939,12 @@ costante \const{CLOCKS\_PER\_SEC}.\footnote{le \acr{glibc} seguono lo standard
   1000000 indipendentemente dalla risoluzione del timer di sistema.} In genere
 \type{clock\_t} viene rappresentato come intero a 32 bit, il che comporta un
 valore massimo corrispondente a circa 72 minuti, dopo i quali il contatore
-riprenderà lo stesso valore iniziale.
+riprenderà lo stesso valore iniziale.
 
-Come accennato in sez.~\ref{sec:sys_unix_time} il tempo di CPU è la somma di
+Come accennato in sez.~\ref{sec:sys_unix_time} il tempo di CPU è la somma di
 altri due tempi, l'\textit{user time} ed il \textit{system time} che sono
 quelli effettivamente mantenuti dal kernel per ciascun processo. Questi
-possono essere letti attraverso la funzione \funcd{times}, il cui prototipo è:
+possono essere letti attraverso la funzione \funcd{times}, il cui prototipo è:
 \begin{prototype}{sys/times.h}{clock\_t times(struct tms *buf)}
   Legge in \param{buf} il valore corrente dei tempi di processore.
   
@@ -1954,10 +1954,10 @@ possono essere letti attraverso la funzione \funcd{times}, il cui prototipo 
 \end{prototype}
 
 La funzione restituisce i valori di \textit{process time} del processo
-corrente in una struttura di tipo \struct{tms}, la cui definizione è riportata
+corrente in una struttura di tipo \struct{tms}, la cui definizione è riportata
 in fig.~\ref{fig:sys_tms_struct}. La struttura prevede quattro campi; i primi
 due, \var{tms\_utime} e \var{tms\_stime}, sono l'\textit{user time} ed il
-\textit{system time} del processo, così come definiti in
+\textit{system time} del processo, così come definiti in
 sez.~\ref{sec:sys_unix_time}.
 
 \begin{figure}[!htb]
@@ -1974,12 +1974,12 @@ sez.~\ref{sec:sys_unix_time}.
 
 Gli altri due campi mantengono rispettivamente la somma dell'\textit{user
   time} ed del \textit{system time} di tutti i processi figli che sono
-terminati; il kernel cioè somma in \var{tms\_cutime} il valore di
-\var{tms\_utime} e \var{tms\_cutime} per ciascun figlio del quale è stato
+terminati; il kernel cioè somma in \var{tms\_cutime} il valore di
+\var{tms\_utime} e \var{tms\_cutime} per ciascun figlio del quale è stato
 ricevuto lo stato di terminazione, e lo stesso vale per \var{tms\_cstime}.
 
 Si tenga conto che l'aggiornamento di \var{tms\_cutime} e \var{tms\_cstime}
-viene eseguito solo quando una chiamata a \func{wait} o \func{waitpid} è
+viene eseguito solo quando una chiamata a \func{wait} o \func{waitpid} è
 ritornata. Per questo motivo se un processo figlio termina prima di ricevere
 lo stato di terminazione di tutti i suoi figli, questi processi
 ``\textsl{nipoti}'' non verranno considerati nel calcolo di questi tempi.
@@ -1992,44 +1992,44 @@ lo stato di terminazione di tutti i suoi figli, questi processi
 
 \itindbeg{calendar~time}
 
-Come anticipato in sez.~\ref{sec:sys_unix_time} il \textit{calendar time} è
+Come anticipato in sez.~\ref{sec:sys_unix_time} il \textit{calendar time} è
 mantenuto dal kernel in una variabile di tipo \type{time\_t},\footnote{in
-  realtà il kernel usa una rappresentazione interna di che fornisce una
+  realtà il kernel usa una rappresentazione interna di che fornisce una
   precisione molto maggiore, e consente per questo anche di usare
   rappresentazioni diverse del \textit{calendar time}.} che usualmente
-corrisponde ad un tipo elementare (in Linux è definito come \ctyp{long int},
+corrisponde ad un tipo elementare (in Linux è definito come \ctyp{long int},
 che di norma corrisponde a 32 bit).  Il valore corrente del \textit{calendar
-  time}, che indicheremo come \textsl{tempo di sistema}, può essere ottenuto
+  time}, che indicheremo come \textsl{tempo di sistema}, può essere ottenuto
 con la funzione \funcd{time} che lo restituisce nel suddetto formato; il suo
-prototipo è:
+prototipo è:
 \begin{prototype}{time.h}{time\_t time(time\_t *t)}
   Legge il valore corrente del \textit{calendar time}.
   
   \bodydesc{La funzione ritorna il valore del \textit{calendar time} in caso
-    di successo e -1 in caso di errore, che può essere solo \errval{EFAULT}.}
+    di successo e -1 in caso di errore, che può essere solo \errval{EFAULT}.}
 \end{prototype}
 \noindent dove \param{t}, se non nullo, deve essere  l'indirizzo di una
 variabile su cui duplicare il valore di ritorno.
 
-Analoga a \func{time} è la funzione \funcd{stime} che serve per effettuare
-l'operazione inversa, e cioè per impostare il tempo di sistema qualora questo
-sia necessario; il suo prototipo è:
+Analoga a \func{time} è la funzione \funcd{stime} che serve per effettuare
+l'operazione inversa, e cioè per impostare il tempo di sistema qualora questo
+sia necessario; il suo prototipo è:
 \begin{prototype}{time.h}{int stime(time\_t *t)}
   Imposta a \param{t} il valore corrente del \textit{calendar time}.
   
   \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
-    che può essere \errval{EFAULT} o \errval{EPERM}.}
+    che può essere \errval{EFAULT} o \errval{EPERM}.}
 \end{prototype}
 \noindent dato che modificare l'ora ha un impatto su tutto il sistema 
-il cambiamento dell'orologio è una operazione privilegiata e questa funzione
-può essere usata solo da un processo con i privilegi di amministratore,
-altrimenti la chiamata fallirà con un errore di \errcode{EPERM}.
+il cambiamento dell'orologio è una operazione privilegiata e questa funzione
+può essere usata solo da un processo con i privilegi di amministratore,
+altrimenti la chiamata fallirà con un errore di \errcode{EPERM}.
 
 Data la scarsa precisione nell'uso di \type{time\_t} (che ha una risoluzione
 massima di un secondo) quando si devono effettuare operazioni sui tempi di
-norma l'uso delle funzioni precedenti è sconsigliato, ed esse sono di solito
+norma l'uso delle funzioni precedenti è sconsigliato, ed esse sono di solito
 sostituite da \funcd{gettimeofday} e \funcd{settimeofday},\footnote{le due
-  funzioni \func{time} e \func{stime} sono più antiche e derivano da SVr4,
+  funzioni \func{time} e \func{stime} sono più antiche e derivano da SVr4,
   \func{gettimeofday} e \func{settimeofday} sono state introdotte da BSD, ed
   in BSD4.3 sono indicate come sostitute delle precedenti.} i cui prototipi
 sono:
@@ -2047,58 +2047,58 @@ sono:
   Imposta il tempo di sistema.
   
   \bodydesc{Entrambe le funzioni restituiscono 0 in caso di successo e -1 in
-    caso di errore, nel qual caso \var{errno} può assumere i valori
+    caso di errore, nel qual caso \var{errno} può assumere i valori
     \errval{EINVAL} \errval{EFAULT} e per \func{settimeofday} anche
     \errval{EPERM}.}
 \end{functions}
 
 Si noti come queste funzioni utilizzino per indicare il tempo una struttura di
-tipo \struct{timeval}, la cui definizione si è già vista in
+tipo \struct{timeval}, la cui definizione si è già vista in
 fig.~\ref{fig:sys_timeval_struct}, questa infatti permette una espressione
 alternativa dei valori del \textit{calendar time}, con una precisione,
-rispetto a \type{time\_t}, fino al microsecondo.\footnote{la precisione è solo
+rispetto a \type{time\_t}, fino al microsecondo.\footnote{la precisione è solo
   teorica, la precisione reale della misura del tempo dell'orologio di sistema
   non dipende dall'uso di queste strutture.}
 
 Come nel caso di \func{stime} anche \func{settimeofday} (la cosa continua a
 valere per qualunque funzione che vada a modificare l'orologio di sistema,
-quindi anche per quelle che tratteremo in seguito) può essere utilizzata solo
-da un processo coi privilegi di amministratore.\footnote{più precisamente la
+quindi anche per quelle che tratteremo in seguito) può essere utilizzata solo
+da un processo coi privilegi di amministratore.\footnote{più precisamente la
   capabitity \const{CAP\_SYS\_TIME}.}
 
-Il secondo argomento di entrambe le funzioni è una struttura
+Il secondo argomento di entrambe le funzioni è una struttura
 \struct{timezone}, che storicamente veniva utilizzata per specificare appunto
-la \textit{time zone}, cioè l'insieme del fuso orario e delle convenzioni per
+la \textit{time zone}, cioè l'insieme del fuso orario e delle convenzioni per
 l'ora legale che permettevano il passaggio dal tempo universale all'ora
-locale. Questo argomento oggi è obsoleto ed in Linux non è mai stato
-utilizzato; esso non è supportato né dalle vecchie \textsl{libc5}, né dalle
+locale. Questo argomento oggi è obsoleto ed in Linux non è mai stato
+utilizzato; esso non è supportato né dalle vecchie \textsl{libc5}, né dalle
 \textsl{glibc}: pertanto quando si chiama questa funzione deve essere sempre
 impostato a \val{NULL}.
 
-Modificare l'orologio di sistema con queste funzioni è comunque problematico,
-in quanto esse effettuano un cambiamento immediato. Questo può creare dei
+Modificare l'orologio di sistema con queste funzioni è comunque problematico,
+in quanto esse effettuano un cambiamento immediato. Questo può creare dei
 buchi o delle ripetizioni nello scorrere dell'orologio di sistema, con
 conseguenze indesiderate.  Ad esempio se si porta avanti l'orologio si possono
-perdere delle esecuzioni di \cmd{cron} programmate nell'intervallo che si è
+perdere delle esecuzioni di \cmd{cron} programmate nell'intervallo che si è
 saltato. Oppure se si porta indietro l'orologio si possono eseguire due volte
 delle operazioni previste nell'intervallo di tempo che viene ripetuto. 
 
-Per questo motivo la modalità più corretta per impostare l'ora è quella di
-usare la funzione \funcd{adjtime}, il cui prototipo è:
+Per questo motivo la modalità più corretta per impostare l'ora è quella di
+usare la funzione \funcd{adjtime}, il cui prototipo è:
 \begin{prototype}{sys/time.h}
 {int adjtime(const struct timeval *delta, struct timeval *olddelta)} 
   
   Aggiusta del valore \param{delta} l'orologio di sistema.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    errore, nel qual caso \var{errno} assumerà il valore \errcode{EPERM}.}
+    errore, nel qual caso \var{errno} assumerà il valore \errcode{EPERM}.}
 \end{prototype}
 
 Questa funzione permette di avere un aggiustamento graduale del tempo di
 sistema in modo che esso sia sempre crescente in maniera monotona. Il valore
-di \param{delta} esprime il valore di cui si vuole spostare l'orologio; se è
-positivo l'orologio sarà accelerato per un certo tempo in modo da guadagnare
-il tempo richiesto, altrimenti sarà rallentato. Il secondo argomento viene
+di \param{delta} esprime il valore di cui si vuole spostare l'orologio; se è
+positivo l'orologio sarà accelerato per un certo tempo in modo da guadagnare
+il tempo richiesto, altrimenti sarà rallentato. Il secondo argomento viene
 usato, se non nullo, per ricevere il valore dell'ultimo aggiustamento
 effettuato.
 
@@ -2114,10 +2114,10 @@ effettuato.
   \label{fig:sys_timex_struct}
 \end{figure}
 
-Linux poi prevede un'altra funzione, che consente un aggiustamento molto più
+Linux poi prevede un'altra funzione, che consente un aggiustamento molto più
 dettagliato del tempo, permettendo ad esempio anche di modificare anche la
-velocità dell'orologio di sistema.  La funzione è \funcd{adjtimex} ed il suo
-prototipo è:
+velocità dell'orologio di sistema.  La funzione è \funcd{adjtimex} ed il suo
+prototipo è:
 \begin{prototype}{sys/timex.h}
 {int adjtimex(struct timex *buf)} 
   
@@ -2125,11 +2125,11 @@ prototipo 
   
   \bodydesc{La funzione restituisce lo stato dell'orologio (un valore $>0$) in
     caso di successo e -1 in caso di errore, nel qual caso \var{errno}
-    assumerà i valori \errval{EFAULT}, \errval{EINVAL} ed \errval{EPERM}.}
+    assumerà i valori \errval{EFAULT}, \errval{EINVAL} ed \errval{EPERM}.}
 \end{prototype}
 
 La funzione richiede una struttura di tipo \struct{timex}, la cui definizione,
-così come effettuata in \file{sys/timex.h}, è riportata in
+così come effettuata in \file{sys/timex.h}, è riportata in
 fig.~\ref{fig:sys_timex_struct}. L'azione della funzione dipende dal valore del
 campo \var{mode}, che specifica quale parametro dell'orologio di sistema,
 specificato in un opportuno campo di \struct{timex}, deve essere impostato. Un
@@ -2138,14 +2138,14 @@ devono essere specificati come OR binario delle costanti riportate in
 tab.~\ref{tab:sys_timex_mode}.
 
 La funzione utilizza il meccanismo di David L. Mills, descritto
-nell'\href{http://www.ietf.org/rfc/rfc1305.txt}{RFC~1305}, che è alla base del
-protocollo NTP. La funzione è specifica di Linux e non deve essere usata se la
-portabilità è un requisito, le \acr{glibc} provvedono anche un suo omonimo
+nell'\href{http://www.ietf.org/rfc/rfc1305.txt}{RFC~1305}, che è alla base del
+protocollo NTP. La funzione è specifica di Linux e non deve essere usata se la
+portabilità è un requisito, le \acr{glibc} provvedono anche un suo omonimo
 \func{ntp\_adjtime}.  La trattazione completa di questa funzione necessita di
 una lettura approfondita del meccanismo descritto nell'RFC~1305, ci limitiamo
 a descrivere in tab.~\ref{tab:sys_timex_mode} i principali valori utilizzabili
-per il campo \var{mode}, un elenco più dettagliato del significato dei vari
-campi della struttura \struct{timex} può essere ritrovato in \cite{glibc}.
+per il campo \var{mode}, un elenco più dettagliato del significato dei vari
+campi della struttura \struct{timex} può essere ritrovato in \cite{glibc}.
 
 \begin{table}[!htb]
   \footnotesize
@@ -2198,7 +2198,7 @@ campi della struttura \struct{timex} pu
   \label{tab:sys_timex_mode}
 \end{table}
 
-Il valore delle costanti per \var{mode} può essere anche espresso, secondo la
+Il valore delle costanti per \var{mode} può essere anche espresso, secondo la
 sintassi specificata per la forma equivalente di questa funzione definita come
 \func{ntp\_adjtime}, utilizzando il prefisso \code{MOD} al posto di
 \code{ADJ}.
@@ -2211,12 +2211,12 @@ sintassi specificata per la forma equivalente di questa funzione definita come
     \textbf{Nome} & \textbf{Valore} & \textbf{Significato}\\
     \hline
     \hline
-    \const{TIME\_OK}   & 0 & L'orologio è sincronizzato.\\ 
+    \const{TIME\_OK}   & 0 & L'orologio è sincronizzato.\\ 
     \const{TIME\_INS}  & 1 & Insert leap second.\\ 
     \const{TIME\_DEL}  & 2 & Delete leap second.\\ 
     \const{TIME\_OOP}  & 3 & Leap second in progress.\\ 
     \const{TIME\_WAIT} & 4 & Leap second has occurred.\\ 
-    \const{TIME\_BAD}  & 5 & L'orologio non è sincronizzato.\\ 
+    \const{TIME\_BAD}  & 5 & L'orologio non è sincronizzato.\\ 
     \hline
   \end{tabular}
   \caption{Possibili valori di ritorno di \func{adjtimex}.} 
@@ -2224,11 +2224,11 @@ sintassi specificata per la forma equivalente di questa funzione definita come
 \end{table}
 
 La funzione ritorna un valore positivo che esprime lo stato dell'orologio di
-sistema; questo può assumere i valori riportati in
+sistema; questo può assumere i valori riportati in
 tab.~\ref{tab:sys_adjtimex_return}.  Un valore di -1 viene usato per riportare
-un errore; al solito se si cercherà di modificare l'orologio di sistema
+un errore; al solito se si cercherà di modificare l'orologio di sistema
 (specificando un \var{mode} diverso da zero) senza avere i privilegi di
-amministratore si otterrà un errore di \errcode{EPERM}.
+amministratore si otterrà un errore di \errcode{EPERM}.
 
 
 
@@ -2236,20 +2236,20 @@ amministratore si otterr
 \label{sec:sys_date}
 
 Le funzioni viste al paragrafo precedente sono molto utili per trattare le
-operazioni elementari sui tempi, però le rappresentazioni del tempo ivi
+operazioni elementari sui tempi, però le rappresentazioni del tempo ivi
 illustrate, se han senso per specificare un intervallo, non sono molto
-intuitive quando si deve esprimere un'ora o una data.  Per questo motivo è
+intuitive quando si deve esprimere un'ora o una data.  Per questo motivo è
 stata introdotta una ulteriore rappresentazione, detta \textit{broken-down
   time}, che permette appunto di \textsl{suddividere} il \textit{calendar
   time} usuale in ore, minuti, secondi, ecc.
 
 Questo viene effettuato attraverso una opportuna struttura \struct{tm}, la cui
-definizione è riportata in fig.~\ref{fig:sys_tm_struct}, ed è in genere questa
+definizione è riportata in fig.~\ref{fig:sys_tm_struct}, ed è in genere questa
 struttura che si utilizza quando si deve specificare un tempo a partire dai
 dati naturali (ora e data), dato che essa consente anche di trattare la
-gestione del fuso orario e dell'ora legale.\footnote{in realtà i due campi
+gestione del fuso orario e dell'ora legale.\footnote{in realtà i due campi
   \var{tm\_gmtoff} e \var{tm\_zone} sono estensioni previste da BSD e dalle
-  \acr{glibc}, che, quando è definita \macro{\_BSD\_SOURCE}, hanno la forma in
+  \acr{glibc}, che, quando è definita \macro{\_BSD\_SOURCE}, hanno la forma in
   fig.~\ref{fig:sys_tm_struct}.}
 
 Le funzioni per la gestione del \textit{broken-down time} sono varie e vanno
@@ -2302,25 +2302,25 @@ stringa, allocata staticamente, nella forma:
 "Wed Jun 30 21:49:08 1993\n"
 \end{verbatim}
 e impostano anche la variabile \var{tzname} con l'informazione della
-\textit{time zone} corrente; \func{ctime} è banalmente definita in termini di
+\textit{time zone} corrente; \func{ctime} è banalmente definita in termini di
 \func{asctime} come \code{asctime(localtime(t)}. Dato che l'uso di una stringa
 statica rende le funzioni non \index{funzioni!rientranti} rientranti POSIX.1c
 e SUSv2 prevedono due sostitute \index{funzioni!rientranti} rientranti, il cui
-nome è al solito ottenuto aggiungendo un \code{\_r}, che prendono un secondo
+nome è al solito ottenuto aggiungendo un \code{\_r}, che prendono un secondo
 argomento \code{char *buf}, in cui l'utente deve specificare il buffer su cui
 la stringa deve essere copiata (deve essere di almeno 26 caratteri).
 
 Le altre tre funzioni, \func{gmtime}, \func{localtime} e \func{mktime} servono
 per convertire il tempo dal formato \type{time\_t} a quello di \struct{tm} e
 viceversa; \func{gmtime} effettua la conversione usando il tempo coordinato
-universale (UTC), cioè l'ora di Greenwich; mentre \func{localtime} usa l'ora
+universale (UTC), cioè l'ora di Greenwich; mentre \func{localtime} usa l'ora
 locale; \func{mktime} esegue la conversione inversa.  
 
 Anche in questo caso le prime due funzioni restituiscono l'indirizzo di una
 struttura allocata staticamente, per questo sono state definite anche altre
 due versioni \index{funzioni!rientranti} rientranti (con la solita estensione
 \code{\_r}), che prevedono un secondo argomento \code{struct tm *result},
-fornito dal chiamante, che deve preallocare la struttura su cui sarà
+fornito dal chiamante, che deve preallocare la struttura su cui sarà
 restituita la conversione.
 
 Come mostrato in fig.~\ref{fig:sys_tm_struct} il \textit{broken-down time}
@@ -2329,18 +2329,18 @@ locale, compresa l'eventuale ora legale. Questo viene fatto attraverso le tre
 variabili globali mostrate in fig.~\ref{fig:sys_tzname}, cui si accede quando
 si include \file{time.h}. Queste variabili vengono impostate quando si chiama
 una delle precedenti funzioni di conversione, oppure invocando direttamente la
-funzione \funcd{tzset}, il cui prototipo è:
+funzione \funcd{tzset}, il cui prototipo è:
 \begin{prototype}{sys/timex.h}
 {void tzset(void)} 
   
   Imposta le variabili globali della \textit{time zone}.
   
-  \bodydesc{La funzione non ritorna niente e non dà errori.}
+  \bodydesc{La funzione non ritorna niente e non dà errori.}
 \end{prototype}
 
 La funzione inizializza le variabili di fig.~\ref{fig:sys_tzname} a partire dal
-valore della variabile di ambiente \const{TZ}, se quest'ultima non è definita
-verrà usato il file \conffile{/etc/localtime}.
+valore della variabile di ambiente \const{TZ}, se quest'ultima non è definita
+verrà usato il file \conffile{/etc/localtime}.
 
 \begin{figure}[!htb]
   \footnotesize
@@ -2355,17 +2355,17 @@ verr
 \end{figure}
 
 La variabile \var{tzname} contiene due stringhe, che indicano i due nomi
-standard della \textit{time zone} corrente. La prima è il nome per l'ora
+standard della \textit{time zone} corrente. La prima è il nome per l'ora
 solare, la seconda per l'ora legale.\footnote{anche se sono indicati come
-  \code{char *} non è il caso di modificare queste stringhe.} La variabile
+  \code{char *} non è il caso di modificare queste stringhe.} La variabile
 \var{timezone} indica la differenza di fuso orario in secondi, mentre
-\var{daylight} indica se è attiva o meno l'ora legale. 
+\var{daylight} indica se è attiva o meno l'ora legale. 
 
-Benché la funzione \func{asctime} fornisca la modalità più immediata per
-stampare un tempo o una data, la flessibilità non fa parte delle sue
+Benché la funzione \func{asctime} fornisca la modalità più immediata per
+stampare un tempo o una data, la flessibilità non fa parte delle sue
 caratteristiche; quando si vuole poter stampare solo una parte (l'ora, o il
-giorno) di un tempo si può ricorrere alla più sofisticata \funcd{strftime},
-il cui prototipo è:
+giorno) di un tempo si può ricorrere alla più sofisticata \funcd{strftime},
+il cui prototipo è:
 \begin{prototype}{time.h}
 {size\_t strftime(char *s, size\_t max, const char *format, 
   const struct tm *tm)}
@@ -2378,11 +2378,11 @@ Stampa il tempo \param{tm} nella stringa \param{s} secondo il formato
 \end{prototype}
 
 La funzione converte opportunamente il tempo \param{tm} in una stringa di
-testo da salvare in \param{s}, purché essa sia di dimensione, indicata da
+testo da salvare in \param{s}, purché essa sia di dimensione, indicata da
 \param{size}, sufficiente. I caratteri generati dalla funzione vengono
 restituiti come valore di ritorno, ma non tengono conto del terminatore
 finale, che invece viene considerato nel computo della dimensione; se
-quest'ultima è eccessiva viene restituito 0 e lo stato di \param{s} è
+quest'ultima è eccessiva viene restituito 0 e lo stato di \param{s} è
 indefinito.
 
 \begin{table}[htb]
@@ -2410,7 +2410,7 @@ indefinito.
                                     domenica).\\ 
     \var{\%w}&\texttt{3}          & Giorno della settimana.  \\ 
     \var{\%W}&\texttt{16}         & Settimana dell'anno (partendo dal
-                                    lunedì).\\ 
+                                    lunedì).\\ 
     \var{\%x}&\texttt{04/24/02}   & La data.\\ 
     \var{\%X}&\texttt{18:40:50}   & L'ora.\\ 
     \var{\%y}&\texttt{02}         & Anno nel secolo.\\ 
@@ -2424,14 +2424,14 @@ indefinito.
   \label{tab:sys_strftime_format}
 \end{table}
 
-Il risultato della funzione è controllato dalla stringa di formato
+Il risultato della funzione è controllato dalla stringa di formato
 \param{format}, tutti i caratteri restano invariati eccetto \texttt{\%} che
 viene utilizzato come modificatore; alcuni\footnote{per la precisione quelli
   definiti dallo standard ANSI C, che sono anche quelli riportati da POSIX.1;
   le \acr{glibc} provvedono tutte le estensioni introdotte da POSIX.2 per il
   comando \cmd{date}, i valori introdotti da SVID3 e ulteriori estensioni GNU;
-  l'elenco completo dei possibili valori è riportato nella pagina di manuale
-  della funzione.} dei possibili valori che esso può assumere sono riportati
+  l'elenco completo dei possibili valori è riportato nella pagina di manuale
+  della funzione.} dei possibili valori che esso può assumere sono riportati
 in tab.~\ref{tab:sys_strftime_format}. La funzione tiene conto anche della
 presenza di una localizzazione per stampare in maniera adeguata i vari nomi.
 
@@ -2447,7 +2447,7 @@ alcuni segnali (che tratteremo in cap.~\ref{cha:signals}) in un sistema
 unix-like il kernel non avvisa mai direttamente un processo dell'occorrenza di
 un errore nell'esecuzione di una funzione, ma di norma questo viene riportato
 semplicemente usando un opportuno valore di ritorno della funzione invocata.
-Inoltre il sistema di classificazione degli errori è basato sull'architettura
+Inoltre il sistema di classificazione degli errori è basato sull'architettura
 a processi, e presenta una serie di problemi nel caso lo si debba usare con i
 \itindex{thread} \textit{thread}.
 
@@ -2456,30 +2456,30 @@ a processi, e presenta una serie di problemi nel caso lo si debba usare con i
 \label{sec:sys_errno}
 
 Quasi tutte le funzioni delle librerie del C sono in grado di individuare e
-riportare condizioni di errore, ed è una norma fondamentale di buona
+riportare condizioni di errore, ed è una norma fondamentale di buona
 programmazione controllare \textbf{sempre} che le funzioni chiamate si siano
 concluse correttamente.
 
 In genere le funzioni di libreria usano un valore speciale per indicare che
-c'è stato un errore. Di solito questo valore è -1 o un puntatore nullo o la
+c'è stato un errore. Di solito questo valore è -1 o un puntatore nullo o la
 costante \val{EOF} (a seconda della funzione); ma questo valore segnala solo
-che c'è stato un errore, non il tipo di errore.
+che c'è stato un errore, non il tipo di errore.
 
 Per riportare il tipo di errore il sistema usa la variabile globale
-\var{errno},\footnote{l'uso di una variabile globale può comportare alcuni
+\var{errno},\footnote{l'uso di una variabile globale può comportare alcuni
   problemi (ad esempio nel caso dei \itindex{thread} \textit{thread}) ma lo
   standard ISO C consente anche di definire \var{errno} come un
-  \textit{modifiable lvalue}, quindi si può anche usare una macro, e questo è
+  \textit{modifiable lvalue}, quindi si può anche usare una macro, e questo è
   infatti il modo usato da Linux per renderla locale ai singoli
   \itindex{thread} \textit{thread}.}  definita nell'header \file{errno.h}; la
-variabile è in genere definita come \direct{volatile} dato che può essere
+variabile è in genere definita come \direct{volatile} dato che può essere
 cambiata in modo asincrono da un segnale (si veda sez.~\ref{sec:sig_sigchld}
 per un esempio, ricordando quanto trattato in sez.~\ref{sec:proc_race_cond}),
 ma dato che un gestore di segnale scritto bene salva e ripristina il valore
-della variabile, di questo non è necessario preoccuparsi nella programmazione
+della variabile, di questo non è necessario preoccuparsi nella programmazione
 normale.
 
-I valori che può assumere \var{errno} sono riportati in app.~\ref{cha:errors},
+I valori che può assumere \var{errno} sono riportati in app.~\ref{cha:errors},
 nell'header \file{errno.h} sono anche definiti i nomi simbolici per le
 costanti numeriche che identificano i vari errori; essi iniziano tutti per
 \val{E} e si possono considerare come nomi riservati. In seguito faremo
@@ -2489,25 +2489,25 @@ codice relativo ad un valore numerico con l'opzione \cmd{-l}.
 
 Il valore di \var{errno} viene sempre impostato a zero all'avvio di un
 programma, gran parte delle funzioni di libreria impostano \var{errno} ad un
-valore diverso da zero in caso di errore. Il valore è invece indefinito in
-caso di successo, perché anche se una funzione ha successo, può chiamarne
-altre al suo interno che falliscono, modificando così \var{errno}.
-
-Pertanto un valore non nullo di \var{errno} non è sintomo di errore (potrebbe
-essere il risultato di un errore precedente) e non lo si può usare per
-determinare quando o se una chiamata a funzione è fallita.  La procedura da
-seguire è sempre quella di controllare \var{errno} immediatamente dopo aver
+valore diverso da zero in caso di errore. Il valore è invece indefinito in
+caso di successo, perché anche se una funzione ha successo, può chiamarne
+altre al suo interno che falliscono, modificando così \var{errno}.
+
+Pertanto un valore non nullo di \var{errno} non è sintomo di errore (potrebbe
+essere il risultato di un errore precedente) e non lo si può usare per
+determinare quando o se una chiamata a funzione è fallita.  La procedura da
+seguire è sempre quella di controllare \var{errno} immediatamente dopo aver
 verificato il fallimento della funzione attraverso il suo codice di ritorno.
 
 
 \subsection{Le funzioni \func{strerror} e \func{perror}}
 \label{sec:sys_strerror}
 
-Benché gli errori siano identificati univocamente dal valore numerico di
+Benché gli errori siano identificati univocamente dal valore numerico di
 \var{errno} le librerie provvedono alcune funzioni e variabili utili per
 riportare in opportuni messaggi le condizioni di errore verificatesi.  La
-prima funzione che si può usare per ricavare i messaggi di errore è
-\funcd{strerror}, il cui prototipo è:
+prima funzione che si può usare per ricavare i messaggi di errore è
+\funcd{strerror}, il cui prototipo è:
 \begin{prototype}{string.h}{char *strerror(int errnum)} 
   Restituisce una stringa con il messaggio di errore relativo ad
   \param{errnum}.
@@ -2517,28 +2517,28 @@ prima funzione che si pu
 
 
 La funzione ritorna il puntatore alla stringa contenente il messaggio di
-errore corrispondente al valore di \param{errnum}, se questo non è un valore
-valido verrà comunque restituita una stringa valida contenente un messaggio
-che dice che l'errore è sconosciuto, e \var{errno} verrà modificata assumendo
+errore corrispondente al valore di \param{errnum}, se questo non è un valore
+valido verrà comunque restituita una stringa valida contenente un messaggio
+che dice che l'errore è sconosciuto, e \var{errno} verrà modificata assumendo
 il valore \errval{EINVAL}.
 
 In generale \func{strerror} viene usata passando \var{errno} come argomento,
-ed il valore di quest'ultima non verrà modificato. La funzione inoltre tiene
+ed il valore di quest'ultima non verrà modificato. La funzione inoltre tiene
 conto del valore della variabile di ambiente \val{LC\_MESSAGES} per usare le
 appropriate traduzioni dei messaggi d'errore nella localizzazione presente.
 
 La funzione utilizza una stringa statica che non deve essere modificata dal
-programma; essa è utilizzabile solo fino ad una chiamata successiva a
+programma; essa è utilizzabile solo fino ad una chiamata successiva a
 \func{strerror} o \func{perror}, nessun'altra funzione di libreria tocca
 questa stringa. In ogni caso l'uso di una stringa statica rende la funzione
 non \index{funzioni!rientranti} rientrante, per cui nel caso si usino i
 \itindex{thread} \textit{thread} le librerie forniscono\footnote{questa
-  funzione è la versione prevista dalle \acr{glibc}, ed effettivamente
+  funzione è la versione prevista dalle \acr{glibc}, ed effettivamente
   definita in \file{string.h}, ne esiste una analoga nello standard SUSv3
   (quella riportata dalla pagina di manuale), che restituisce \code{int} al
   posto di \code{char *}, e che tronca la stringa restituita a
   \param{size}.}  una apposita versione \index{funzioni!rientranti} rientrante
-\func{strerror\_r}, il cui prototipo è:
+\func{strerror\_r}, il cui prototipo è:
 \begin{prototype}{string.h}
   {char * strerror\_r(int errnum, char *buf, size\_t size)} 
   
@@ -2547,27 +2547,27 @@ non \index{funzioni!rientranti} rientrante, per cui nel caso si usino i
  
   \bodydesc{La funzione restituisce l'indirizzo del messaggio in caso di
     successo e \val{NULL} in caso di errore; nel qual caso \var{errno}
-    assumerà i valori:
+    assumerà i valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] si è specificato un valore di \param{errnum} non
+  \item[\errcode{EINVAL}] si è specificato un valore di \param{errnum} non
     valido.
-  \item[\errcode{ERANGE}] la lunghezza di \param{buf} è insufficiente a
+  \item[\errcode{ERANGE}] la lunghezza di \param{buf} è insufficiente a
     contenere la stringa di errore.
   \end{errlist}}
 \end{prototype}
 \noindent
 
-La funzione è analoga a \func{strerror} ma restituisce la stringa di errore
+La funzione è analoga a \func{strerror} ma restituisce la stringa di errore
 nel buffer \param{buf} che il singolo \itindex{thread} \textit{thread} deve
 allocare autonomamente per evitare i problemi connessi alla condivisione del
-buffer statico. Il messaggio è copiato fino alla dimensione massima del
+buffer statico. Il messaggio è copiato fino alla dimensione massima del
 buffer, specificata dall'argomento
 \param{size}, che deve comprendere pure il carattere di terminazione;
 altrimenti la stringa viene troncata.
 
 Una seconda funzione usata per riportare i codici di errore in maniera
-automatizzata sullo standard error (vedi sez.~\ref{sec:file_std_descr}) è
-\funcd{perror}, il cui prototipo è:
+automatizzata sullo standard error (vedi sez.~\ref{sec:file_std_descr}) è
+\funcd{perror}, il cui prototipo è:
 \begin{prototype}{stdio.h}{void perror(const char *message)} 
   Stampa il messaggio di errore relativo al valore corrente di \var{errno}
   sullo standard error; preceduto dalla stringa \param{message}.
@@ -2577,13 +2577,13 @@ I messaggi di errore stampati sono gli stessi di \func{strerror}, (riportati
 in app.~\ref{cha:errors}), e, usando il valore corrente di \var{errno}, si
 riferiscono all'ultimo errore avvenuto. La stringa specificata con
 \param{message} viene stampato prima del messaggio d'errore, seguita dai due
-punti e da uno spazio, il messaggio è terminato con un a capo.
+punti e da uno spazio, il messaggio è terminato con un a capo.
 
-Il messaggio può essere riportato anche usando le due variabili globali:
+Il messaggio può essere riportato anche usando le due variabili globali:
 \includecodesnip{listati/errlist.c} 
 dichiarate in \file{errno.h}. La prima contiene i puntatori alle stringhe di
-errore indicizzati da \var{errno}; la seconda esprime il valore più alto per
-un codice di errore, l'utilizzo di questa stringa è sostanzialmente
+errore indicizzati da \var{errno}; la seconda esprime il valore più alto per
+un codice di errore, l'utilizzo di questa stringa è sostanzialmente
 equivalente a quello di \func{strerror}.
 
 \begin{figure}[!htb]
@@ -2596,12 +2596,12 @@ equivalente a quello di \func{strerror}.
   \label{fig:sys_err_mess}
 \end{figure}
 
-In fig.~\ref{fig:sys_err_mess} è riportata la sezione attinente del codice del
-programma \cmd{errcode}, che può essere usato per stampare i messaggi di
+In fig.~\ref{fig:sys_err_mess} è riportata la sezione attinente del codice del
+programma \cmd{errcode}, che può essere usato per stampare i messaggi di
 errore e le costanti usate per identificare i singoli errori; il sorgente
-completo del programma è allegato nel file \file{ErrCode.c} e contiene pure la
+completo del programma è allegato nel file \file{ErrCode.c} e contiene pure la
 gestione delle opzioni e tutte le definizioni necessarie ad associare il
-valore numerico alla costante simbolica. In particolare si è riportata la
+valore numerico alla costante simbolica. In particolare si è riportata la
 sezione che converte la stringa passata come argomento in un intero
 (\texttt{\small 1--2}), controllando con i valori di ritorno di \func{strtol}
 che la conversione sia avvenuta correttamente (\texttt{\small 4--10}), e poi
@@ -2614,9 +2614,9 @@ stampa, a seconda dell'opzione scelta il messaggio di errore (\texttt{\small
 \label{sec:sys_err_GNU}
 
 Le precedenti funzioni sono quelle definite ed usate nei vari standard; le
-\acr{glibc} hanno però introdotto una serie di estensioni ``GNU'' che
-forniscono alcune funzionalità aggiuntive per una gestione degli errori
-semplificata e più efficiente. 
+\acr{glibc} hanno però introdotto una serie di estensioni ``GNU'' che
+forniscono alcune funzionalità aggiuntive per una gestione degli errori
+semplificata e più efficiente. 
 
 La prima estensione consiste in due variabili, \code{char *
   program\_invocation\_name} e \code{char * program\_invocation\_short\_name}
@@ -2624,17 +2624,17 @@ servono per ricavare il nome del programma; queste sono utili quando si deve
 aggiungere il nome del programma (cosa comune quando si ha un programma che
 non viene lanciato da linea di comando e salva gli errori in un file di log)
 al messaggio d'errore. La prima contiene il nome usato per lanciare il
-programma (ed è equivalente ad \code{argv[0]}); la seconda mantiene solo il
+programma (ed è equivalente ad \code{argv[0]}); la seconda mantiene solo il
 nome del programma (senza eventuali directory in testa).
 
-Uno dei problemi che si hanno con l'uso di \func{perror} è che non c'è
-flessibilità su quello che si può aggiungere al messaggio di errore, che può
+Uno dei problemi che si hanno con l'uso di \func{perror} è che non c'è
+flessibilità su quello che si può aggiungere al messaggio di errore, che può
 essere solo una stringa. In molte occasioni invece serve poter scrivere dei
 messaggi con maggiore informazione; ad esempio negli standard di
 programmazione GNU si richiede che ogni messaggio di errore sia preceduto dal
-nome del programma, ed in generale si può voler stampare il contenuto di
+nome del programma, ed in generale si può voler stampare il contenuto di
 qualche variabile; per questo le \acr{glibc} definiscono la funzione
-\funcd{error}, il cui prototipo è:
+\funcd{error}, il cui prototipo è:
 \begin{prototype}{stdio.h}
 {void error(int status, int errnum, const char *format, ...)} 
 
@@ -2651,24 +2651,24 @@ il valore corrente di \var{errno}); la funzione stampa sullo standard error il
 nome del programma, come indicato dalla variabile globale \var{program\_name},
 seguito da due punti ed uno spazio, poi dalla stringa generata da
 \param{format} e dagli argomenti seguenti, seguita da due punti ed uno spazio
-infine il messaggio di errore relativo ad \param{errnum}, il tutto è terminato
+infine il messaggio di errore relativo ad \param{errnum}, il tutto è terminato
 da un a capo.
 
-Il comportamento della funzione può essere ulteriormente controllato se si
+Il comportamento della funzione può essere ulteriormente controllato se si
 definisce una variabile \var{error\_print\_progname} come puntatore ad una
 funzione \ctyp{void} che restituisce \ctyp{void} che si incarichi di stampare
 il nome del programma. 
 
-L'argomento \param{status} può essere usato per terminare direttamente il
+L'argomento \param{status} può essere usato per terminare direttamente il
 programma in caso di errore, nel qual caso \func{error} dopo la stampa del
 messaggio di errore chiama \func{exit} con questo stato di uscita. Se invece
-il valore è nullo \func{error} ritorna normalmente ma viene incrementata
+il valore è nullo \func{error} ritorna normalmente ma viene incrementata
 un'altra variabile globale, \var{error\_message\_count}, che tiene conto di
 quanti errori ci sono stati.
 
-Un'altra funzione per la stampa degli errori, ancora più sofisticata, che
-prende due argomenti aggiuntivi per indicare linea e file su cui è avvenuto
-l'errore è \funcd{error\_at\_line}; il suo prototipo è:
+Un'altra funzione per la stampa degli errori, ancora più sofisticata, che
+prende due argomenti aggiuntivi per indicare linea e file su cui è avvenuto
+l'errore è \funcd{error\_at\_line}; il suo prototipo è:
 \begin{prototype}{stdio.h}
 {void error\_at\_line(int status, int errnum, const char *fname, 
   unsigned int lineno, const char *format, ...)} 
@@ -2677,7 +2677,7 @@ Stampa un messaggio di errore formattato.
 
 \bodydesc{La funzione non restituisce nulla e non riporta errori.}
 \end{prototype}
-\noindent ed il suo comportamento è identico a quello di \func{error} se non
+\noindent ed il suo comportamento è identico a quello di \func{error} se non
 per il fatto che, separati con il solito due punti-spazio, vengono inseriti un
 nome di file indicato da \param{fname} ed un numero di linea subito dopo la
 stampa del nome del programma. Inoltre essa usa un'altra variabile globale,
diff --git a/tcpsock.tex b/tcpsock.tex
index 102242b..9cd9ab7 100644
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -23,15 +23,15 @@ finiremo prendendo in esame l'uso dell'I/O multiplexing.
 \label{sec:TCP_connession}
 
 Prima di entrare nei dettagli delle singole funzioni usate nelle applicazioni
-che utilizzano i socket TCP, è fondamentale spiegare alcune delle basi del
-funzionamento del protocollo, poiché questa conoscenza è essenziale per
+che utilizzano i socket TCP, è fondamentale spiegare alcune delle basi del
+funzionamento del protocollo, poiché questa conoscenza è essenziale per
 comprendere il comportamento di dette funzioni per questo tipo di socket, ed
 il relativo modello di programmazione.
 
 Si ricordi che il protocollo TCP serve a creare degli \textit{stream socket},
-cioè una forma di canale di comunicazione che stabilisce una connessione
+cioè una forma di canale di comunicazione che stabilisce una connessione
 stabile fra due stazioni, in modo che queste possano scambiarsi dei dati. In
-questa sezione ci concentreremo sulle modalità con le quali il protocollo dà
+questa sezione ci concentreremo sulle modalità con le quali il protocollo dà
 inizio e conclude una connessione e faremo inoltre un breve accenno al
 significato di alcuni dei vari \textsl{stati} ad essa associati.
 
@@ -40,18 +40,18 @@ significato di alcuni dei vari \textsl{stati} ad essa associati.
 \label{sec:TCP_conn_cre}
 
 \itindbeg{three~way~handshake} 
-Il processo che porta a creare una connessione TCP è chiamato \textit{three
+Il processo che porta a creare una connessione TCP è chiamato \textit{three
   way handshake}; la successione tipica degli eventi (e dei
-\textsl{segmenti}\footnote{si ricordi che il segmento è l'unità elementare di
+\textsl{segmenti}\footnote{si ricordi che il segmento è l'unità elementare di
   dati trasmessa dal protocollo TCP al livello successivo; tutti i segmenti
   hanno un header che contiene le informazioni che servono allo \textit{stack
-    TCP} (così viene di solito chiamata la parte del kernel che implementa il
+    TCP} (così viene di solito chiamata la parte del kernel che implementa il
   protocollo) per realizzare la comunicazione, fra questi dati ci sono una
   serie di flag usati per gestire la connessione, come SYN, ACK, URG, FIN,
   alcuni di essi, come SYN (che sta per \textit{syncronize}) corrispondono a
   funzioni particolari del protocollo e danno il nome al segmento, (per
   maggiori dettagli vedere sez.~\ref{sec:tcp_protocol}).}  di dati che vengono
-scambiati) che porta alla creazione di una connessione è la seguente:
+scambiati) che porta alla creazione di una connessione è la seguente:
  
 \begin{enumerate}
 \item Il server deve essere preparato per accettare le connessioni in arrivo;
@@ -76,23 +76,23 @@ scambiati) che porta alla creazione di una connessione 
   e ACK.
   
 \item una volta che il client ha ricevuto l'acknowledge dal server la funzione
-  \func{connect} ritorna, l'ultimo passo è dare il ricevuto del SYN del
+  \func{connect} ritorna, l'ultimo passo è dare il ricevuto del SYN del
   server inviando un ACK. Alla ricezione di quest'ultimo la funzione
-  \func{accept} del server ritorna e la connessione è stabilita.
+  \func{accept} del server ritorna e la connessione è stabilita.
 \end{enumerate} 
 
 Il procedimento viene chiamato \textit{three way handshake} dato che per
 realizzarlo devono essere scambiati tre segmenti.  In fig.~\ref{fig:TCP_TWH}
-si è rappresentata graficamente la sequenza di scambio dei segmenti che
+si è rappresentata graficamente la sequenza di scambio dei segmenti che
 stabilisce la connessione.
 
-% Una analogia citata da R. Stevens per la connessione TCP è quella con il
-% sistema del telefono. La funzione \func{socket} può essere considerata
-% l'equivalente di avere un telefono. La funzione \func{bind} è analoga al
-% dire alle altre persone qual è il proprio numero di telefono perché possano
-% chiamare. La funzione \func{listen} è accendere il campanello del telefono
+% Una analogia citata da R. Stevens per la connessione TCP è quella con il
+% sistema del telefono. La funzione \func{socket} può essere considerata
+% l'equivalente di avere un telefono. La funzione \func{bind} è analoga al
+% dire alle altre persone qual è il proprio numero di telefono perché possano
+% chiamare. La funzione \func{listen} è accendere il campanello del telefono
 % per sentire le chiamate in arrivo.  La funzione \func{connect} richiede di
-% conoscere il numero di chi si vuole chiamare. La funzione \func{accept} è
+% conoscere il numero di chi si vuole chiamare. La funzione \func{accept} è
 % quando si risponde al telefono.
 
 \begin{figure}[htb]
@@ -102,7 +102,7 @@ stabilisce la connessione.
   \label{fig:TCP_TWH}
 \end{figure}
 
-Si è accennato in precedenza ai \textsl{numeri di sequenza} (che sono anche
+Si è accennato in precedenza ai \textsl{numeri di sequenza} (che sono anche
 riportati in fig.~\ref{fig:TCP_TWH}): per gestire una connessione affidabile
 infatti il protocollo TCP prevede nell'header la presenza di un numero a 32
 bit (chiamato appunto \textit{sequence number}) che identifica a quale byte
@@ -117,8 +117,8 @@ il flag ACK e restituendo nell'apposito campo dell'header un
 \textit{acknowledge number}) pari al numero di sequenza che il ricevente si
 aspetta di ricevere con il pacchetto successivo; dato che il primo pacchetto
 SYN consuma un byte, nel \textit{three way handshake} il numero di acknowledge
-è sempre pari al numero di sequenza iniziale incrementato di uno; lo stesso
-varrà anche (vedi fig.~\ref{fig:TCP_close}) per l'acknowledgement di un FIN.
+è sempre pari al numero di sequenza iniziale incrementato di uno; lo stesso
+varrà anche (vedi fig.~\ref{fig:TCP_close}) per l'acknowledgement di un FIN.
 
 \itindend{three~way~handshake}
 
@@ -139,7 +139,7 @@ connessione.  Normalmente vengono usate le seguenti opzioni:
 \item \textit{MSS option}, dove MMS sta per \itindex{Maximum~Segment~Size}
   \textit{Maximum Segment Size}, con questa opzione ciascun capo della
   connessione annuncia all'altro il massimo ammontare di dati che vorrebbe
-  accettare per ciascun segmento nella connessione corrente. È possibile
+  accettare per ciascun segmento nella connessione corrente. È possibile
   leggere e scrivere questo valore attraverso l'opzione del socket
   \const{TCP\_MAXSEG} (vedi sez.~\ref{sec:sock_tcp_udp_options}).
   
@@ -148,43 +148,43 @@ connessione.  Normalmente vengono usate le seguenti opzioni:
     window} (la ``\textsl{finestra annunciata}'', vedi
   sez.~\ref{sec:tcp_protocol_xxx}) con la quale ciascun capo della
   comunicazione dichiara quanto spazio disponibile ha in memoria per i dati.
-  Questo è un numero a 16 bit dell'header, che così può indicare un massimo di
-  65535 byte;\footnote{in Linux il massimo è 32767 per evitare problemi con
+  Questo è un numero a 16 bit dell'header, che così può indicare un massimo di
+  65535 byte;\footnote{in Linux il massimo è 32767 per evitare problemi con
     alcune implementazioni che usano l'aritmetica con segno per implementare
-    lo stack TCP.} ma alcuni tipi di connessione come quelle ad alta velocità
+    lo stack TCP.} ma alcuni tipi di connessione come quelle ad alta velocità
   (sopra i 45Mbit/sec) e quelle che hanno grandi ritardi nel cammino dei
-  pacchetti (come i satelliti) richiedono una finestra più grande per poter
+  pacchetti (come i satelliti) richiedono una finestra più grande per poter
   ottenere il massimo dalla trasmissione. Per questo esiste questa opzione che
   indica un fattore di scala da applicare al valore della
   \itindex{advertised~window} finestra annunciata\footnote{essendo una nuova
-    opzione per garantire la compatibilità con delle vecchie implementazioni
+    opzione per garantire la compatibilità con delle vecchie implementazioni
     del protocollo la procedura che la attiva prevede come negoziazione che
     l'altro capo della connessione riconosca esplicitamente l'opzione
     inserendola anche lui nel suo SYN di risposta dell'apertura della
     connessione.} per la connessione corrente (espresso come numero di bit cui
   spostare a sinistra il valore della finestra annunciata inserito nel
-  pacchetto). Con Linux è possibile indicare al kernel di far negoziare il
+  pacchetto). Con Linux è possibile indicare al kernel di far negoziare il
   fattore di scala in fase di creazione di una connessione tramite la
   \textit{sysctl} \itindex{TCP~window~scaling} \texttt{tcp\_window\_scaling}
   (vedi sez.~\ref{sec:sock_ipv4_sysctl}).\footnote{per poter usare questa
-    funzionalità è comunque necessario ampliare le dimensioni dei buffer di
-    ricezione e spedizione, cosa che può essere fatta sia a livello di sistema
+    funzionalità è comunque necessario ampliare le dimensioni dei buffer di
+    ricezione e spedizione, cosa che può essere fatta sia a livello di sistema
     con le opportune \textit{sysctl} (vedi sez.~\ref{sec:sock_ipv4_sysctl})
     che a livello di singoli socket con le relative opzioni (vedi
     sez.~\ref{sec:sock_tcp_udp_options}).}
 
-\item \textit{timestamp option}, è anche questa una nuova opzione necessaria
-  per le connessioni ad alta velocità per evitare possibili corruzioni di dati
+\item \textit{timestamp option}, è anche questa una nuova opzione necessaria
+  per le connessioni ad alta velocità per evitare possibili corruzioni di dati
   dovute a pacchetti perduti che riappaiono; anche questa viene negoziata come
   la precedente.
 
 \end{itemize}
 
-La MSS \itindex{Maximum~Segment~Size} è generalmente supportata da quasi tutte
+La MSS \itindex{Maximum~Segment~Size} è generalmente supportata da quasi tutte
 le implementazioni del protocollo, le ultime due opzioni (trattate
 nell'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}) sono meno comuni;
-vengono anche dette \textit{long fat pipe options} dato che questo è il nome
-che viene dato alle connessioni caratterizzate da alta velocità o da ritardi
+vengono anche dette \textit{long fat pipe options} dato che questo è il nome
+che viene dato alle connessioni caratterizzate da alta velocità o da ritardi
 elevati. In ogni caso Linux supporta pienamente entrambe le opzioni.
 
 
@@ -193,36 +193,36 @@ elevati. In ogni caso Linux supporta pienamente entrambe le opzioni.
 
 Mentre per la creazione di una connessione occorre un interscambio di tre
 segmenti, la procedura di chiusura ne richiede normalmente quattro. In questo
-caso la successione degli eventi è la seguente:
+caso la successione degli eventi è la seguente:
 
 \begin{enumerate}
 \item Un processo ad uno dei due capi chiama la funzione \func{close}, dando
   l'avvio a quella che viene chiamata \textsl{chiusura attiva} (o
   \textit{active close}). Questo comporta l'emissione di un segmento FIN, che
-  serve ad indicare che si è finito con l'invio dei dati sulla connessione.
+  serve ad indicare che si è finito con l'invio dei dati sulla connessione.
   
-\item L'altro capo della connessione riceve il FIN e dovrà eseguire la
+\item L'altro capo della connessione riceve il FIN e dovrà eseguire la
   \textsl{chiusura passiva} (o \textit{passive close}). Al FIN, come ad ogni
   altro pacchetto, viene risposto con un ACK, inoltre il ricevimento del FIN
   viene segnalato al processo che ha aperto il socket (dopo che ogni altro
-  eventuale dato rimasto in coda è stato ricevuto) come un end-of-file sulla
-  lettura: questo perché il ricevimento di un FIN significa che non si
+  eventuale dato rimasto in coda è stato ricevuto) come un end-of-file sulla
+  lettura: questo perché il ricevimento di un FIN significa che non si
   riceveranno altri dati sulla connessione.
   
-\item Una volta rilevata l'end-of-file anche il secondo processo chiamerà la
+\item Una volta rilevata l'end-of-file anche il secondo processo chiamerà la
   funzione \func{close} sul proprio socket, causando l'emissione di un altro
   segmento FIN.
 
-\item L'altro capo della connessione riceverà il FIN conclusivo e risponderà
+\item L'altro capo della connessione riceverà il FIN conclusivo e risponderà
   con un ACK.
 \end{enumerate}
 
 Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione
-normalmente i segmenti scambiati sono quattro.  Questo non è vero sempre
-giacché in alcune situazioni il FIN del passo 1) è inviato insieme a dei dati.
-Inoltre è possibile che i segmenti inviati nei passi 2 e 3 dal capo che
+normalmente i segmenti scambiati sono quattro.  Questo non è vero sempre
+giacché in alcune situazioni il FIN del passo 1) è inviato insieme a dei dati.
+Inoltre è possibile che i segmenti inviati nei passi 2 e 3 dal capo che
 effettua la chiusura passiva, siano accorpati in un singolo segmento. In
-fig.~\ref{fig:TCP_close} si è rappresentato graficamente lo sequenza di
+fig.~\ref{fig:TCP_close} si è rappresentato graficamente lo sequenza di
 scambio dei segmenti che conclude la connessione.
 
 \begin{figure}[htb]
@@ -233,31 +233,31 @@ scambio dei segmenti che conclude la connessione.
 \end{figure}
 
 Come per il SYN anche il FIN occupa un byte nel numero di sequenza, per cui
-l'ACK riporterà un \textit{acknowledge number} incrementato di uno. 
+l'ACK riporterà un \textit{acknowledge number} incrementato di uno. 
 
-Si noti che, nella sequenza di chiusura, fra i passi 2 e 3, è in teoria
+Si noti che, nella sequenza di chiusura, fra i passi 2 e 3, è in teoria
 possibile che si mantenga un flusso di dati dal capo della connessione che
 deve ancora eseguire la chiusura passiva a quello che sta eseguendo la
 chiusura attiva.  Nella sequenza indicata i dati verrebbero persi, dato che si
-è chiuso il socket dal lato che esegue la chiusura attiva; esistono tuttavia
-situazioni in cui si vuole poter sfruttare questa possibilità, usando una
-procedura che è chiamata \itindex{half-close} \textit{half-close}; torneremo
+è chiuso il socket dal lato che esegue la chiusura attiva; esistono tuttavia
+situazioni in cui si vuole poter sfruttare questa possibilità, usando una
+procedura che è chiamata \itindex{half-close} \textit{half-close}; torneremo
 su questo aspetto e su come utilizzarlo in sez.~\ref{sec:TCP_shutdown}, quando
 parleremo della funzione \func{shutdown}.
 
-La emissione del FIN avviene quando il socket viene chiuso, questo però non
+La emissione del FIN avviene quando il socket viene chiuso, questo però non
 avviene solo per la chiamata esplicita della funzione \func{close}, ma anche
 alla terminazione di un processo, quando tutti i file vengono chiusi.  Questo
 comporta ad esempio che se un processo viene terminato da un segnale tutte le
 connessioni aperte verranno chiuse.
 
-Infine occorre sottolineare che, benché nella figura (e nell'esempio che
-vedremo più avanti in sez.~\ref{sec:TCP_echo}) sia stato il client ad eseguire
-la chiusura attiva, nella realtà questa può essere eseguita da uno qualunque
+Infine occorre sottolineare che, benché nella figura (e nell'esempio che
+vedremo più avanti in sez.~\ref{sec:TCP_echo}) sia stato il client ad eseguire
+la chiusura attiva, nella realtà questa può essere eseguita da uno qualunque
 dei due capi della comunicazione (come nell'esempio di
-fig.~\ref{fig:TCP_daytime_iter_server_code}), e anche se il caso più comune
-resta quello del client, ci sono alcuni servizi, il principale dei quali è
-l'HTTP, per i quali è il server ad effettuare la chiusura attiva.
+fig.~\ref{fig:TCP_daytime_iter_server_code}), e anche se il caso più comune
+resta quello del client, ci sono alcuni servizi, il principale dei quali è
+l'HTTP, per i quali è il server ad effettuare la chiusura attiva.
 
 
 \subsection{Un esempio di connessione}
@@ -266,7 +266,7 @@ l'HTTP, per i quali 
 Come abbiamo visto le operazioni del TCP nella creazione e conclusione di una
 connessione sono piuttosto complesse, ed abbiamo esaminato soltanto quelle
 relative ad un andamento normale.  In sez.~\ref{sec:TCP_states} vedremo con
-maggiori dettagli che una connessione può assumere vari stati, che ne
+maggiori dettagli che una connessione può assumere vari stati, che ne
 caratterizzano il funzionamento, e che sono quelli che vengono riportati dal
 comando \cmd{netstat}, per ciascun socket TCP aperto, nel campo
 \textit{State}.
@@ -278,24 +278,24 @@ riferimento resta \cite{TCPIll1}. Qui ci limiteremo a descrivere brevemente un
 semplice esempio di connessione e le transizioni che avvengono nei due casi
 appena citati (creazione e terminazione della connessione).
 
-In assenza di connessione lo stato del TCP è \texttt{CLOSED}; quando una
+In assenza di connessione lo stato del TCP è \texttt{CLOSED}; quando una
 applicazione esegue una apertura attiva il TCP emette un SYN e lo stato
 diventa \texttt{SYN\_SENT}; quando il TCP riceve la risposta del SYN$+$ACK
-emette un ACK e passa allo stato \texttt{ESTABLISHED}; questo è lo stato
+emette un ACK e passa allo stato \texttt{ESTABLISHED}; questo è lo stato
 finale in cui avviene la gran parte del trasferimento dei dati.
 
 Dal lato server in genere invece il passaggio che si opera con l'apertura
-passiva è quello di portare il socket dallo stato \texttt{CLOSED} allo
+passiva è quello di portare il socket dallo stato \texttt{CLOSED} allo
 stato \texttt{LISTEN} in cui vengono accettate le connessioni.
 
-Dallo stato \texttt{ESTABLISHED} si può uscire in due modi; se un'applicazione
+Dallo stato \texttt{ESTABLISHED} si può uscire in due modi; se un'applicazione
 chiama la funzione \func{close} prima di aver ricevuto un
-\textit{end-of-file} (chiusura attiva) la transizione è verso lo stato
+\textit{end-of-file} (chiusura attiva) la transizione è verso lo stato
 \texttt{FIN\_WAIT\_1}; se invece l'applicazione riceve un FIN nello stato
-\texttt{ESTABLISHED} (chiusura passiva) la transizione è verso lo stato
+\texttt{ESTABLISHED} (chiusura passiva) la transizione è verso lo stato
 \texttt{CLOSE\_WAIT}.
 
-In fig.~\ref{fig:TCP_conn_example} è riportato lo schema dello scambio dei
+In fig.~\ref{fig:TCP_conn_example} è riportato lo schema dello scambio dei
 pacchetti che avviene per una un esempio di connessione, insieme ai vari stati
 che il protocollo viene ad assumere per i due lati, server e client.
 
@@ -311,13 +311,13 @@ La connessione viene iniziata dal client che annuncia una
 IPv4 su Ethernet, il server risponde con lo stesso valore (ma potrebbe essere
 anche un valore diverso).
 
-Una volta che la connessione è stabilita il client scrive al server una
-richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei
+Una volta che la connessione è stabilita il client scrive al server una
+richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei
 1460 byte annunciati dal server), quest'ultimo riceve la richiesta e
 restituisce una risposta (che di nuovo supponiamo stare in un singolo
-segmento). Si noti che l'acknowledge della richiesta è mandato insieme alla
+segmento). Si noti che l'acknowledge della richiesta è mandato insieme alla
 risposta: questo viene chiamato \textit{piggybacking} ed avviene tutte le
-volte che il server è sufficientemente veloce a costruire la risposta; in
+volte che il server è sufficientemente veloce a costruire la risposta; in
 caso contrario si avrebbe prima l'emissione di un ACK e poi l'invio della
 risposta.
 
@@ -326,52 +326,52 @@ secondo quanto visto in sez.~\ref{sec:TCP_conn_term}; si noti che il capo della
 connessione che esegue la chiusura attiva entra nello stato
 \texttt{TIME\_WAIT}, sul cui significato torneremo fra poco.
 
-È da notare come per effettuare uno scambio di due pacchetti (uno di richiesta
+È da notare come per effettuare uno scambio di due pacchetti (uno di richiesta
 e uno di risposta) il TCP necessiti di ulteriori otto segmenti, se invece si
-fosse usato UDP sarebbero stati sufficienti due soli pacchetti. Questo è il
-costo che occorre pagare per avere l'affidabilità garantita dal TCP, se si
+fosse usato UDP sarebbero stati sufficienti due soli pacchetti. Questo è il
+costo che occorre pagare per avere l'affidabilità garantita dal TCP, se si
 fosse usato UDP si sarebbe dovuto trasferire la gestione di tutta una serie di
 dettagli (come la verifica della ricezione dei pacchetti) dal livello del
 trasporto all'interno dell'applicazione.
 
-Quello che è bene sempre tenere presente è allora quali sono le esigenze che
-si hanno in una applicazione di rete, perché non è detto che TCP sia la
+Quello che è bene sempre tenere presente è allora quali sono le esigenze che
+si hanno in una applicazione di rete, perché non è detto che TCP sia la
 miglior scelta in tutti i casi (ad esempio se si devono solo scambiare dati
-già organizzati in piccoli pacchetti l'overhead aggiunto può essere eccessivo)
-per questo esistono applicazioni che usano UDP e lo fanno perché nel caso
-specifico le sue caratteristiche di velocità e compattezza nello scambio dei
+già organizzati in piccoli pacchetti l'overhead aggiunto può essere eccessivo)
+per questo esistono applicazioni che usano UDP e lo fanno perché nel caso
+specifico le sue caratteristiche di velocità e compattezza nello scambio dei
 dati rispondono meglio alle esigenze che devono essere affrontate.
 
 \subsection{Lo stato \texttt{TIME\_WAIT}}
 \label{sec:TCP_time_wait}
 
-Come riportato da Stevens in \cite{UNP1} lo stato \texttt{TIME\_WAIT} è
-probabilmente uno degli aspetti meno compresi del protocollo TCP, è infatti
+Come riportato da Stevens in \cite{UNP1} lo stato \texttt{TIME\_WAIT} è
+probabilmente uno degli aspetti meno compresi del protocollo TCP, è infatti
 comune trovare domande su come sia possibile evitare che un'applicazione resti
-in questo stato lasciando attiva una connessione ormai conclusa; la risposta è
+in questo stato lasciando attiva una connessione ormai conclusa; la risposta è
 che non deve essere fatto, ed il motivo cercheremo di spiegarlo adesso.
 
-Come si è visto nell'esempio precedente (vedi fig.~\ref{fig:TCP_conn_example})
-\texttt{TIME\_WAIT} è lo stato finale in cui il capo di una connessione che
+Come si è visto nell'esempio precedente (vedi fig.~\ref{fig:TCP_conn_example})
+\texttt{TIME\_WAIT} è lo stato finale in cui il capo di una connessione che
 esegue la chiusura attiva resta prima di passare alla chiusura definitiva
 della connessione. Il tempo in cui l'applicazione resta in questo stato deve
 essere due volte la MSL (\textit{Maximum Segment Lifetime}).
 
-La MSL è la stima del massimo periodo di tempo che un pacchetto IP può vivere
-sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
+La MSL è la stima del massimo periodo di tempo che un pacchetto IP può vivere
+sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
 ritrasmesso dai router un numero massimo di volte (detto \textit{hop limit}).
-Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di
+Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di
 IP (per maggiori dettagli vedi sez.~\ref{sec:ip_protocol}), e viene
 decrementato ad ogni passaggio da un router; quando si annulla il pacchetto
-viene scartato.  Siccome il numero è ad 8 bit il numero massimo di
-``\textsl{salti}'' è di 255, pertanto anche se il TTL (da \textit{time to
-  live}) non è propriamente un limite sul tempo di vita, si stima che un
-pacchetto IP non possa restare nella rete per più di MSL secondi.
+viene scartato.  Siccome il numero è ad 8 bit il numero massimo di
+``\textsl{salti}'' è di 255, pertanto anche se il TTL (da \textit{time to
+  live}) non è propriamente un limite sul tempo di vita, si stima che un
+pacchetto IP non possa restare nella rete per più di MSL secondi.
 
 Ogni implementazione del TCP deve scegliere un valore per la MSL
 (l'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} raccomanda 2 minuti,
 Linux usa 30 secondi), questo comporta una durata dello stato
-\texttt{TIME\_WAIT} che a seconda delle implementazioni può variare fra 1 a 4
+\texttt{TIME\_WAIT} che a seconda delle implementazioni può variare fra 1 a 4
 minuti.  Lo stato \texttt{TIME\_WAIT} viene utilizzato dal protocollo per due
 motivi principali:
 \begin{enumerate}
@@ -380,18 +380,18 @@ motivi principali:
 \item consentire l'eliminazione dei segmenti duplicati dalla rete. 
 \end{enumerate}
 
-Il punto è che entrambe le ragioni sono importanti, anche se spesso si fa
-riferimento solo alla prima; ma è solo se si tiene conto della seconda che si
-capisce il perché della scelta di un tempo pari al doppio della MSL come
+Il punto è che entrambe le ragioni sono importanti, anche se spesso si fa
+riferimento solo alla prima; ma è solo se si tiene conto della seconda che si
+capisce il perché della scelta di un tempo pari al doppio della MSL come
 durata di questo stato.
 
-Il primo dei due motivi precedenti si può capire tornando a
+Il primo dei due motivi precedenti si può capire tornando a
 fig.~\ref{fig:TCP_conn_example}: assumendo che l'ultimo ACK della sequenza
 (quello del capo che ha eseguito la chiusura attiva) venga perso, chi esegue
-la chiusura passiva non ricevendo risposta rimanderà un ulteriore FIN, per
+la chiusura passiva non ricevendo risposta rimanderà un ulteriore FIN, per
 questo motivo chi esegue la chiusura attiva deve mantenere lo stato della
 connessione per essere in grado di reinviare l'ACK e chiuderla correttamente.
-Se non fosse così la risposta sarebbe un RST (un altro tipo si segmento) che
+Se non fosse così la risposta sarebbe un RST (un altro tipo si segmento) che
 verrebbe interpretato come un errore.
 
 Se il TCP deve poter chiudere in maniera pulita entrambe le direzioni della
@@ -401,30 +401,30 @@ motivo un socket deve rimanere attivo nello stato \texttt{TIME\_WAIT} anche
 dopo l'invio dell'ultimo ACK, per potere essere in grado di gestirne
 l'eventuale ritrasmissione, in caso esso venga perduto.
 
-Il secondo motivo è più complesso da capire, e necessita di una spiegazione
-degli scenari in cui può accadere che i pacchetti TCP si possano perdere nella
+Il secondo motivo è più complesso da capire, e necessita di una spiegazione
+degli scenari in cui può accadere che i pacchetti TCP si possano perdere nella
 rete o restare intrappolati, per poi riemergere in un secondo tempo.
 
-Il caso più comune in cui questo avviene è quello di anomalie
-nell'instradamento; può accadere cioè che un router smetta di funzionare o che
+Il caso più comune in cui questo avviene è quello di anomalie
+nell'instradamento; può accadere cioè che un router smetta di funzionare o che
 una connessione fra due router si interrompa. In questo caso i protocolli di
 instradamento dei pacchetti possono impiegare diverso tempo (anche dell'ordine
 dei minuti) prima di trovare e stabilire un percorso alternativo per i
 pacchetti. Nel frattempo possono accadere casi in cui un router manda i
 pacchetti verso un altro e quest'ultimo li rispedisce indietro, o li manda ad
-un terzo router che li rispedisce al primo, si creano cioè dei circoli (i
+un terzo router che li rispedisce al primo, si creano cioè dei circoli (i
 cosiddetti \textit{routing loop}) in cui restano intrappolati i pacchetti.
 
-Se uno di questi pacchetti intrappolati è un segmento TCP, chi l'ha inviato,
-non ricevendo un ACK in risposta, provvederà alla ritrasmissione e se nel
-frattempo sarà stata stabilita una strada alternativa il pacchetto ritrasmesso
-giungerà a destinazione.
+Se uno di questi pacchetti intrappolati è un segmento TCP, chi l'ha inviato,
+non ricevendo un ACK in risposta, provvederà alla ritrasmissione e se nel
+frattempo sarà stata stabilita una strada alternativa il pacchetto ritrasmesso
+giungerà a destinazione.
 
 Ma se dopo un po' di tempo (che non supera il limite dell'MSL, dato che
 altrimenti verrebbe ecceduto il TTL) l'anomalia viene a cessare, il circolo di
 instradamento viene spezzato i pacchetti intrappolati potranno essere inviati
 alla destinazione finale, con la conseguenza di avere dei pacchetti duplicati;
-questo è un caso che il TCP deve essere in grado di gestire.
+questo è un caso che il TCP deve essere in grado di gestire.
 
 Allora per capire la seconda ragione per l'esistenza dello stato
 \texttt{TIME\_WAIT} si consideri il caso seguente: si supponga di avere una
@@ -437,7 +437,7 @@ ristabilisca la stessa connessione fra gli stessi IP sulle stesse porte
 potrebbe trovare con dei pacchetti duplicati relativi alla precedente
 connessione che riappaiono nella nuova.
 
-Ma fintanto che il socket non è chiuso una nuova incarnazione non può essere
+Ma fintanto che il socket non è chiuso una nuova incarnazione non può essere
 creata: per questo un socket TCP resta sempre nello stato \texttt{TIME\_WAIT}
 per un periodo di 2MSL, in modo da attendere MSL secondi per essere sicuri che
 tutti i pacchetti duplicati in arrivo siano stati ricevuti (e scartati) o che
@@ -453,10 +453,10 @@ rete.
 \subsection{I numeri di porta}
 \label{sec:TCP_port_num}
 
-In un ambiente multitasking in un dato momento più processi devono poter usare
-sia UDP che TCP, e ci devono poter essere più connessioni in contemporanea.
+In un ambiente multitasking in un dato momento più processi devono poter usare
+sia UDP che TCP, e ci devono poter essere più connessioni in contemporanea.
 Per poter tenere distinte le diverse connessioni entrambi i protocolli usano i
-\textsl{numeri di porta}, che fanno parte, come si può vedere in
+\textsl{numeri di porta}, che fanno parte, come si può vedere in
 sez.~\ref{sec:sock_sa_ipv4} e sez.~\ref{sec:sock_sa_ipv6} pure delle strutture
 degli indirizzi del socket.
 
@@ -467,19 +467,19 @@ identificano una serie di servizi noti (ad esempio la porta 22 identifica il
 servizio SSH) effettuati da appositi server che rispondono alle connessioni
 verso tali porte.
 
-D'altra parte un client non ha necessità di usare un numero di porta
+D'altra parte un client non ha necessità di usare un numero di porta
 specifico, per cui in genere vengono usate le cosiddette \textsl{porte
-  effimere} (o \textit{ephemeral ports}) cioè porte a cui non è assegnato
+  effimere} (o \textit{ephemeral ports}) cioè porte a cui non è assegnato
 nessun servizio noto e che vengono assegnate automaticamente dal kernel alla
 creazione della connessione. Queste sono dette effimere in quanto vengono
 usate solo per la durata della connessione, e l'unico requisito che deve
-essere soddisfatto è che ognuna di esse sia assegnata in maniera univoca.
+essere soddisfatto è che ognuna di esse sia assegnata in maniera univoca.
 
-La lista delle porte conosciute è definita
+La lista delle porte conosciute è definita
 dall'\href{http://www.ietf.org/rfc/rfc1700.txt}{RFC~1700} che contiene
 l'elenco delle porte assegnate dalla IANA (la \textit{Internet Assigned Number
   Authority}) ma l'elenco viene costantemente aggiornato e pubblicato su
-internet (una versione aggiornata si può trovare all'indirizzo
+internet (una versione aggiornata si può trovare all'indirizzo
 \href{http://www.iana.org/assignments/port-numbers}
 {\textsf{http://www.iana.org/assignments/port-numbers}}); inoltre in un
 sistema unix-like un analogo elenco viene mantenuto nel file
@@ -488,23 +488,23 @@ il nome simbolico del servizio.  I numeri sono divisi in tre intervalli:
 
 \begin{enumerate*}
 \item \textsl{le porte note}. I numeri da 0 a 1023. Queste sono controllate e
-  assegnate dalla IANA. Se è possibile la stessa porta è assegnata allo stesso
-  servizio sia su UDP che su TCP (ad esempio la porta 22 è assegnata a SSH su
+  assegnate dalla IANA. Se è possibile la stessa porta è assegnata allo stesso
+  servizio sia su UDP che su TCP (ad esempio la porta 22 è assegnata a SSH su
   entrambi i protocolli, anche se viene usata solo dal TCP).
   
 \item \textsl{le porte registrate}. I numeri da 1024 a 49151. Queste porte non
-  sono controllate dalla IANA, che però registra ed elenca chi usa queste
+  sono controllate dalla IANA, che però registra ed elenca chi usa queste
   porte come servizio agli utenti. Come per le precedenti si assegna una porta
-  ad un servizio sia per TCP che UDP anche se poi il servizio è implementato
+  ad un servizio sia per TCP che UDP anche se poi il servizio è implementato
   solo su TCP. Ad esempio X Window usa le porte TCP e UDP dal 6000 al 6063
-  anche se il protocollo è implementato solo tramite TCP.
+  anche se il protocollo è implementato solo tramite TCP.
   
 \item \textsl{le porte private} o \textsl{dinamiche}. I numeri da 49152 a
   65535. La IANA non dice nulla riguardo a queste porte che pertanto
   sono i candidati naturali ad essere usate come porte effimere.
 \end{enumerate*}
 
-In realtà rispetto a quanto indicato
+In realtà rispetto a quanto indicato
 nell'\href{http://www.ietf.org/rfc/rfc1700.txt}{RFC~1700} i vari sistemi hanno
 fatto scelte diverse per le porte effimere, in particolare in
 fig.~\ref{fig:TCP_port_alloc} sono riportate quelle di BSD e Linux.
@@ -518,8 +518,8 @@ fig.~\ref{fig:TCP_port_alloc} sono riportate quelle di BSD e Linux.
 
 I sistemi Unix hanno inoltre il concetto di \textsl{porte riservate} (che
 corrispondono alle porte con numero minore di 1024 e coincidono quindi con le
-\textsl{porte note}). La loro caratteristica è che possono essere assegnate a
-un socket solo da un processo con i privilegi di amministratore, per far sì
+\textsl{porte note}). La loro caratteristica è che possono essere assegnate a
+un socket solo da un processo con i privilegi di amministratore, per far sì
 che solo l'amministratore possa allocare queste porte per far partire i
 relativi servizi.
 
@@ -528,7 +528,7 @@ Le \textsl{glibc} definiscono (in \texttt{netinet/in.h})
 vale 1024) indica il limite superiore delle porte riservate, e la seconda (che
 vale 5000) il limite inferiore delle porte a disposizione degli utenti.  La
 convenzione vorrebbe che le porte \textsl{effimere} siano allocate fra questi
-due valori. Nel caso di Linux questo è vero solo in uno dei due casi di
+due valori. Nel caso di Linux questo è vero solo in uno dei due casi di
 fig.~\ref{fig:TCP_port_alloc}, e la scelta fra i due possibili intervalli
 viene fatta dinamicamente dal kernel a seconda della memoria disponibile per
 la gestione delle relative tabelle.
@@ -536,20 +536,20 @@ la gestione delle relative tabelle.
 Si tenga conto poi che ci sono alcuni client, in particolare \cmd{rsh} e
 \cmd{rlogin}, che richiedono una connessione su una porta riservata anche dal
 lato client come parte dell'autenticazione, contando appunto sul fatto che
-solo l'amministratore può usare queste porte. Data l'assoluta inconsistenza in
-termini di sicurezza di un tale metodo, al giorno d'oggi esso è in completo
+solo l'amministratore può usare queste porte. Data l'assoluta inconsistenza in
+termini di sicurezza di un tale metodo, al giorno d'oggi esso è in completo
 disuso.
 
 Data una connessione TCP si suole chiamare \textit{socket pair}\footnote{da
   non confondere con la coppia di socket della omonima funzione
   \func{socketpair} che fanno riferimento ad una coppia di socket sulla stessa
   macchina, non ai capi di una connessione TCP.} la combinazione dei quattro
-numeri che definiscono i due capi della connessione e cioè l'indirizzo IP
+numeri che definiscono i due capi della connessione e cioè l'indirizzo IP
 locale e la porta TCP locale, e l'indirizzo IP remoto e la porta TCP remota.
 Questa combinazione, che scriveremo usando una notazione del tipo
 (\texttt{195.110.112.152:22}, \texttt{192.84.146.100:20100}), identifica
 univocamente una connessione su internet.  Questo concetto viene di solito
-esteso anche a UDP, benché in questo caso non abbia senso parlare di
+esteso anche a UDP, benché in questo caso non abbia senso parlare di
 connessione. L'utilizzo del programma \cmd{netstat} permette di visualizzare
 queste informazioni nei campi \textit{Local Address} e \textit{Foreing
   Address}.
@@ -577,10 +577,10 @@ essendo presenti e attivi un server SSH, un server di posta e un DNS per il
 caching locale.
 
 Questo ci mostra ad esempio che il server SSH ha compiuto un'apertura passiva,
-mettendosi in ascolto sulla porta 22 riservata a questo servizio, e che si è
+mettendosi in ascolto sulla porta 22 riservata a questo servizio, e che si è
 posto in ascolto per connessioni provenienti da uno qualunque degli indirizzi
 associati alle interfacce locali. La notazione \texttt{0.0.0.0} usata da
-\cmd{netstat} è equivalente all'asterisco utilizzato per il numero di porta,
+\cmd{netstat} è equivalente all'asterisco utilizzato per il numero di porta,
 indica il valore generico, e corrisponde al valore \const{INADDR\_ANY}
 definito in \file{arpa/inet.h} (vedi \ref{tab:TCP_ipv4_addr}).
 
@@ -590,25 +590,25 @@ al socket potrebbe essere indicata come (\texttt{*:22}, \texttt{*:*}), usando
 anche per gli indirizzi l'asterisco come carattere che indica il valore
 generico.
 
-Dato che in genere una macchina è associata ad un solo indirizzo IP, ci si può
+Dato che in genere una macchina è associata ad un solo indirizzo IP, ci si può
 chiedere che senso abbia l'utilizzo dell'indirizzo generico per specificare
-l'indirizzo locale; ma a parte il caso di macchine che hanno più di un
+l'indirizzo locale; ma a parte il caso di macchine che hanno più di un
 indirizzo IP (il cosiddetto \textit{multihoming}) esiste sempre anche
 l'indirizzo di loopback, per cui con l'uso dell'indirizzo generico si possono
 accettare connessioni indirizzate verso uno qualunque degli indirizzi IP
-presenti. Ma, come si può vedere nell'esempio con il DNS che è in ascolto
-sulla porta 53, è possibile anche restringere l'accesso ad uno specifico
-indirizzo, cosa che nel caso è fatta accettando solo connessioni che arrivino
+presenti. Ma, come si può vedere nell'esempio con il DNS che è in ascolto
+sulla porta 53, è possibile anche restringere l'accesso ad uno specifico
+indirizzo, cosa che nel caso è fatta accettando solo connessioni che arrivino
 sull'interfaccia di loopback.
 
-Una volta che ci si vorrà collegare a questa macchina da un'altra, per esempio
-quella con l'indirizzo \texttt{192.84.146.100}, si dovrà lanciare su
+Una volta che ci si vorrà collegare a questa macchina da un'altra, per esempio
+quella con l'indirizzo \texttt{192.84.146.100}, si dovrà lanciare su
 quest'ultima un client \cmd{ssh} per creare una connessione, e il kernel gli
-assocerà una porta effimera (ad esempio la 21100), per cui la connessione sarà
+assocerà una porta effimera (ad esempio la 21100), per cui la connessione sarà
 espressa dalla socket pair (\texttt{192.84.146.100:21100},
 \texttt{195.110.112.152:22}).
 
-Alla ricezione della richiesta dal client il server creerà un processo figlio
+Alla ricezione della richiesta dal client il server creerà un processo figlio
 per gestire la connessione, se a questo punto eseguiamo nuovamente il
 programma \cmd{netstat} otteniamo come risultato:
 \begin{verbatim}
@@ -620,14 +620,14 @@ tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN
 tcp        0      0 195.110.112.152:22      192.84.146.100:21100    ESTABLISHED
 \end{verbatim}
 
-Come si può notare il server è ancora in ascolto sulla porta 22, però adesso
-c'è un nuovo socket (con lo stato \texttt{ESTABLISHED}) che utilizza anch'esso
-la porta 22, ed ha specificato l'indirizzo locale, questo è il socket con cui
+Come si può notare il server è ancora in ascolto sulla porta 22, però adesso
+c'è un nuovo socket (con lo stato \texttt{ESTABLISHED}) che utilizza anch'esso
+la porta 22, ed ha specificato l'indirizzo locale, questo è il socket con cui
 il processo figlio gestisce la connessione mentre il padre resta in ascolto
 sul socket originale.
 
 Se a questo punto lanciamo un'altra volta il client \cmd{ssh} per una seconda
-connessione quello che otterremo usando \cmd{netstat} sarà qualcosa del
+connessione quello che otterremo usando \cmd{netstat} sarà qualcosa del
 genere:
 \begin{verbatim}
 Active Internet connections (servers and established)
@@ -638,12 +638,12 @@ tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN
 tcp        0      0 195.110.112.152:22      192.84.146.100:21100    ESTABLISHED
 tcp        0      0 195.110.112.152:22      192.84.146.100:21101    ESTABLISHED
 \end{verbatim}
-cioè il client effettuerà la connessione usando un'altra porta effimera: con
-questa sarà aperta la connessione, ed il server creerà un altro processo
+cioè il client effettuerà la connessione usando un'altra porta effimera: con
+questa sarà aperta la connessione, ed il server creerà un altro processo
 figlio per gestirla.
 
-Tutto ciò mostra come il TCP, per poter gestire le connessioni con un server
-concorrente, non può suddividere i pacchetti solo sulla base della porta di
+Tutto ciò mostra come il TCP, per poter gestire le connessioni con un server
+concorrente, non può suddividere i pacchetti solo sulla base della porta di
 destinazione, ma deve usare tutta l'informazione contenuta nella socket pair,
 compresa la porta dell'indirizzo remoto.  E se andassimo a vedere quali sono i
 processi\footnote{ad esempio con il comando \cmd{fuser}, o con \cmd{lsof}, o
@@ -656,8 +656,8 @@ figlio e quelli che arrivano alla porta 21101 al secondo.
 \label{sec:TCP_functions}
 
 In questa sezione descriveremo in maggior dettaglio le varie funzioni che
-vengono usate per la gestione di base dei socket TCP, non torneremo però sulla
-funzione \func{socket}, che è già stata esaminata accuratamente nel capitolo
+vengono usate per la gestione di base dei socket TCP, non torneremo però sulla
+funzione \func{socket}, che è già stata esaminata accuratamente nel capitolo
 precedente in sez.~\ref{sec:sock_socket}.
 
 
@@ -666,11 +666,11 @@ precedente in sez.~\ref{sec:sock_socket}.
 
 La funzione \funcd{bind} assegna un indirizzo locale ad un
 socket.\footnote{nel nostro caso la utilizzeremo per socket TCP, ma la
-  funzione è generica e deve essere usata per qualunque tipo di socket
-  \const{SOCK\_STREAM} prima che questo possa accettare connessioni.} È usata
-cioè per specificare la prima parte dalla socket pair.  Viene usata sul lato
+  funzione è generica e deve essere usata per qualunque tipo di socket
+  \const{SOCK\_STREAM} prima che questo possa accettare connessioni.} È usata
+cioè per specificare la prima parte dalla socket pair.  Viene usata sul lato
 server per specificare la porta (e gli eventuali indirizzi locali) su cui poi
-ci si porrà in ascolto. Il prototipo della funzione è il seguente:
+ci si porrà in ascolto. Il prototipo della funzione è il seguente:
 \begin{prototype}{sys/socket.h}
 {int bind(int sockfd, const struct sockaddr *serv\_addr, socklen\_t addrlen)}
   
@@ -680,63 +680,63 @@ ci si porr
     in caso di errore la variabile \var{errno} viene impostata secondo i
     seguenti codici di errore:
   \begin{errlist}
-  \item[\errcode{EBADF}] il file descriptor non è valido.
-  \item[\errcode{EINVAL}] il socket ha già un indirizzo assegnato.
-  \item[\errcode{ENOTSOCK}] il file descriptor non è associato ad un socket.
-  \item[\errcode{EACCES}] si è cercato di usare una porta riservata senza
+  \item[\errcode{EBADF}] il file descriptor non è valido.
+  \item[\errcode{EINVAL}] il socket ha già un indirizzo assegnato.
+  \item[\errcode{ENOTSOCK}] il file descriptor non è associato ad un socket.
+  \item[\errcode{EACCES}] si è cercato di usare una porta riservata senza
     sufficienti privilegi.
-  \item[\errcode{EADDRNOTAVAIL}] il tipo di indirizzo specificato non è
+  \item[\errcode{EADDRNOTAVAIL}] il tipo di indirizzo specificato non è
     disponibile.
-  \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo.
+  \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo.
   \end{errlist}
   ed anche \errval{EFAULT} e per i socket di tipo \const{AF\_UNIX},
   \errval{ENOTDIR}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ELOOP},
   \errval{ENOSR} e \errval{EROFS}.}
 \end{prototype}
 
-Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
+Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
 \func{socket}, mentre il secondo e terzo argomento sono rispettivamente
 l'indirizzo (locale) del socket e la dimensione della struttura che lo
-contiene, secondo quanto già trattato in sez.~\ref{sec:sock_sockaddr}. 
+contiene, secondo quanto già trattato in sez.~\ref{sec:sock_sockaddr}. 
 
 Con i socket TCP la chiamata \func{bind} permette di specificare l'indirizzo,
 la porta, entrambi o nessuno dei due. In genere i server utilizzano una porta
-nota che assegnano all'avvio, se questo non viene fatto è il kernel a
+nota che assegnano all'avvio, se questo non viene fatto è il kernel a
 scegliere una porta effimera quando vengono eseguite la funzioni
-\func{connect} o \func{listen}, ma se questo è normale per il client non lo è
-per il server\footnote{un'eccezione a tutto ciò sono i server che usano RPC.
+\func{connect} o \func{listen}, ma se questo è normale per il client non lo è
+per il server\footnote{un'eccezione a tutto ciò sono i server che usano RPC.
   In questo caso viene fatta assegnare dal kernel una porta effimera che poi
-  viene registrata presso il \textit{portmapper}; quest'ultimo è un altro
+  viene registrata presso il \textit{portmapper}; quest'ultimo è un altro
   demone che deve essere contattato dai client per ottenere la porta effimera
   su cui si trova il server.} che in genere viene identificato dalla porta su
-cui risponde (l'elenco di queste porte, e dei relativi servizi, è in
+cui risponde (l'elenco di queste porte, e dei relativi servizi, è in
 \conffile{/etc/services}).
 
-Con \func{bind} si può assegnare un indirizzo IP specifico ad un socket,
-purché questo appartenga ad una interfaccia della macchina.  Per un client TCP
-questo diventerà l'indirizzo sorgente usato per i tutti i pacchetti inviati
-sul socket, mentre per un server TCP questo restringerà l'accesso al socket
+Con \func{bind} si può assegnare un indirizzo IP specifico ad un socket,
+purché questo appartenga ad una interfaccia della macchina.  Per un client TCP
+questo diventerà l'indirizzo sorgente usato per i tutti i pacchetti inviati
+sul socket, mentre per un server TCP questo restringerà l'accesso al socket
 solo alle connessioni che arrivano verso tale indirizzo.
 
 Normalmente un client non specifica mai l'indirizzo di un socket, ed il kernel
 sceglie l'indirizzo di origine quando viene effettuata la connessione, sulla
-base dell'interfaccia usata per trasmettere i pacchetti, (che dipenderà dalle
+base dell'interfaccia usata per trasmettere i pacchetti, (che dipenderà dalle
 regole di instradamento usate per raggiungere il server).  Se un server non
-specifica il suo indirizzo locale il kernel userà come indirizzo di origine
+specifica il suo indirizzo locale il kernel userà come indirizzo di origine
 l'indirizzo di destinazione specificato dal SYN del client.
 
 Per specificare un indirizzo generico, con IPv4 si usa il valore
 \const{INADDR\_ANY}, il cui valore, come accennato in
-sez.~\ref{sec:sock_sa_ipv4}, è pari a zero; nell'esempio
-fig.~\ref{fig:TCP_daytime_iter_server_code} si è usata un'assegnazione
+sez.~\ref{sec:sock_sa_ipv4}, è pari a zero; nell'esempio
+fig.~\ref{fig:TCP_daytime_iter_server_code} si è usata un'assegnazione
 immediata del tipo: \includecodesnip{listati/serv_addr_sin_addr.c}
 
-Si noti che si è usato \func{htonl} per assegnare il valore
-\const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è
+Si noti che si è usato \func{htonl} per assegnare il valore
+\const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è
 inutile.  Si tenga presente comunque che tutte le costanti \val{INADDR\_}
 (riportate in tab.~\ref{tab:TCP_ipv4_addr}) sono definite secondo
 \itindex{endianess} l'\textit{endianess} della macchina, ed anche se esse
-possono essere invarianti rispetto all'ordinamento dei bit, è comunque buona
+possono essere invarianti rispetto all'ordinamento dei bit, è comunque buona
 norma usare sempre la funzione \func{htonl}.
 
 \begin{table}[htb]
@@ -759,17 +759,17 @@ norma usare sempre la funzione \func{htonl}.
   \label{tab:TCP_ipv4_addr}
 \end{table}
 
-L'esempio precedente funziona correttamente con IPv4 poiché che l'indirizzo è
-rappresentabile anche con un intero a 32 bit; non si può usare lo stesso
+L'esempio precedente funziona correttamente con IPv4 poiché che l'indirizzo è
+rappresentabile anche con un intero a 32 bit; non si può usare lo stesso
 metodo con IPv6, in cui l'indirizzo deve necessariamente essere specificato
-con una struttura, perché il linguaggio C non consente l'uso di una struttura
+con una struttura, perché il linguaggio C non consente l'uso di una struttura
 costante come operando a destra in una assegnazione.
 
-Per questo motivo nell'header \file{netinet/in.h} è definita una variabile
+Per questo motivo nell'header \file{netinet/in.h} è definita una variabile
 \macro{in6addr\_any} (dichiarata come \direct{extern}, ed inizializzata dal
 sistema al valore \const{IN6ADRR\_ANY\_INIT}) che permette di effettuare una
 assegnazione del tipo: \includecodesnip{listati/serv_addr_sin6_addr.c} in
-maniera analoga si può utilizzare la variabile \macro{in6addr\_loopback} per
+maniera analoga si può utilizzare la variabile \macro{in6addr\_loopback} per
 indicare l'indirizzo di \textit{loopback}, che a sua volta viene inizializzata
 staticamente a \const{IN6ADRR\_LOOPBACK\_INIT}.
 
@@ -777,15 +777,15 @@ staticamente a \const{IN6ADRR\_LOOPBACK\_INIT}.
 \subsection{La funzione \func{connect}}
 \label{sec:TCP_func_connect}
 
-La funzione \funcd{connect} è usata da un client TCP per stabilire la
-connessione con un server TCP,\footnote{di nuovo la funzione è generica e
-  supporta vari tipi di socket, la differenza è che per socket senza
+La funzione \funcd{connect} è usata da un client TCP per stabilire la
+connessione con un server TCP,\footnote{di nuovo la funzione è generica e
+  supporta vari tipi di socket, la differenza è che per socket senza
   connessione come quelli di tipo \const{SOCK\_DGRAM} la sua chiamata si
-  limiterà ad impostare l'indirizzo dal quale e verso il quale saranno inviati
+  limiterà ad impostare l'indirizzo dal quale e verso il quale saranno inviati
   e ricevuti i pacchetti, mentre per socket di tipo \const{SOCK\_STREAM} o
-  \const{SOCK\_SEQPACKET}, essa attiverà la procedura di avvio (nel caso del
+  \const{SOCK\_SEQPACKET}, essa attiverà la procedura di avvio (nel caso del
   TCP il \itindex{three~way~handshake} \textit{three way handshake}) della
-  connessione.}  il prototipo della funzione è il seguente:
+  connessione.}  il prototipo della funzione è il seguente:
 \begin{prototype}{sys/socket.h}
   {int connect(int sockfd, const struct sockaddr *servaddr, socklen\_t
     addrlen)}
@@ -793,23 +793,23 @@ connessione con un server TCP,\footnote{di nuovo la funzione 
   Stabilisce una connessione fra due socket.
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
-  \item[\errcode{ECONNREFUSED}] non c'è nessuno in ascolto sull'indirizzo
+  \item[\errcode{ECONNREFUSED}] non c'è nessuno in ascolto sull'indirizzo
     remoto.
-  \item[\errcode{ETIMEDOUT}] si è avuto timeout durante il tentativo di
+  \item[\errcode{ETIMEDOUT}] si è avuto timeout durante il tentativo di
     connessione.
-  \item[\errcode{ENETUNREACH}] la rete non è raggiungibile.
-  \item[\errcode{EINPROGRESS}] il socket è non bloccante (vedi
-    sez.~\ref{sec:file_noblocking}) e la connessione non può essere conclusa
+  \item[\errcode{ENETUNREACH}] la rete non è raggiungibile.
+  \item[\errcode{EINPROGRESS}] il socket è non bloccante (vedi
+    sez.~\ref{sec:file_noblocking}) e la connessione non può essere conclusa
     immediatamente.
-  \item[\errcode{EALREADY}] il socket è non bloccante (vedi
+  \item[\errcode{EALREADY}] il socket è non bloccante (vedi
     sez.~\ref{sec:file_noblocking}) e un tentativo precedente di connessione
-    non si è ancora concluso.
-  \item[\errcode{EAGAIN}] non ci sono più porte locali libere. 
+    non si è ancora concluso.
+  \item[\errcode{EAGAIN}] non ci sono più porte locali libere. 
   \item[\errcode{EAFNOSUPPORT}] l'indirizzo non ha una famiglia di indirizzi
     corretta nel relativo campo.
-  \item[\errcode{EACCES}, \errcode{EPERM}] si è tentato di eseguire una
+  \item[\errcode{EACCES}, \errcode{EPERM}] si è tentato di eseguire una
     connessione ad un indirizzo \itindex{broadcast} \textit{broadcast} senza
     che il socket fosse stato abilitato per il \itindex{broadcast}
     \textit{broadcast}.
@@ -818,10 +818,10 @@ connessione con un server TCP,\footnote{di nuovo la funzione 
   \errval{ENOTSOCK}, \errval{EISCONN} e \errval{EADDRINUSE}.}
 \end{prototype}
 
-Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
+Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
 \func{socket}, mentre il secondo e terzo argomento sono rispettivamente
 l'indirizzo e la dimensione della struttura che contiene l'indirizzo del
-socket, già descritta in sez.~\ref{sec:sock_sockaddr}.
+socket, già descritta in sez.~\ref{sec:sock_sockaddr}.
 
 La struttura dell'indirizzo deve essere inizializzata con l'indirizzo IP e il
 numero di porta del server a cui ci si vuole connettere, come mostrato
@@ -830,40 +830,40 @@ in sez.~\ref{sec:sock_addr_func}.
 
 Nel caso di socket TCP la funzione \func{connect} avvia il
 \itindex{three~way~handshake} \textit{three way handshake}, e ritorna solo
-quando la connessione è stabilita o si è verificato un errore. Le possibili
+quando la connessione è stabilita o si è verificato un errore. Le possibili
 cause di errore sono molteplici (ed i relativi codici riportati sopra), quelle
-che però dipendono dalla situazione della rete e non da errori o problemi
+che però dipendono dalla situazione della rete e non da errori o problemi
 nella chiamata della funzione sono le seguenti:
 \begin{enumerate}
-\item Il client non riceve risposta al SYN: l'errore restituito è
+\item Il client non riceve risposta al SYN: l'errore restituito è
   \errcode{ETIMEDOUT}. Stevens riporta che BSD invia un primo SYN alla
   chiamata di \func{connect}, un altro dopo 6 secondi, un terzo dopo 24
   secondi, se dopo 75 secondi non ha ricevuto risposta viene ritornato
   l'errore. Linux invece ripete l'emissione del SYN ad intervalli di 30
-  secondi per un numero di volte che può essere stabilito dall'utente. Questo
-  può essere fatto a livello globale con una opportuna
-  \func{sysctl},\footnote{o più semplicemente scrivendo il valore voluto in
+  secondi per un numero di volte che può essere stabilito dall'utente. Questo
+  può essere fatto a livello globale con una opportuna
+  \func{sysctl},\footnote{o più semplicemente scrivendo il valore voluto in
     \procfile{/proc/sys/net/ipv4/tcp\_syn\_retries}, vedi
     sez.~\ref{sec:sock_ipv4_sysctl}.} e a livello di singolo socket con
   l'opzione \const{TCP\_SYNCNT} (vedi sez.~\ref{sec:sock_tcp_udp_options}). Il
-  valore predefinito per la ripetizione dell'invio è di 5 volte, che comporta
+  valore predefinito per la ripetizione dell'invio è di 5 volte, che comporta
   un timeout dopo circa 180 secondi.
 
-\item Il client riceve come risposta al SYN un RST significa che non c'è
+\item Il client riceve come risposta al SYN un RST significa che non c'è
   nessun programma in ascolto per la connessione sulla porta specificata (il
-  che vuol dire probabilmente che o si è sbagliato il numero della porta o che
-  non è stato avviato il server), questo è un errore fatale e la funzione
+  che vuol dire probabilmente che o si è sbagliato il numero della porta o che
+  non è stato avviato il server), questo è un errore fatale e la funzione
   ritorna non appena il RST viene ricevuto riportando un errore
   \errcode{ECONNREFUSED}.
   
-  Il flag RST sta per \textit{reset} ed è un segmento inviato direttamente
+  Il flag RST sta per \textit{reset} ed è un segmento inviato direttamente
   dal TCP quando qualcosa non va. Tre condizioni che generano un RST sono:
   quando arriva un SYN per una porta che non ha nessun server in ascolto,
   quando il TCP abortisce una connessione in corso, quando TCP riceve un
   segmento per una connessione che non esiste.
   
 \item Il SYN del client provoca l'emissione di un messaggio ICMP di
-  destinazione non raggiungibile. In questo caso dato che il messaggio può
+  destinazione non raggiungibile. In questo caso dato che il messaggio può
   essere dovuto ad una condizione transitoria si ripete l'emissione dei SYN
   come nel caso precedente, fino al timeout, e solo allora si restituisce il
   codice di errore dovuto al messaggio ICMP, che da luogo ad un
@@ -876,77 +876,77 @@ fig.~\ref{fig:TCP_state_diag} la funzione \func{connect} porta un socket
 dallo stato \texttt{CLOSED} (lo stato iniziale in cui si trova un socket
 appena creato) prima allo stato \texttt{SYN\_SENT} e poi, al ricevimento del
 ACK, nello stato \texttt{ESTABLISHED}. Se invece la connessione fallisce il
-socket non è più utilizzabile e deve essere chiuso.
+socket non è più utilizzabile e deve essere chiuso.
 
-Si noti infine che con la funzione \func{connect} si è specificato solo
-indirizzo e porta del server, quindi solo una metà della socket pair; essendo
-questa funzione usata nei client l'altra metà contenente indirizzo e porta
-locale viene lasciata all'assegnazione automatica del kernel, e non è
+Si noti infine che con la funzione \func{connect} si è specificato solo
+indirizzo e porta del server, quindi solo una metà della socket pair; essendo
+questa funzione usata nei client l'altra metà contenente indirizzo e porta
+locale viene lasciata all'assegnazione automatica del kernel, e non è
 necessario effettuare una \func{bind}.
 
 
 \subsection{La funzione \func{listen}}
 \label{sec:TCP_func_listen}
 
-La funzione \funcd{listen} serve ad usare un socket in modalità passiva, cioè,
+La funzione \funcd{listen} serve ad usare un socket in modalità passiva, cioè,
 come dice il nome, per metterlo in ascolto di eventuali
-connessioni;\footnote{questa funzione può essere usata con socket che
-  supportino le connessioni, cioè di tipo \const{SOCK\_STREAM} o
-  \const{SOCK\_SEQPACKET}.} in sostanza l'effetto della funzione è di portare
+connessioni;\footnote{questa funzione può essere usata con socket che
+  supportino le connessioni, cioè di tipo \const{SOCK\_STREAM} o
+  \const{SOCK\_SEQPACKET}.} in sostanza l'effetto della funzione è di portare
 il socket dallo stato \texttt{CLOSED} a quello \texttt{LISTEN}. In genere si
 chiama la funzione in un server dopo le chiamate a \func{socket} e \func{bind}
 e prima della chiamata ad \func{accept}. Il prototipo della funzione, come
-definito dalla pagina di manuale, è:
+definito dalla pagina di manuale, è:
 \begin{prototype}{sys/socket.h}{int listen(int sockfd, int backlog)}
   Pone un socket in attesa di una connessione.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
     errore. I codici di errore restituiti in \var{errno} sono i seguenti:
   \begin{errlist}
-  \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
+  \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
     valido.
-  \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
-  \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
+  \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
+  \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
     operazione.
   \end{errlist}}
 \end{prototype}
 
-La funzione pone il socket specificato da \param{sockfd} in modalità passiva e
+La funzione pone il socket specificato da \param{sockfd} in modalità passiva e
 predispone una coda per le connessioni in arrivo di lunghezza pari a
-\param{backlog}. La funzione si può applicare solo a socket di tipo
+\param{backlog}. La funzione si può applicare solo a socket di tipo
 \const{SOCK\_STREAM} o \const{SOCK\_SEQPACKET}.
 
 L'argomento \param{backlog} indica il numero massimo di connessioni pendenti
 accettate; se esso viene ecceduto il client al momento della richiesta della
-connessione riceverà un errore di tipo \errcode{ECONNREFUSED}, o se il
+connessione riceverà un errore di tipo \errcode{ECONNREFUSED}, o se il
 protocollo, come accade nel caso del TCP, supporta la ritrasmissione, la
-richiesta sarà ignorata in modo che la connessione possa venire ritentata.
+richiesta sarà ignorata in modo che la connessione possa venire ritentata.
 
-Per capire meglio il significato di tutto ciò occorre approfondire la modalità
+Per capire meglio il significato di tutto ciò occorre approfondire la modalità
 con cui il kernel tratta le connessioni in arrivo. Per ogni socket in ascolto
 infatti vengono mantenute due code:
 \begin{enumerate}
 \item La coda delle connessioni incomplete (\textit{incomplete connection
-    queue}) che contiene un riferimento per ciascun socket per il quale è
+    queue}) che contiene un riferimento per ciascun socket per il quale è
   arrivato un SYN ma il \itindex{three~way~handshake} \textit{three way
-    handshake} non si è ancora concluso.  Questi socket sono tutti nello stato
+    handshake} non si è ancora concluso.  Questi socket sono tutti nello stato
   \texttt{SYN\_RECV}.
 \item La coda delle connessioni complete (\textit{complete connection queue})
   che contiene un ingresso per ciascun socket per il quale il
-  \itindex{three~way~handshake} \textit{three way handshake} è stato
-  completato ma ancora \func{accept} non è ritornata.  Questi socket sono
+  \itindex{three~way~handshake} \textit{three way handshake} è stato
+  completato ma ancora \func{accept} non è ritornata.  Questi socket sono
   tutti nello stato \texttt{ESTABLISHED}.
 \end{enumerate}
 
-Lo schema di funzionamento è descritto in fig.~\ref{fig:TCP_listen_backlog}:
+Lo schema di funzionamento è descritto in fig.~\ref{fig:TCP_listen_backlog}:
 quando arriva un SYN da un client il server crea una nuova voce nella coda
-delle connessioni incomplete, e poi risponde con il SYN$+$ACK. La voce resterà
+delle connessioni incomplete, e poi risponde con il SYN$+$ACK. La voce resterà
 nella coda delle connessioni incomplete fino al ricevimento dell'ACK dal
 client o fino ad un timeout. Nel caso di completamento del
 \itindex{three~way~handshake} \textit{three way handshake} la voce viene
 spostata nella coda delle connessioni complete.  Quando il processo chiama la
 funzione \func{accept} (vedi sez.~\ref{sec:TCP_func_accept}) la prima voce
-nella coda delle connessioni complete è passata al programma, o, se la coda è
+nella coda delle connessioni complete è passata al programma, o, se la coda è
 vuota, il processo viene posto in attesa e risvegliato all'arrivo della prima
 connessione completa.
 
@@ -965,68 +965,68 @@ code. Stevens in \cite{UNP1} riporta che BSD ha sempre applicato un fattore di
 kernel, compreso Linux 2.0, che mostrano le differenze fra diverse
 implementazioni.
 
-In Linux il significato di questo valore è cambiato a partire dal kernel 2.2
+In Linux il significato di questo valore è cambiato a partire dal kernel 2.2
 per prevenire l'attacco chiamato \index{SYN~flood} \textit{SYN flood}. Questo
 si basa sull'emissione da parte dell'attaccante di un grande numero di
 pacchetti SYN indirizzati verso una porta, forgiati con indirizzo IP
-fasullo\footnote{con la tecnica che viene detta \textit{ip spoofing}.} così
+fasullo\footnote{con la tecnica che viene detta \textit{ip spoofing}.} così
 che i SYN$+$ACK vanno perduti e la coda delle connessioni incomplete viene
 saturata, impedendo di fatto ulteriori connessioni.
 
-Per ovviare a questo il significato del \param{backlog} è stato cambiato a
+Per ovviare a questo il significato del \param{backlog} è stato cambiato a
 indicare la lunghezza della coda delle connessioni complete. La lunghezza
-della coda delle connessioni incomplete può essere ancora controllata usando
+della coda delle connessioni incomplete può essere ancora controllata usando
 la funzione \func{sysctl} con il parametro \const{NET\_TCP\_MAX\_SYN\_BACKLOG}
 o scrivendola direttamente in
 \procfile{/proc/sys/net/ipv4/tcp\_max\_syn\_backlog}.  Quando si attiva la
-protezione dei syncookies però (con l'opzione da compilare nel kernel e da
+protezione dei syncookies però (con l'opzione da compilare nel kernel e da
 attivare usando \procfile{/proc/sys/net/ipv4/tcp\_syncookies}) questo valore
-viene ignorato e non esiste più un valore massimo.  In ogni caso in Linux il
+viene ignorato e non esiste più un valore massimo.  In ogni caso in Linux il
 valore di \param{backlog} viene troncato ad un massimo di \const{SOMAXCONN} se
-è superiore a detta costante (che di default vale 128).\footnote{il valore di
-  questa costante può essere controllato con un altro parametro di
+è superiore a detta costante (che di default vale 128).\footnote{il valore di
+  questa costante può essere controllato con un altro parametro di
   \func{sysctl}, vedi sez.~\ref{sec:sock_ioctl_IP}.}
 
 La scelta storica per il valore di questo parametro era di 5, e alcuni vecchi
-kernel non supportavano neanche valori superiori, ma la situazione corrente è
+kernel non supportavano neanche valori superiori, ma la situazione corrente è
 molto cambiata per via della presenza di server web che devono gestire un gran
-numero di connessioni per cui un tale valore non è più adeguato. Non esiste
+numero di connessioni per cui un tale valore non è più adeguato. Non esiste
 comunque una risposta univoca per la scelta del valore, per questo non
 conviene specificarlo con una costante (il cui cambiamento richiederebbe la
 ricompilazione del server) ma usare piuttosto una variabile di ambiente (vedi
 sez.~\ref{sec:proc_environ}).
 
 Stevens tratta accuratamente questo argomento in \cite{UNP1}, con esempi presi
-da casi reali su web server, ed in particolare evidenzia come non sia più vero
+da casi reali su web server, ed in particolare evidenzia come non sia più vero
 che il compito principale della coda sia quello di gestire il caso in cui il
-server è occupato fra chiamate successive alla \func{accept} (per cui la coda
-più occupata sarebbe quella delle connessioni completate), ma piuttosto quello
+server è occupato fra chiamate successive alla \func{accept} (per cui la coda
+più occupata sarebbe quella delle connessioni completate), ma piuttosto quello
 di gestire la presenza di un gran numero di SYN in attesa di concludere il
 \itindex{three~way~handshake} \textit{three way handshake}.
 
 Infine va messo in evidenza che, nel caso di socket TCP, quando un SYN arriva
-con tutte le code piene, il pacchetto deve essere ignorato. Questo perché la
-condizione in cui le code sono piene è ovviamente transitoria, per cui se il
-client ritrasmette il SYN è probabile che passato un po' di tempo possa
+con tutte le code piene, il pacchetto deve essere ignorato. Questo perché la
+condizione in cui le code sono piene è ovviamente transitoria, per cui se il
+client ritrasmette il SYN è probabile che passato un po' di tempo possa
 trovare nella coda lo spazio per una nuova connessione. Se invece si
-rispondesse con un RST, per indicare l'impossibilità di effettuare la
+rispondesse con un RST, per indicare l'impossibilità di effettuare la
 connessione, la chiamata a \func{connect} nel client ritornerebbe con una
 condizione di errore, costringendo a inserire nell'applicazione la gestione
-dei tentativi di riconnessione, che invece può essere effettuata in maniera
+dei tentativi di riconnessione, che invece può essere effettuata in maniera
 trasparente dal protocollo TCP.
 
 
 \subsection{La funzione \func{accept}}
 \label{sec:TCP_func_accept}
 
-La funzione \funcd{accept} è chiamata da un server per gestire la connessione
+La funzione \funcd{accept} è chiamata da un server per gestire la connessione
 una volta che sia stato completato il \itindex{three~way~handshake}
-\textit{three way handshake},\footnote{la funzione è comunque generica ed è
+\textit{three way handshake},\footnote{la funzione è comunque generica ed è
   utilizzabile su socket di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET}
   e \const{SOCK\_RDM}.} la funzione restituisce un nuovo socket descriptor su
-cui si potrà operare per effettuare la comunicazione. Se non ci sono
+cui si potrà operare per effettuare la comunicazione. Se non ci sono
 connessioni completate il processo viene messo in attesa. Il prototipo della
-funzione è il seguente:
+funzione è il seguente:
 \begin{prototype}{sys/socket.h}
 {int accept(int sockfd, struct sockaddr *addr, socklen\_t *addrlen)} 
  
@@ -1037,19 +1037,19 @@ funzione 
     impostata ai seguenti valori:
 
   \begin{errlist}
-  \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
+  \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
     valido.
-  \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
-  \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
+  \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
+  \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
     operazione.
-  \item[\errcode{EAGAIN} o \errcode{EWOULDBLOCK}] il socket è stato impostato
+  \item[\errcode{EAGAIN} o \errcode{EWOULDBLOCK}] il socket è stato impostato
     come non bloccante (vedi sez.~\ref{sec:file_noblocking}), e non ci sono
     connessioni in attesa di essere accettate.
   \item[\errcode{EPERM}] le regole del firewall non consentono la connessione.
   \item[\errcode{ENOBUFS}, \errcode{ENOMEM}] questo spesso significa che
-    l'allocazione della memoria è limitata dai limiti sui buffer dei socket,
+    l'allocazione della memoria è limitata dai limiti sui buffer dei socket,
     non dalla memoria di sistema.
-  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+  \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
   \end{errlist}
   Inoltre possono essere restituiti gli errori di rete relativi al nuovo
   socket, diversi a secondo del protocollo, come: \errval{EMFILE},
@@ -1064,32 +1064,32 @@ le stesse caratteristiche di \param{sockfd}.  Il socket originale non viene
 toccato e resta nello stato di \texttt{LISTEN}, mentre il nuovo socket viene
 posto nello stato \texttt{ESTABLISHED}. Nella struttura \param{addr} e nella
 variabile \param{addrlen} vengono restituiti indirizzo e relativa lunghezza
-del client che si è connesso.
+del client che si è connesso.
 
-I due argomenti \param{addr} e \param{addrlen} (si noti che quest'ultimo è
+I due argomenti \param{addr} e \param{addrlen} (si noti che quest'ultimo è
 passato per indirizzo per avere indietro il valore) sono usati per ottenere
 l'indirizzo del client da cui proviene la connessione. Prima della chiamata
 \param{addrlen} deve essere inizializzato alle dimensioni della struttura il
-cui indirizzo è passato come argomento in \param{addr}; al ritorno della
-funzione \param{addrlen} conterrà il numero di byte scritti dentro
-\param{addr}. Se questa informazione non interessa basterà inizializzare a
+cui indirizzo è passato come argomento in \param{addr}; al ritorno della
+funzione \param{addrlen} conterrà il numero di byte scritti dentro
+\param{addr}. Se questa informazione non interessa basterà inizializzare a
 \val{NULL} detti puntatori.
 
 Se la funzione ha successo restituisce il descrittore di un nuovo socket
 creato dal kernel (detto \textit{connected socket}) a cui viene associata la
 prima connessione completa (estratta dalla relativa coda, vedi
 sez.~\ref{sec:TCP_func_listen}) che il client ha effettuato verso il socket
-\param{sockfd}. Quest'ultimo (detto \textit{listening socket}) è quello creato
+\param{sockfd}. Quest'ultimo (detto \textit{listening socket}) è quello creato
 all'inizio e messo in ascolto con \func{listen}, e non viene toccato dalla
 funzione.  Se non ci sono connessioni pendenti da accettare la funzione mette
 in attesa il processo\footnote{a meno che non si sia impostato il socket per
   essere non bloccante (vedi sez.~\ref{sec:file_noblocking}), nel qual caso
-  ritorna con l'errore \errcode{EAGAIN}.  Torneremo su questa modalità di
+  ritorna con l'errore \errcode{EAGAIN}.  Torneremo su questa modalità di
   operazione in sez.~\ref{sec:TCP_sock_multiplexing}.}  fintanto che non ne
 arriva una.
 
-La funzione può essere usata solo con socket che supportino la connessione
-(cioè di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET} o
+La funzione può essere usata solo con socket che supportino la connessione
+(cioè di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET} o
 \const{SOCK\_RDM}). Per alcuni protocolli che richiedono una conferma
 esplicita della connessione,\footnote{attualmente in Linux solo DECnet ha
   questo comportamento.} la funzione opera solo l'estrazione dalla coda delle
@@ -1097,26 +1097,26 @@ connessioni, la conferma della connessione viene eseguita implicitamente dalla
 prima chiamata ad una \func{read} o una \func{write}, mentre il rifiuto della
 connessione viene eseguito con la funzione \func{close}.
 
-È da chiarire che Linux presenta un comportamento diverso nella gestione degli
+È da chiarire che Linux presenta un comportamento diverso nella gestione degli
 errori rispetto ad altre implementazioni dei socket BSD, infatti la funzione
 \func{accept} passa gli errori di rete pendenti sul nuovo socket come codici
 di errore per \func{accept}, per cui l'applicazione deve tenerne conto ed
 eventualmente ripetere la chiamata alla funzione come per l'errore di
 \errcode{EAGAIN} (torneremo su questo in sez.~\ref{sec:TCP_echo_critical}).
-Un'altra differenza con BSD è che la funzione non fa ereditare al nuovo socket
+Un'altra differenza con BSD è che la funzione non fa ereditare al nuovo socket
 i flag del socket originale, come \const{O\_NONBLOCK},\footnote{ed in generale
   tutti quelli che si possono impostare con \func{fcntl}, vedi
   sez.~\ref{sec:file_fcntl}.} che devono essere rispecificati ogni volta. Tutto
 questo deve essere tenuto in conto se si devono scrivere programmi portabili.
 
-Il meccanismo di funzionamento di \func{accept} è essenziale per capire il
-funzionamento di un server: in generale infatti c'è sempre un solo socket in
+Il meccanismo di funzionamento di \func{accept} è essenziale per capire il
+funzionamento di un server: in generale infatti c'è sempre un solo socket in
 ascolto, detto per questo \textit{listening socket}, che resta per tutto il
 tempo nello stato \texttt{LISTEN}, mentre le connessioni vengono gestite dai
 nuovi socket, detti \textit{connected socket}, ritornati da \func{accept}, che
 si trovano automaticamente nello stato \texttt{ESTABLISHED}, e vengono
 utilizzati per lo scambio dei dati, che avviene su di essi, fino alla chiusura
-della connessione.  Si può riconoscere questo schema anche nell'esempio
+della connessione.  Si può riconoscere questo schema anche nell'esempio
 elementare di fig.~\ref{fig:TCP_daytime_iter_server_code}, dove per ogni
 connessione il socket creato da \func{accept} viene chiuso dopo l'invio dei
 dati.
@@ -1128,11 +1128,11 @@ dati.
 Oltre a tutte quelle viste finora, dedicate all'utilizzo dei socket, esistono
 alcune funzioni ausiliarie che possono essere usate per recuperare alcune
 informazioni relative ai socket ed alle connessioni ad essi associate. Le due
-funzioni più elementari sono queste, che vengono usate per ottenere i dati
+funzioni più elementari sono queste, che vengono usate per ottenere i dati
 relativi alla socket pair associata ad un certo socket.
 
-La prima funzione è \funcd{getsockname} e serve ad ottenere l'indirizzo locale
-associato ad un socket; il suo prototipo è:
+La prima funzione è \funcd{getsockname} e serve ad ottenere l'indirizzo locale
+associato ad un socket; il suo prototipo è:
 \begin{prototype}{sys/socket.h}
   {int getsockname(int sockfd, struct sockaddr *name, socklen\_t *namelen)}
   Legge l'indirizzo locale di un socket.
@@ -1140,25 +1140,25 @@ associato ad un socket; il suo prototipo 
 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
   errore. I codici di errore restituiti in \var{errno} sono i seguenti:
   \begin{errlist}
-  \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
+  \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
     valido.
-  \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
+  \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
   \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
     eseguire l'operazione.
-  \item[\errcode{EFAULT}] l'indirizzo \param{name} non è valido.
+  \item[\errcode{EFAULT}] l'indirizzo \param{name} non è valido.
   \end{errlist}}
 \end{prototype}
 
 La funzione restituisce la struttura degli indirizzi del socket \param{sockfd}
-nella struttura indicata dal puntatore \param{name} la cui lunghezza è
+nella struttura indicata dal puntatore \param{name} la cui lunghezza è
 specificata tramite l'argomento \param{namlen}. Quest'ultimo viene passato
 come indirizzo per avere indietro anche il numero di byte effettivamente
-scritti nella struttura puntata da \param{name}. Si tenga presente che se si è
-utilizzato un buffer troppo piccolo per \param{name} l'indirizzo risulterà
+scritti nella struttura puntata da \param{name}. Si tenga presente che se si è
+utilizzato un buffer troppo piccolo per \param{name} l'indirizzo risulterà
 troncato.
 
 La funzione si usa tutte le volte che si vuole avere l'indirizzo locale di un
-socket; ad esempio può essere usata da un client (che usualmente non chiama
+socket; ad esempio può essere usata da un client (che usualmente non chiama
 \func{bind}) per ottenere numero IP e porta locale associati al socket
 restituito da una \func{connect}, o da un server che ha chiamato \func{bind}
 su un socket usando 0 come porta locale per ottenere il numero di porta
@@ -1170,7 +1170,7 @@ chiamata dopo il completamento di una connessione sul socket restituito da
 quella connessione.
 
 Tutte le volte che si vuole avere l'indirizzo remoto di un socket si usa la
-funzione \funcd{getpeername}, il cui prototipo è:
+funzione \funcd{getpeername}, il cui prototipo è:
 \begin{prototype}{sys/socket.h}
   {int getpeername(int sockfd, struct sockaddr * name, socklen\_t * namelen)}
   Legge l'indirizzo remoto di un socket.
@@ -1178,10 +1178,10 @@ funzione \funcd{getpeername}, il cui prototipo 
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
     errore. I codici di errore restituiti in \var{errno} sono i seguenti:
   \begin{errlist}
-  \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
+  \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
     valido.
-  \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
-  \item[\errcode{ENOTCONN}] il socket non è connesso.
+  \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
+  \item[\errcode{ENOTCONN}] il socket non è connesso.
   \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
     eseguire l'operazione.
   \item[\errcode{EFAULT}] l'argomento \param{name} punta al di fuori dello
@@ -1189,38 +1189,38 @@ funzione \funcd{getpeername}, il cui prototipo 
   \end{errlist}}
 \end{prototype}
 
-La funzione è identica a \func{getsockname}, ed usa la stessa sintassi, ma
-restituisce l'indirizzo remoto del socket, cioè quello associato all'altro
-capo della connessione.  Ci si può chiedere a cosa serva questa funzione dato
-che dal lato client l'indirizzo remoto è sempre noto quando si esegue la
+La funzione è identica a \func{getsockname}, ed usa la stessa sintassi, ma
+restituisce l'indirizzo remoto del socket, cioè quello associato all'altro
+capo della connessione.  Ci si può chiedere a cosa serva questa funzione dato
+che dal lato client l'indirizzo remoto è sempre noto quando si esegue la
 \func{connect} mentre dal lato server si possono usare, come vedremo in
 fig.~\ref{fig:TCP_daytime_cunc_server_code}, i valori di ritorno di
 \func{accept}.
 
-Il fatto è che in generale quest'ultimo caso non è sempre possibile.  In
+Il fatto è che in generale quest'ultimo caso non è sempre possibile.  In
 particolare questo avviene quando il server, invece di gestire la connessione
 direttamente in un processo figlio, come vedremo nell'esempio di server
 concorrente di sez.~\ref{sec:TCP_daytime_cunc_server}, lancia per ciascuna
 connessione un altro programma, usando \func{exec}.\footnote{questa ad esempio
-  è la modalità con cui opera il \textsl{super-server} \cmd{inetd}, che può
+  è la modalità con cui opera il \textsl{super-server} \cmd{inetd}, che può
   gestire tutta una serie di servizi diversi, eseguendo su ogni connessione
   ricevuta sulle porte tenute sotto controllo, il relativo server.}
 
-In questo caso benché il processo figlio abbia una immagine della memoria che
-è copia di quella del processo padre (e contiene quindi anche la struttura
-ritornata da \func{accept}), all'esecuzione di \func{exec} verrà caricata in
+In questo caso benché il processo figlio abbia una immagine della memoria che
+è copia di quella del processo padre (e contiene quindi anche la struttura
+ritornata da \func{accept}), all'esecuzione di \func{exec} verrà caricata in
 memoria l'immagine del programma eseguito, che a questo punto perde ogni
-riferimento ai valori tornati da \func{accept}.  Il socket descriptor però
-resta aperto, e se si è seguita una opportuna convenzione per rendere noto al
-programma eseguito qual è il socket connesso, \footnote{ad esempio il solito
+riferimento ai valori tornati da \func{accept}.  Il socket descriptor però
+resta aperto, e se si è seguita una opportuna convenzione per rendere noto al
+programma eseguito qual è il socket connesso, \footnote{ad esempio il solito
   \cmd{inetd} fa sempre in modo che i file descriptor 0, 1 e 2 corrispondano
-  al socket connesso.} quest'ultimo potrà usare la funzione \func{getpeername}
+  al socket connesso.} quest'ultimo potrà usare la funzione \func{getpeername}
 per determinare l'indirizzo remoto del client.
 
-Infine è da chiarire (si legga la pagina di manuale) che, come per
-\func{accept}, il terzo argomento, che è specificato dallo standard POSIX.1g
-come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un
-\ctyp{int *} come prima dello standard perché tutte le implementazioni dei
+Infine è da chiarire (si legga la pagina di manuale) che, come per
+\func{accept}, il terzo argomento, che è specificato dallo standard POSIX.1g
+come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un
+\ctyp{int *} come prima dello standard perché tutte le implementazioni dei
 socket BSD fanno questa assunzione.
 
 
@@ -1228,30 +1228,30 @@ socket BSD fanno questa assunzione.
 \label{sec:TCP_func_close}
 
 La funzione standard Unix \func{close} (vedi sez.~\ref{sec:file_close}) che si
-usa sui file può essere usata con lo stesso effetto anche sui file descriptor
+usa sui file può essere usata con lo stesso effetto anche sui file descriptor
 associati ad un socket.
 
-L'azione di questa funzione quando applicata a socket è di marcarlo come
+L'azione di questa funzione quando applicata a socket è di marcarlo come
 chiuso e ritornare immediatamente al processo. Una volta chiamata il socket
-descriptor non è più utilizzabile dal processo e non può essere usato come
+descriptor non è più utilizzabile dal processo e non può essere usato come
 argomento per una \func{write} o una \func{read} (anche se l'altro capo della
-connessione non avesse chiuso la sua parte).  Il kernel invierà comunque tutti
+connessione non avesse chiuso la sua parte).  Il kernel invierà comunque tutti
 i dati che ha in coda prima di iniziare la sequenza di chiusura.
 
-Vedremo più avanti in sez.~\ref{sec:sock_generic_options} come sia possibile
-cambiare questo comportamento, e cosa può essere fatto perché il processo
+Vedremo più avanti in sez.~\ref{sec:sock_generic_options} come sia possibile
+cambiare questo comportamento, e cosa può essere fatto perché il processo
 possa assicurarsi che l'altro capo abbia ricevuto tutti i dati.
 
 Come per tutti i file descriptor anche per i socket viene mantenuto un numero
-di riferimenti, per cui se più di un processo ha lo stesso socket aperto
+di riferimenti, per cui se più di un processo ha lo stesso socket aperto
 l'emissione del FIN e la sequenza di chiusura di TCP non viene innescata
 fintanto che il numero di riferimenti non si annulla, questo si applica, come
 visto in sez.~\ref{sec:file_sharing}, sia ai file descriptor duplicati che a
-quelli ereditati dagli eventuali processi figli, ed è il comportamento che ci
+quelli ereditati dagli eventuali processi figli, ed è il comportamento che ci
 si aspetta in una qualunque applicazione client/server.
 
 Per attivare immediatamente l'emissione del FIN e la sequenza di chiusura
-descritta in sez.~\ref{sec:TCP_conn_term}, si può invece usare la funzione
+descritta in sez.~\ref{sec:TCP_conn_term}, si può invece usare la funzione
 \func{shutdown} su cui torneremo in seguito (vedi
 sez.~\ref{sec:TCP_shutdown}).
 
@@ -1265,27 +1265,27 @@ vedere in questa sezione un primo esempio di applicazione elementare che
 implementa il servizio \textit{daytime} su TCP, secondo quanto specificato
 dall'\href{http://www.ietf.org/rfc/rfc867.txt}{RFC~867}.  Prima di passare
 agli esempi del client e del server, inizieremo riesaminando con maggiori
-dettagli una peculiarità delle funzioni di I/O, già accennata in
-sez.~\ref{sec:file_read} e sez.~\ref{sec:file_write}, che nel caso dei socket è
+dettagli una peculiarità delle funzioni di I/O, già accennata in
+sez.~\ref{sec:file_read} e sez.~\ref{sec:file_write}, che nel caso dei socket è
 particolarmente rilevante.  Passeremo poi ad illustrare gli esempi
-dell'implementazione, sia dal lato client, che dal lato server, che si è
+dell'implementazione, sia dal lato client, che dal lato server, che si è
 realizzato sia in forma iterativa che concorrente.
 
 
 \subsection{Il comportamento delle funzioni di I/O}
 \label{sec:sock_io_behav}
 
-Una cosa che si tende a dimenticare quando si ha a che fare con i socket è che
+Una cosa che si tende a dimenticare quando si ha a che fare con i socket è che
 le funzioni di input/output non sempre hanno lo stesso comportamento che
 avrebbero con i normali file di dati (in particolare questo accade per i
 socket di tipo stream).
 
-Infatti con i socket è comune che funzioni come \func{read} o \func{write}
+Infatti con i socket è comune che funzioni come \func{read} o \func{write}
 possano restituire in input o scrivere in output un numero di byte minore di
-quello richiesto. Come già accennato in sez.~\ref{sec:file_read} questo è un
+quello richiesto. Come già accennato in sez.~\ref{sec:file_read} questo è un
 comportamento normale per le funzioni di I/O, ma con i normali file di dati il
 problema si avverte solo in lettura, quando si incontra la fine del file. In
-generale non è così, e con i socket questo è particolarmente evidente.
+generale non è così, e con i socket questo è particolarmente evidente.
 
 
 \begin{figure}[htb]
@@ -1300,9 +1300,9 @@ generale non 
 \end{figure}
 
 Quando ci si trova ad affrontare questo comportamento tutto quello che si deve
-fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
+fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
 byte restanti, tenendo conto che le funzioni si possono bloccare se i dati non
-sono disponibili: è lo stesso comportamento che si può avere scrivendo più di
+sono disponibili: è lo stesso comportamento che si può avere scrivendo più di
 \const{PIPE\_BUF} byte in una pipe (si riveda quanto detto in
 sez.~\ref{sec:ipc_pipes}).
 
@@ -1310,8 +1310,8 @@ Per questo motivo, seguendo l'esempio di R. W. Stevens in \cite{UNP1}, si sono
 definite due funzioni, \func{FullRead} e \func{FullWrite}, che eseguono
 lettura e scrittura tenendo conto di questa caratteristica, ed in grado di
 ritornare solo dopo avere letto o scritto esattamente il numero di byte
-specificato; il sorgente è riportato rispettivamente in
-fig.~\ref{fig:sock_FullRead_code} e fig.~\ref{fig:sock_FullWrite_code} ed è
+specificato; il sorgente è riportato rispettivamente in
+fig.~\ref{fig:sock_FullRead_code} e fig.~\ref{fig:sock_FullWrite_code} ed è
 disponibile fra i sorgenti allegati alla guida nei file \file{FullRead.c} e
 \file{FullWrite.c}.
 
@@ -1327,15 +1327,15 @@ disponibile fra i sorgenti allegati alla guida nei file \file{FullRead.c} e
   \label{fig:sock_FullWrite_code}
 \end{figure}
 
-Come si può notare le due funzioni ripetono la lettura/scrittura in un ciclo
+Come si può notare le due funzioni ripetono la lettura/scrittura in un ciclo
 fino all'esaurimento del numero di byte richiesti, in caso di errore viene
-controllato se questo è \errcode{EINTR} (cioè un'interruzione della system
+controllato se questo è \errcode{EINTR} (cioè un'interruzione della system
 call dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti
 l'errore viene ritornato al programma chiamante, interrompendo il ciclo.
 
-Nel caso della lettura, se il numero di byte letti è zero, significa che si è
+Nel caso della lettura, se il numero di byte letti è zero, significa che si è
 arrivati alla fine del file (per i socket questo significa in genere che
-l'altro capo è stato chiuso, e quindi non sarà più possibile leggere niente) e
+l'altro capo è stato chiuso, e quindi non sarà più possibile leggere niente) e
 pertanto si ritorna senza aver concluso la lettura di tutti i byte
 richiesti. Entrambe le funzioni restituiscono 0 in caso di successo, ed un
 valore negativo in caso di errore, \func{FullRead} restituisce il numero di
@@ -1346,17 +1346,17 @@ byte non letti in caso di end-of-file prematuro.
 \label{sec:TCP_daytime_client}
 
 Il primo esempio di applicazione delle funzioni di base illustrate in
-sez.~\ref{sec:TCP_functions} è relativo alla creazione di un client elementare
+sez.~\ref{sec:TCP_functions} è relativo alla creazione di un client elementare
 per il servizio \textit{daytime}, un servizio elementare, definito
 nell'\href{http://www.ietf.org/rfc/rfc867.txt}{RFC~867}, che restituisce
-l'ora locale della macchina a cui si effettua la richiesta, e che è assegnato
+l'ora locale della macchina a cui si effettua la richiesta, e che è assegnato
 alla porta 13.
 
-In fig.~\ref{fig:TCP_daytime_client_code} è riportata la sezione principale
+In fig.~\ref{fig:TCP_daytime_client_code} è riportata la sezione principale
 del codice del nostro client. Il sorgente completo del programma
 (\texttt{TCP\_daytime.c}, che comprende il trattamento delle opzioni ed una
-funzione per stampare un messaggio di aiuto) è allegato alla guida nella
-sezione dei codici sorgente e può essere compilato su una qualunque macchina
+funzione per stampare un messaggio di aiuto) è allegato alla guida nella
+sezione dei codici sorgente e può essere compilato su una qualunque macchina
 GNU/Linux.
 
 \begin{figure}[!htb]
@@ -1371,30 +1371,30 @@ GNU/Linux.
 \end{figure}
 
 Il programma anzitutto (\texttt{\small 1--5}) include gli header necessari;
-dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
+dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
 tutta la parte relativa al trattamento degli argomenti passati dalla linea di
 comando (effettuata con le apposite funzioni illustrate in
 sez.~\ref{sec:proc_opt_handling}).
 
-Il primo passo (\texttt{\small 14--18}) è creare un socket TCP (quindi di tipo
+Il primo passo (\texttt{\small 14--18}) è creare un socket TCP (quindi di tipo
 \const{SOCK\_STREAM} e di famiglia \const{AF\_INET}). La funzione
 \func{socket} ritorna il descrittore che viene usato per identificare il
 socket in tutte le chiamate successive. Nel caso la chiamata fallisca si
 stampa un errore (\texttt{\small 16}) con la funzione \func{perror} e si esce
 (\texttt{\small 17}) con un codice di errore.
 
-Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita
-struttura \struct{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
-il numero della porta del servizio. Il primo passo (\texttt{\small 20}) è
+Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita
+struttura \struct{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
+il numero della porta del servizio. Il primo passo (\texttt{\small 20}) è
 inizializzare tutto a zero, per poi inserire il tipo di indirizzo
 (\texttt{\small 21}) e la porta (\texttt{\small 22}), usando per quest'ultima
 la funzione \func{htons} per convertire il formato dell'intero usato dal
-computer a quello usato nella rete, infine \texttt{\small 23--27} si può
+computer a quello usato nella rete, infine \texttt{\small 23--27} si può
 utilizzare la funzione \func{inet\_pton} per convertire l'indirizzo numerico
 passato dalla linea di comando.
 
 A questo punto (\texttt{\small 28--32}) usando la funzione \func{connect} sul
-socket creato in precedenza (\texttt{\small 29}) si può stabilire la
+socket creato in precedenza (\texttt{\small 29}) si può stabilire la
 connessione con il server. Per questo si deve utilizzare come secondo
 argomento la struttura preparata in precedenza con il relativo indirizzo; si
 noti come, esistendo diversi tipi di socket, si sia dovuto effettuare un cast.
@@ -1403,10 +1403,10 @@ connessione, nel qual caso si stampa un errore (\texttt{\small 30}) e si
 ritorna (\texttt{\small 31}).
 
 Completata con successo la connessione il passo successivo (\texttt{\small
-  34--40}) è leggere la data dal socket; il protocollo prevede che il server
-invii sempre una stringa alfanumerica, il formato della stringa non è
+  34--40}) è leggere la data dal socket; il protocollo prevede che il server
+invii sempre una stringa alfanumerica, il formato della stringa non è
 specificato dallo standard, per cui noi useremo il formato usato dalla
-funzione \func{ctime}, seguito dai caratteri di terminazione \verb|\r\n|, cioè
+funzione \func{ctime}, seguito dai caratteri di terminazione \verb|\r\n|, cioè
 qualcosa del tipo:
 \begin{verbatim}
 Wed Apr 4 00:53:00 2001\r\n
@@ -1416,23 +1416,23 @@ in un buffer temporaneo; la stringa poi deve essere terminata (\texttt{\small
   35}) con il solito carattere nullo per poter essere stampata (\texttt{\small
   36}) sullo standard output con l'uso di \func{fputs}.
 
-Come si è già spiegato in sez.~\ref{sec:sock_io_behav} la risposta dal socket
-potrà arrivare in un unico pacchetto di 26 byte (come avverrà senz'altro nel
+Come si è già spiegato in sez.~\ref{sec:sock_io_behav} la risposta dal socket
+potrà arrivare in un unico pacchetto di 26 byte (come avverrà senz'altro nel
 caso in questione) ma potrebbe anche arrivare in 26 pacchetti di un byte.  Per
-questo nel caso generale non si può mai assumere che tutti i dati arrivino con
+questo nel caso generale non si può mai assumere che tutti i dati arrivino con
 una singola lettura, pertanto quest'ultima deve essere effettuata in un ciclo
 in cui si continui a leggere fintanto che la funzione \func{read} non ritorni
 uno zero (che significa che l'altro capo ha chiuso la connessione) o un numero
 minore di zero (che significa un errore nella connessione).
 
 Si noti come in questo caso la fine dei dati sia specificata dal server che
-chiude la connessione (anche questo è quanto richiesto dal protocollo); questa
-è una delle tecniche possibili (è quella usata pure dal protocollo HTTP), ma
+chiude la connessione (anche questo è quanto richiesto dal protocollo); questa
+è una delle tecniche possibili (è quella usata pure dal protocollo HTTP), ma
 ce ne possono essere altre, ad esempio FTP marca la conclusione di un blocco
 di dati con la sequenza ASCII \verb|\r\n| (carriage return e line feed),
 mentre il DNS mette la lunghezza in testa ad ogni blocco che trasmette. Il
-punto essenziale è che TCP non provvede nessuna indicazione che permetta di
-marcare dei blocchi di dati, per cui se questo è necessario deve provvedere il
+punto essenziale è che TCP non provvede nessuna indicazione che permetta di
+marcare dei blocchi di dati, per cui se questo è necessario deve provvedere il
 programma stesso.
 
 Se abilitiamo il servizio \textit{daytime}\footnote{in genere questo viene
@@ -1452,9 +1452,9 @@ e come si vede tutto funziona regolarmente.
 Dopo aver illustrato il client daremo anche un esempio di un server
 elementare, che sia anche in grado di rispondere al precedente client. Come
 primo esempio realizzeremo un server iterativo, in grado di fornire una sola
-risposta alla volta. Il codice del programma è nuovamente mostrato in
+risposta alla volta. Il codice del programma è nuovamente mostrato in
 fig.~\ref{fig:TCP_daytime_iter_server_code}, il sorgente completo
-(\texttt{TCP\_iter\_daytimed.c}) è allegato insieme agli altri file degli
+(\texttt{TCP\_iter\_daytimed.c}) è allegato insieme agli altri file degli
 esempi.
 
 \begin{figure}[!htbp]
@@ -1468,12 +1468,12 @@ esempi.
 \end{figure}
 
 Come per il client si includono (\texttt{\small 1--9}) gli header necessari a
-cui è aggiunto quello per trattare i tempi, e si definiscono (\texttt{\small
+cui è aggiunto quello per trattare i tempi, e si definiscono (\texttt{\small
   14--18}) alcune costanti e le variabili necessarie in seguito. Come nel caso
 precedente si sono omesse le parti relative al trattamento delle opzioni da
 riga di comando.
 
-La creazione del socket (\texttt{\small 20--24}) è analoga al caso precedente,
+La creazione del socket (\texttt{\small 20--24}) è analoga al caso precedente,
 come pure l'inizializzazione (\texttt{\small 25--29}) della struttura
 \struct{sockaddr\_in}.  Anche in questo caso (\texttt{\small 28}) si usa la
 porta standard del servizio daytime, ma come indirizzo IP si usa
@@ -1487,73 +1487,73 @@ delle interfacce di rete locali. In caso di errore si stampa (\texttt{\small
   31}) un messaggio, e si termina (\texttt{\small 32}) immediatamente il
 programma.
 
-Il passo successivo (\texttt{\small 35--39}) è quello di mettere ``\textsl{in
+Il passo successivo (\texttt{\small 35--39}) è quello di mettere ``\textsl{in
   ascolto}'' il socket; questo viene fatto (\texttt{\small 36}) con la
 funzione \func{listen} che dice al kernel di accettare connessioni per il
 socket che abbiamo creato; la funzione indica inoltre, con il secondo
-argomento, il numero massimo di connessioni che il kernel accetterà di mettere
+argomento, il numero massimo di connessioni che il kernel accetterà di mettere
 in coda per il suddetto socket. Di nuovo in caso di errore si stampa
 (\texttt{\small 37}) un messaggio, e si esce (\texttt{\small 38})
 immediatamente.
 
 La chiamata a \func{listen} completa la preparazione del socket per l'ascolto
-(che viene chiamato anche \textit{listening descriptor}) a questo punto si può
+(che viene chiamato anche \textit{listening descriptor}) a questo punto si può
 procedere con il ciclo principale (\texttt{\small 40--53}) che viene eseguito
-indefinitamente. Il primo passo (\texttt{\small 42}) è porsi in attesa di
+indefinitamente. Il primo passo (\texttt{\small 42}) è porsi in attesa di
 connessioni con la chiamata alla funzione \func{accept}, come in precedenza in
 caso di errore si stampa (\texttt{\small 43}) un messaggio, e si esce
 (\texttt{\small 44}).
 
-Il processo resterà in stato di \textit{sleep} fin quando non arriva e viene
+Il processo resterà in stato di \textit{sleep} fin quando non arriva e viene
 accettata una connessione da un client; quando questo avviene \func{accept}
 ritorna, restituendo un secondo descrittore, che viene chiamato
-\textit{connected descriptor}, e che è quello che verrà usato dalla successiva
+\textit{connected descriptor}, e che è quello che verrà usato dalla successiva
 chiamata alla \func{write} per scrivere la risposta al client.
 
-Il ciclo quindi proseguirà determinando (\texttt{\small 46}) il tempo corrente
-con una chiamata a \texttt{time}, con il quale si potrà opportunamente
+Il ciclo quindi proseguirà determinando (\texttt{\small 46}) il tempo corrente
+con una chiamata a \texttt{time}, con il quale si potrà opportunamente
 costruire (\texttt{\small 47}) la stringa con la data da trasmettere
 (\texttt{\small 48}) con la chiamata a \func{write}. Completata la
 trasmissione il nuovo socket viene chiuso (\texttt{\small 52}).  A questo
 punto il ciclo si chiude ricominciando da capo in modo da poter ripetere
 l'invio della data in risposta ad una successiva connessione.
 
-È importante notare che questo server è estremamente elementare, infatti, a
-parte il fatto di poter essere usato solo con indirizzi IPv4, esso è in grado
-di rispondere ad un solo un client alla volta: è cioè, come dicevamo, un
-\textsl{server iterativo}. Inoltre è scritto per essere lanciato da linea di
+È importante notare che questo server è estremamente elementare, infatti, a
+parte il fatto di poter essere usato solo con indirizzi IPv4, esso è in grado
+di rispondere ad un solo un client alla volta: è cioè, come dicevamo, un
+\textsl{server iterativo}. Inoltre è scritto per essere lanciato da linea di
 comando, se lo si volesse utilizzare come demone occorrerebbero le opportune
 modifiche\footnote{come una chiamata a \func{daemon} prima dell'inizio del
   ciclo principale.} per tener conto di quanto illustrato in
-sez.~\ref{sec:sess_daemon}. Si noti anche che non si è inserita nessuna forma
+sez.~\ref{sec:sess_daemon}. Si noti anche che non si è inserita nessuna forma
 di gestione della terminazione del processo, dato che tutti i file descriptor
 vengono chiusi automaticamente alla sua uscita, e che, non generando figli,
-non è necessario preoccuparsi di gestire la loro terminazione.
+non è necessario preoccuparsi di gestire la loro terminazione.
 
 
 \subsection{Un server \textit{daytime} concorrente}
 \label{sec:TCP_daytime_cunc_server}
 
 Il server \texttt{daytime} dell'esempio in
-sez.~\ref{sec:TCP_daytime_iter_server} è un tipico esempio di server iterativo,
-in cui viene servita una richiesta alla volta; in generale però, specie se il
-servizio è più complesso e comporta uno scambio di dati più sostanzioso di
-quello in questione, non è opportuno bloccare un server nel servizio di un
-client per volta; per questo si ricorre alle capacità di multitasking del
+sez.~\ref{sec:TCP_daytime_iter_server} è un tipico esempio di server iterativo,
+in cui viene servita una richiesta alla volta; in generale però, specie se il
+servizio è più complesso e comporta uno scambio di dati più sostanzioso di
+quello in questione, non è opportuno bloccare un server nel servizio di un
+client per volta; per questo si ricorre alle capacità di multitasking del
 sistema.
 
-Come accennato anche in sez.~\ref{sec:proc_gen} una delle modalità più comuni
-di funzionamento da parte dei server è quella di usare la funzione \func{fork}
+Come accennato anche in sez.~\ref{sec:proc_gen} una delle modalità più comuni
+di funzionamento da parte dei server è quella di usare la funzione \func{fork}
 per creare, ad ogni richiesta da parte di un client, un processo figlio che si
-incarichi della gestione della comunicazione.  Si è allora riscritto il server
+incarichi della gestione della comunicazione.  Si è allora riscritto il server
 \textit{daytime} dell'esempio precedente in forma concorrente, inserendo anche
 una opzione per la stampa degli indirizzi delle connessioni ricevute.
 
-In fig.~\ref{fig:TCP_daytime_cunc_server_code} è mostrato un estratto del
+In fig.~\ref{fig:TCP_daytime_cunc_server_code} è mostrato un estratto del
 codice, in cui si sono tralasciati il trattamento delle opzioni e le parti
-rimaste invariate rispetto al precedente esempio (cioè tutta la parte
+rimaste invariate rispetto al precedente esempio (cioè tutta la parte
 riguardante l'apertura passiva del socket). Al solito il sorgente completo del
-server, nel file \texttt{TCP\_cunc\_daytimed.c}, è allegato insieme ai
+server, nel file \texttt{TCP\_cunc\_daytimed.c}, è allegato insieme ai
 sorgenti degli altri esempi.
 
 \begin{figure}[!htb]
@@ -1567,16 +1567,16 @@ sorgenti degli altri esempi.
   \label{fig:TCP_daytime_cunc_server_code}
 \end{figure}
 
-Stavolta (\texttt{\small 21--26}) la funzione \func{accept} è chiamata
+Stavolta (\texttt{\small 21--26}) la funzione \func{accept} è chiamata
 fornendo una struttura di indirizzi in cui saranno ritornati l'indirizzo IP e
 la porta da cui il client effettua la connessione, che in un secondo tempo,
-(\texttt{\small 40--44}), se il logging è abilitato, stamperemo sullo standard
+(\texttt{\small 40--44}), se il logging è abilitato, stamperemo sullo standard
 output.
 
 Quando \func{accept} ritorna il server chiama la funzione \func{fork}
-(\texttt{\small 27--31}) per creare il processo figlio che effettuerà
+(\texttt{\small 27--31}) per creare il processo figlio che effettuerà
 (\texttt{\small 32--46}) tutte le operazioni relative a quella connessione,
-mentre il padre proseguirà l'esecuzione del ciclo principale in attesa di
+mentre il padre proseguirà l'esecuzione del ciclo principale in attesa di
 ulteriori connessioni.
 
 Si noti come il figlio operi solo sul socket connesso, chiudendo
@@ -1584,29 +1584,29 @@ immediatamente (\texttt{\small 33}) il socket \var{list\_fd}; mentre il padre
 continua ad operare solo sul socket in ascolto chiudendo (\texttt{\small 48})
 \var{conn\_fd} al ritorno dalla \func{fork}. Per quanto abbiamo detto in
 sez.~\ref{sec:TCP_func_close} nessuna delle due chiamate a \func{close} causa
-l'innesco della sequenza di chiusura perché il numero di riferimenti al file
-descriptor non si è annullato.
+l'innesco della sequenza di chiusura perché il numero di riferimenti al file
+descriptor non si è annullato.
 
 Infatti subito dopo la creazione del socket \var{list\_fd} ha una referenza, e
 lo stesso vale per \var{conn\_fd} dopo il ritorno di \func{accept}, ma dopo la
 \func{fork} i descrittori vengono duplicati nel padre e nel figlio per cui
 entrambi i socket si trovano con due referenze. Questo fa si che quando il
 padre chiude \var{sock\_fd} esso resta con una referenza da parte del figlio,
-e sarà definitivamente chiuso solo quando quest'ultimo, dopo aver completato
-le sue operazioni, chiamerà (\texttt{\small 45}) la funzione \func{close}.
+e sarà definitivamente chiuso solo quando quest'ultimo, dopo aver completato
+le sue operazioni, chiamerà (\texttt{\small 45}) la funzione \func{close}.
 
-In realtà per il figlio non sarebbe necessaria nessuna chiamata a
+In realtà per il figlio non sarebbe necessaria nessuna chiamata a
 \func{close}, in quanto con la \func{exit} finale (\texttt{\small 45}) tutti i
 file descriptor, quindi anche quelli associati ai socket, vengono
-automaticamente chiusi.  Tuttavia si è preferito effettuare esplicitamente le
+automaticamente chiusi.  Tuttavia si è preferito effettuare esplicitamente le
 chiusure per avere una maggiore chiarezza del codice, e per evitare eventuali
 errori, prevenendo ad esempio un uso involontario del \textit{listening
   descriptor}.
 
 Si noti invece come sia essenziale che il padre chiuda ogni volta il socket
-connesso dopo la \func{fork}; se così non fosse nessuno di questi socket
+connesso dopo la \func{fork}; se così non fosse nessuno di questi socket
 sarebbe effettivamente chiuso dato che alla chiusura da parte del figlio
-resterebbe ancora un riferimento nel padre. Si avrebbero così due effetti: il
+resterebbe ancora un riferimento nel padre. Si avrebbero così due effetti: il
 padre potrebbe esaurire i descrittori disponibili (che sono un numero limitato
 per ogni processo) e soprattutto nessuna delle connessioni con i client
 verrebbe chiusa.
@@ -1617,8 +1617,8 @@ chiamare \func{time} per leggere il tempo corrente, e di stamparlo
 (\texttt{\small 35}) sulla stringa contenuta in \var{buffer} con l'uso di
 \func{snprintf} e \func{ctime}. Poi la stringa viene scritta (\texttt{\small
   36--39}) sul socket, controllando che non ci siano errori. Anche in questo
-caso si è evitato il ricorso a \func{FullWrite} in quanto la stringa è
-estremamente breve e verrà senz'altro scritta in un singolo segmento.
+caso si è evitato il ricorso a \func{FullWrite} in quanto la stringa è
+estremamente breve e verrà senz'altro scritta in un singolo segmento.
 
 Inoltre nel caso sia stato abilitato il \textit{logging} delle connessioni, si
 provvede anche (\texttt{\small 40--43}) a stampare sullo standard output
@@ -1626,23 +1626,23 @@ l'indirizzo e la porta da cui il client ha effettuato la connessione, usando i
 valori contenuti nelle strutture restituite da \func{accept}, eseguendo le
 opportune conversioni con \func{inet\_ntop} e \func{ntohs}.
 
-Ancora una volta l'esempio è estremamente semplificato, si noti come di nuovo
-non si sia gestita né la terminazione del processo né il suo uso come demone,
+Ancora una volta l'esempio è estremamente semplificato, si noti come di nuovo
+non si sia gestita né la terminazione del processo né il suo uso come demone,
 che tra l'altro sarebbe stato incompatibile con l'uso della opzione di logging
 che stampa gli indirizzi delle connessioni sullo standard output. Un altro
-aspetto tralasciato è la gestione della terminazione dei processi figli,
-torneremo su questo più avanti quando tratteremo alcuni esempi di server più
+aspetto tralasciato è la gestione della terminazione dei processi figli,
+torneremo su questo più avanti quando tratteremo alcuni esempi di server più
 complessi.
 
 
 
-\section{Un esempio più completo: il servizio \textit{echo}}
+\section{Un esempio più completo: il servizio \textit{echo}}
 \label{sec:TCP_echo_application}
 
-L'esempio precedente, basato sul servizio \textit{daytime}, è un esempio molto
+L'esempio precedente, basato sul servizio \textit{daytime}, è un esempio molto
 elementare, in cui il flusso dei dati va solo nella direzione dal server al
 client. In questa sezione esamineremo un esempio di applicazione client/server
-un po' più complessa, che usi i socket TCP per una comunicazione in entrambe
+un po' più complessa, che usi i socket TCP per una comunicazione in entrambe
 le direzioni.
 
 Ci limiteremo a fornire una implementazione elementare, che usi solo le
@@ -1650,7 +1650,7 @@ funzioni di base viste finora, ma prenderemo in esame, oltre al comportamento
 in condizioni normali, anche tutti i possibili scenari particolari (errori,
 sconnessione della rete, crash del client o del server durante la connessione)
 che possono avere luogo durante l'impiego di un'applicazione di rete, partendo
-da una versione primitiva che dovrà essere rimaneggiata di volta in volta per
+da una versione primitiva che dovrà essere rimaneggiata di volta in volta per
 poter tenere conto di tutte le evenienze che si possono manifestare nella vita
 reale di un'applicazione di rete, fino ad arrivare ad un'implementazione
 completa.
@@ -1661,27 +1661,27 @@ completa.
 
 
 Nella ricerca di un servizio che potesse fare da esempio per una comunicazione
-bidirezionale, si è deciso, seguendo la scelta di Stevens in \cite{UNP1}, di
+bidirezionale, si è deciso, seguendo la scelta di Stevens in \cite{UNP1}, di
 usare il servizio \textit{echo}, che si limita a restituire in uscita quanto
-immesso in ingresso. Infatti, nonostante la sua estrema semplicità, questo
+immesso in ingresso. Infatti, nonostante la sua estrema semplicità, questo
 servizio costituisce il prototipo ideale per una generica applicazione di rete
 in cui un server risponde alle richieste di un client.  Nel caso di una
-applicazione più complessa quello che si potrà avere in più è una elaborazione
+applicazione più complessa quello che si potrà avere in più è una elaborazione
 dell'input del client, che in molti casi viene interpretato come un comando,
 da parte di un server che risponde fornendo altri dati in uscita.
 
-Il servizio \textit{echo} è uno dei servizi standard solitamente provvisti
-direttamente dal superserver \cmd{inetd}, ed è definito
+Il servizio \textit{echo} è uno dei servizi standard solitamente provvisti
+direttamente dal superserver \cmd{inetd}, ed è definito
 dall'\href{http://www.ietf.org/rfc/rfc862.txt}{RFC~862}. Come dice il nome il
 servizio deve riscrivere indietro sul socket i dati che gli vengono inviati in
 ingresso. L'RFC descrive le specifiche del servizio sia per TCP che UDP, e per
 il primo stabilisce che una volta stabilita la connessione ogni dato in
 ingresso deve essere rimandato in uscita fintanto che il chiamante non ha
-chiude la connessione. Al servizio è assegnata la porta riservata 7.
+chiude la connessione. Al servizio è assegnata la porta riservata 7.
 
-Nel nostro caso l'esempio sarà costituito da un client che legge una linea di
+Nel nostro caso l'esempio sarà costituito da un client che legge una linea di
 caratteri dallo standard input e la scrive sul server. A sua volta il server
-leggerà la linea dalla connessione e la riscriverà immutata all'indietro. Sarà
+leggerà la linea dalla connessione e la riscriverà immutata all'indietro. Sarà
 compito del client leggere la risposta del server e stamparla sullo standard
 output.
 
@@ -1690,11 +1690,11 @@ output.
 \label{sec:TCP_echo_client}
 
 Il codice della prima versione del client per il servizio \textit{echo},
-disponibile nel file \texttt{TCP\_echo\_first.c}, è riportato in
+disponibile nel file \texttt{TCP\_echo\_first.c}, è riportato in
 fig.~\ref{fig:TCP_echo_client_1}. Esso ricalca la struttura del precedente
 client per il servizio \textit{daytime} (vedi
 sez.~\ref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27})
-è sostanzialmente identica, a parte l'uso di una porta diversa.
+è sostanzialmente identica, a parte l'uso di una porta diversa.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -1706,18 +1706,18 @@ sez.~\ref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27})
   \label{fig:TCP_echo_client_1}
 \end{figure}
 
-Al solito si è tralasciata la sezione relativa alla gestione delle opzioni a
+Al solito si è tralasciata la sezione relativa alla gestione delle opzioni a
 riga di comando.  Una volta dichiarate le variabili, si prosegue
 (\texttt{\small 10--13}) con della creazione del socket con l'usuale controllo
 degli errori, alla preparazione (\texttt{\small 14--17}) della struttura
 dell'indirizzo, che stavolta usa la porta 7 riservata al servizio
 \textit{echo}, infine si converte (\texttt{\small 18--22}) l'indirizzo
-specificato a riga di comando.  A questo punto (\texttt{\small 23--27}) si può
-eseguire la connessione al server secondo la stessa modalità usata in
+specificato a riga di comando.  A questo punto (\texttt{\small 23--27}) si può
+eseguire la connessione al server secondo la stessa modalità usata in
 sez.~\ref{sec:TCP_daytime_client}.
 
 Completata la connessione, per gestire il funzionamento del protocollo si usa
-la funzione \code{ClientEcho}, il cui codice si è riportato a parte in
+la funzione \code{ClientEcho}, il cui codice si è riportato a parte in
 fig.~\ref{fig:TCP_client_echo_sub}. Questa si preoccupa di gestire tutta la
 comunicazione, leggendo una riga alla volta dallo standard input \file{stdin},
 scrivendola sul socket e ristampando su \file{stdout} quanto ricevuto in
@@ -1735,10 +1735,10 @@ Si usa poi (\texttt{\small 6}) la funzione \func{FullWrite}, vista in
 sez.~\ref{sec:sock_io_behav}, per scrivere i dati sul socket, gestendo
 automaticamente l'invio multiplo qualora una singola \func{write} non sia
 sufficiente.  I dati vengono riletti indietro (\texttt{\small 7}) con una
-\func{read}\footnote{si è fatta l'assunzione implicita che i dati siano
-  contenuti tutti in un solo segmento, così che la chiamata a \func{read} li
+\func{read}\footnote{si è fatta l'assunzione implicita che i dati siano
+  contenuti tutti in un solo segmento, così che la chiamata a \func{read} li
   restituisca sempre tutti; avendo scelto una dimensione ridotta per il buffer
-  questo sarà sempre vero, vedremo più avanti come superare il problema di
+  questo sarà sempre vero, vedremo più avanti come superare il problema di
   rileggere indietro tutti e soli i dati disponibili, senza bloccarsi.} sul
 buffer di ricezione e viene inserita (\texttt{\small 8}) la terminazione della
 stringa e per poter usare (\texttt{\small 9}) la funzione \func{fputs} per
@@ -1755,16 +1755,16 @@ scriverli su \file{stdout}.
   \label{fig:TCP_client_echo_sub}
 \end{figure}
 
-Quando si concluderà l'invio di dati mandando un end-of-file sullo standard
-input si avrà il ritorno di \func{fgets} con un puntatore nullo (si riveda
+Quando si concluderà l'invio di dati mandando un end-of-file sullo standard
+input si avrà il ritorno di \func{fgets} con un puntatore nullo (si riveda
 quanto spiegato in sez.~\ref{sec:file_line_io}) e la conseguente uscita dal
 ciclo; al che la subroutine ritorna ed il nostro programma client termina.
 
-Si può effettuare una verifica del funzionamento del client abilitando il
+Si può effettuare una verifica del funzionamento del client abilitando il
 servizio \textit{echo} nella configurazione di \cmd{initd} sulla propria
 macchina ed usandolo direttamente verso di esso in locale, vedremo in
-dettaglio più avanti (in sez.~\ref{sec:TCP_echo_startup}) il funzionamento del
-programma, usato però con la nostra versione del server \textit{echo}, che
+dettaglio più avanti (in sez.~\ref{sec:TCP_echo_startup}) il funzionamento del
+programma, usato però con la nostra versione del server \textit{echo}, che
 illustriamo immediatamente.
 
 
@@ -1772,9 +1772,9 @@ illustriamo immediatamente.
 \label{sec:TCPsimp_server_main}
 
 La prima versione del server, contenuta nel file \texttt{TCP\_echod\_first.c},
-è riportata in fig.~\ref{fig:TCP_echo_server_first_code}. Come abbiamo fatto
-per il client anche il server è stato diviso in un corpo principale,
-costituito dalla funzione \code{main}, che è molto simile a quello visto nel
+è riportata in fig.~\ref{fig:TCP_echo_server_first_code}. Come abbiamo fatto
+per il client anche il server è stato diviso in un corpo principale,
+costituito dalla funzione \code{main}, che è molto simile a quello visto nel
 precedente esempio per il server del servizio \textit{daytime} di
 sez.~\ref{sec:TCP_daytime_cunc_server}, e da una funzione ausiliaria
 \code{ServEcho} che si cura della gestione del servizio.
@@ -1790,43 +1790,43 @@ sez.~\ref{sec:TCP_daytime_cunc_server}, e da una funzione ausiliaria
   \label{fig:TCP_echo_server_first_code}
 \end{figure}
 
-In questo caso però, rispetto a quanto visto nell'esempio di
-fig.~\ref{fig:TCP_daytime_cunc_server_code} si è preferito scrivere il server
+In questo caso però, rispetto a quanto visto nell'esempio di
+fig.~\ref{fig:TCP_daytime_cunc_server_code} si è preferito scrivere il server
 curando maggiormente alcuni dettagli, per tenere conto anche di alcune
 esigenze generali (che non riguardano direttamente la rete), come la
-possibilità di lanciare il server anche in modalità interattiva e la cessione
-dei privilegi di amministratore non appena questi non sono più necessari.
+possibilità di lanciare il server anche in modalità interattiva e la cessione
+dei privilegi di amministratore non appena questi non sono più necessari.
 
-La sezione iniziale del programma (\texttt{\small 8--21}) è la stessa del
+La sezione iniziale del programma (\texttt{\small 8--21}) è la stessa del
 server di sez.~\ref{sec:TCP_daytime_cunc_server}, ed ivi descritta in
 dettaglio: crea il socket, inizializza l'indirizzo e esegue \func{bind}; dato
-che quest'ultima funzione viene usata su una porta riservata, il server dovrà
+che quest'ultima funzione viene usata su una porta riservata, il server dovrà
 essere eseguito da un processo con i privilegi di amministratore, pena il
 fallimento della chiamata.
 
-Una volta eseguita la funzione \func{bind} però i privilegi di amministratore
-non sono più necessari, per questo è sempre opportuno rilasciarli, in modo da
-evitare problemi in caso di eventuali vulnerabilità del server.  Per questo
+Una volta eseguita la funzione \func{bind} però i privilegi di amministratore
+non sono più necessari, per questo è sempre opportuno rilasciarli, in modo da
+evitare problemi in caso di eventuali vulnerabilità del server.  Per questo
 prima (\texttt{\small 22--26}) si esegue \func{setgid} per assegnare il
-processo ad un gruppo senza privilegi,\footnote{si è usato il valore 65534,
+processo ad un gruppo senza privilegi,\footnote{si è usato il valore 65534,
   ovvero -1 per il formato \ctyp{short}, che di norma in tutte le
   distribuzioni viene usato per identificare il gruppo \texttt{nogroup} e
   l'utente \texttt{nobody}, usati appunto per eseguire programmi che non
   richiedono nessun privilegio particolare.} e poi si ripete (\texttt{\small
   27--30}) l'operazione usando \func{setuid} per cambiare anche
 l'utente.\footnote{si tenga presente che l'ordine in cui si eseguono queste
-  due operazioni è importante, infatti solo avendo i privilegi di
-  amministratore si può cambiare il gruppo di un processo ad un altro di cui
+  due operazioni è importante, infatti solo avendo i privilegi di
+  amministratore si può cambiare il gruppo di un processo ad un altro di cui
   non si fa parte, per cui chiamare prima \func{setuid} farebbe fallire una
   successiva chiamata a \func{setgid}.  Inoltre si ricordi (si riveda quanto
   esposto in sez.~\ref{sec:proc_perms}) che usando queste due funzioni il
-  rilascio dei privilegi è irreversibile.}  Infine (\texttt{\small 30--36}),
+  rilascio dei privilegi è irreversibile.}  Infine (\texttt{\small 30--36}),
 qualora sia impostata la variabile \var{demonize}, prima (\texttt{\small 31})
 si apre il sistema di logging per la stampa degli errori, e poi
 (\texttt{\small 32--35}) si invoca \func{daemon} per eseguire in background il
 processo come demone.
 
-A questo punto il programma riprende di nuovo lo schema già visto usato dal
+A questo punto il programma riprende di nuovo lo schema già visto usato dal
 server per il servizio \textit{daytime}, con l'unica differenza della chiamata
 alla funzione \code{PrintErr}, riportata in fig.~\ref{fig:TCP_PrintErr}, al
 posto di \func{perror} per la stampa degli errori. 
@@ -1842,22 +1842,22 @@ del servizio \code{ServEcho}, ed al ritorno di questa esce (\texttt{\small
 
 Il padre invece si limita (\texttt{\small 57}) a chiudere il \textit{connected
   socket} per ricominciare da capo il ciclo in attesa di nuove connessioni. In
-questo modo si ha un server concorrente. La terminazione del padre non è
+questo modo si ha un server concorrente. La terminazione del padre non è
 gestita esplicitamente, e deve essere effettuata inviando un segnale al
 processo.
 
-Avendo trattato direttamente la gestione del programma come demone, si è
-dovuto anche provvedere alla necessità di poter stampare eventuali messaggi di
+Avendo trattato direttamente la gestione del programma come demone, si è
+dovuto anche provvedere alla necessità di poter stampare eventuali messaggi di
 errore attraverso il sistema del \textit{syslog} trattato in
-sez.~\ref{sec:sess_daemon}. Come accennato questo è stato fatto utilizzando
-come \textit{wrapper} la funzione \code{PrintErr}, il cui codice è riportato
+sez.~\ref{sec:sess_daemon}. Come accennato questo è stato fatto utilizzando
+come \textit{wrapper} la funzione \code{PrintErr}, il cui codice è riportato
 in fig.~\ref{fig:TCP_PrintErr}.
 
-In essa ci si limita a controllare (\texttt{\small 2}) se è stato impostato
+In essa ci si limita a controllare (\texttt{\small 2}) se è stato impostato
 (valore attivo per default) l'uso come demone, nel qual caso (\texttt{\small
   3}) si usa \func{syslog} (vedi sez.~\ref{sec:sess_daemon}) per stampare il
-messaggio di errore fornito come argomento sui log di sistema. Se invece si è
-in modalità interattiva (attivabile con l'opzione \texttt{-i}) si usa
+messaggio di errore fornito come argomento sui log di sistema. Se invece si è
+in modalità interattiva (attivabile con l'opzione \texttt{-i}) si usa
 (\texttt{\small 5}) semplicemente la funzione \func{perror} per stampare sullo
 standard error.
 
@@ -1874,15 +1874,15 @@ standard error.
 \end{figure}
 
 La gestione del servizio \textit{echo} viene effettuata interamente nella
-funzione \code{ServEcho}, il cui codice è mostrato in
+funzione \code{ServEcho}, il cui codice è mostrato in
 fig.~\ref{fig:TCP_ServEcho_first}, e la comunicazione viene gestita all'interno
 di un ciclo (\texttt{\small 6--13}).  I dati inviati dal client vengono letti
 (\texttt{\small 6}) dal socket con una semplice \func{read}, di cui non si
 controlla lo stato di uscita, assumendo che ritorni solo in presenza di dati
 in arrivo. La riscrittura (\texttt{\small 7}) viene invece gestita dalla
 funzione \func{FullWrite} (descritta in fig.~\ref{fig:sock_FullWrite_code}) che
-si incarica di tenere conto automaticamente della possibilità che non tutti i
-dati di cui è richiesta la scrittura vengano trasmessi con una singola
+si incarica di tenere conto automaticamente della possibilità che non tutti i
+dati di cui è richiesta la scrittura vengano trasmessi con una singola
 \func{write}.
 
 \begin{figure}[!htb] 
@@ -1908,19 +1908,19 @@ processo figlio.
 \subsection{L'avvio e il funzionamento normale}
 \label{sec:TCP_echo_startup}
 
-Benché il codice dell'esempio precedente sia molto ridotto, esso ci permetterà
+Benché il codice dell'esempio precedente sia molto ridotto, esso ci permetterà
 di considerare in dettaglio le varie problematiche che si possono incontrare
 nello scrivere un'applicazione di rete. Infatti attraverso l'esame delle sue
-modalità di funzionamento normali, all'avvio e alla terminazione, e di quello
+modalità di funzionamento normali, all'avvio e alla terminazione, e di quello
 che avviene nelle varie situazioni limite, da una parte potremo approfondire
 la comprensione del protocollo TCP/IP e dall'altra ricavare le indicazioni
 necessarie per essere in grado di scrivere applicazioni robuste, in grado di
 gestire anche i casi limite.
 
-Il primo passo è compilare e lanciare il server (da root, per poter usare la
-porta 7 che è riservata), alla partenza esso eseguirà l'apertura passiva con
+Il primo passo è compilare e lanciare il server (da root, per poter usare la
+porta 7 che è riservata), alla partenza esso eseguirà l'apertura passiva con
 la sequenza delle chiamate a \func{socket}, \func{bind}, \func{listen} e poi
-si bloccherà nella \func{accept}. A questo punto si potrà controllarne lo
+si bloccherà nella \func{accept}. A questo punto si potrà controllarne lo
 stato con \cmd{netstat}:
 \begin{verbatim}
 [piccardi@roke piccardi]$ netstat -at
@@ -1934,10 +1934,10 @@ che ci mostra come il socket sia in ascolto sulla porta richiesta, accettando
 connessioni da qualunque indirizzo e da qualunque porta e su qualunque
 interfaccia locale.
 
-A questo punto si può lanciare il client, esso chiamerà \func{socket} e
+A questo punto si può lanciare il client, esso chiamerà \func{socket} e
 \func{connect}; una volta completato il \itindex{three~way~handshake}
-\textit{three way handshake} la connessione è stabilita; la \func{connect}
-ritornerà nel client\footnote{si noti che è sempre la \func{connect} del
+\textit{three way handshake} la connessione è stabilita; la \func{connect}
+ritornerà nel client\footnote{si noti che è sempre la \func{connect} del
   client a ritornare per prima, in quanto questo avviene alla ricezione del
   secondo segmento (l'ACK del server) del \itindex{three~way~handshake}
   \textit{three way handshake}, la \func{accept} del server ritorna solo dopo
@@ -1953,11 +1953,11 @@ tcp        0      0 roke:echo               gont:32981              ESTABLISHED
 mentre per quanto riguarda l'esecuzione dei programmi avremo che:
 \begin{itemize}
 \item il client chiama la funzione \code{ClientEcho} che si blocca sulla
-  \func{fgets} dato che non si è ancora scritto nulla sul terminale.
-\item il server eseguirà una \func{fork} facendo chiamare al processo figlio
-  la funzione \code{ServEcho}, quest'ultima si bloccherà sulla \func{read}
+  \func{fgets} dato che non si è ancora scritto nulla sul terminale.
+\item il server eseguirà una \func{fork} facendo chiamare al processo figlio
+  la funzione \code{ServEcho}, quest'ultima si bloccherà sulla \func{read}
   dal socket sul quale ancora non sono presenti dati.
-\item il processo padre del server chiamerà di nuovo \func{accept}
+\item il processo padre del server chiamerà di nuovo \func{accept}
   bloccandosi fino all'arrivo di un'altra connessione.
 \end{itemize}
 e se usiamo il comando \cmd{ps} per esaminare lo stato dei processi otterremo
@@ -1974,21 +1974,21 @@ un risultato del tipo:
 tre processi, tutti in stato di \textit{sleep} (vedi
 tab.~\ref{tab:proc_proc_states}).
 
-Se a questo punto si inizia a scrivere qualcosa sul client non sarà trasmesso
+Se a questo punto si inizia a scrivere qualcosa sul client non sarà trasmesso
 niente fin tanto che non si prema il tasto di a capo (si ricordi quanto detto
 in sez.~\ref{sec:file_line_io} a proposito dell'I/O su terminale), solo allora
-\func{fgets} ritornerà ed il client scriverà quanto immesso sul socket, per
+\func{fgets} ritornerà ed il client scriverà quanto immesso sul socket, per
 poi passare a rileggere quanto gli viene inviato all'indietro dal server, che
-a sua volta sarà inviato sullo standard output, che nel caso ne provoca
+a sua volta sarà inviato sullo standard output, che nel caso ne provoca
 l'immediata stampa a video.
 
 
 \subsection{La conclusione normale}
 \label{sec:TCP_echo_conclusion}
 
-Tutto quello che scriveremo sul client sarà rimandato indietro dal server e
+Tutto quello che scriveremo sul client sarà rimandato indietro dal server e
 ristampato a video fintanto che non concluderemo l'immissione dei dati; una
-sessione tipica sarà allora del tipo: 
+sessione tipica sarà allora del tipo: 
 \begin{verbatim}
 [piccardi@roke sources]$ ./echo 127.0.0.1
 Questa e` una prova
@@ -2007,29 +2007,29 @@ tcp        0      0 localhost:33032         localhost:echo          TIME_WAIT
 con il client che entra in \texttt{TIME\_WAIT}.
 
 Esaminiamo allora in dettaglio la sequenza di eventi che porta alla
-terminazione normale della connessione, che ci servirà poi da riferimento
+terminazione normale della connessione, che ci servirà poi da riferimento
 quando affronteremo il comportamento in caso di conclusioni anomale:
 
 \begin{enumerate}
 \item inviando un carattere di EOF da terminale la \func{fgets} ritorna
   restituendo un puntatore nullo che causa l'uscita dal ciclo di \code{while},
-  così la funzione \code{ClientEcho} ritorna.
+  così la funzione \code{ClientEcho} ritorna.
 \item al ritorno di \code{ClientEcho} ritorna anche la funzione \code{main}, e
   come parte del processo terminazione tutti i file descriptor vengono chiusi
   (si ricordi quanto detto in sez.~\ref{sec:proc_term_conclusion}); questo
-  causa la chiusura del socket di comunicazione; il client allora invierà un
-  FIN al server a cui questo risponderà con un ACK.  A questo punto il client
-  verrà a trovarsi nello stato \texttt{FIN\_WAIT\_2} ed il server nello stato
+  causa la chiusura del socket di comunicazione; il client allora invierà un
+  FIN al server a cui questo risponderà con un ACK.  A questo punto il client
+  verrà a trovarsi nello stato \texttt{FIN\_WAIT\_2} ed il server nello stato
   \texttt{CLOSE\_WAIT} (si riveda quanto spiegato in
   sez.~\ref{sec:TCP_conn_term}).
 \item quando il server riceve il FIN la \func{read} del processo figlio che
-  gestisce la connessione ritorna restituendo 0 causando così l'uscita dal
+  gestisce la connessione ritorna restituendo 0 causando così l'uscita dal
   ciclo e il ritorno di \code{ServEcho}, a questo punto il processo figlio
   termina chiamando \func{exit}.
 \item all'uscita del figlio tutti i file descriptor vengono chiusi, la
-  chiusura del socket connesso fa sì che venga effettuata la sequenza finale
-  di chiusura della connessione, viene emesso un FIN dal server che riceverà
-  un ACK dal client, a questo punto la connessione è conclusa e il client
+  chiusura del socket connesso fa sì che venga effettuata la sequenza finale
+  di chiusura della connessione, viene emesso un FIN dal server che riceverà
+  un ACK dal client, a questo punto la connessione è conclusa e il client
   resta nello stato \texttt{TIME\_WAIT}.
 \end{enumerate}
 
@@ -2037,49 +2037,49 @@ quando affronteremo il comportamento in caso di conclusioni anomale:
 \subsection{La gestione dei processi figli}
 \label{sec:TCP_child_hand}
 
-Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto
+Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto
 del procedimento di chiusura del processo figlio nel server (si veda quanto
 esaminato in sez.~\ref{sec:proc_termination}). In questo caso avremo l'invio
-del segnale \const{SIGCHLD} al padre, ma dato che non si è installato un
-gestore e che l'azione predefinita per questo segnale è quella di essere
+del segnale \const{SIGCHLD} al padre, ma dato che non si è installato un
+gestore e che l'azione predefinita per questo segnale è quella di essere
 ignorato, non avendo predisposto la ricezione dello stato di terminazione,
-otterremo che il processo figlio entrerà nello stato di \index{zombie} zombie
-(si riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}), come risulterà
+otterremo che il processo figlio entrerà nello stato di \index{zombie} zombie
+(si riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}), come risulterà
 ripetendo il comando \cmd{ps}:
 \begin{verbatim}
  2356 pts/0    S      0:00 ./echod
  2359 pts/0    Z      0:00 [echod <defunct>]
 \end{verbatim}
 
-Dato che non è il caso di lasciare processi \index{zombie} zombie, occorrerà
+Dato che non è il caso di lasciare processi \index{zombie} zombie, occorrerà
 ricevere opportunamente lo stato di terminazione del processo (si veda
 sez.~\ref{sec:proc_wait}), cosa che faremo utilizzando \const{SIGCHLD} secondo
 quanto illustrato in sez.~\ref{sec:sig_sigchld}. Una prima modifica al nostro
-server è pertanto quella di inserire la gestione della terminazione dei
+server è pertanto quella di inserire la gestione della terminazione dei
 processi figli attraverso l'uso di un gestore.  Per questo useremo la funzione
 \code{Signal} (che abbiamo illustrato in fig.~\ref{fig:sig_Signal_code}), per
-installare il gestore che riceve i segnali dei processi figli terminati già
-visto in fig.~\ref{fig:sig_sigchld_handl}.  Basterà allora aggiungere il
+installare il gestore che riceve i segnali dei processi figli terminati già
+visto in fig.~\ref{fig:sig_sigchld_handl}.  Basterà allora aggiungere il
 seguente codice: \includecodesnip{listati/sigchildhand.c}
 \noindent
 all'esempio illustrato in fig.~\ref{fig:TCP_echo_server_first_code}.
 
-In questo modo però si introduce un altro problema. Si ricordi infatti che,
+In questo modo però si introduce un altro problema. Si ricordi infatti che,
 come spiegato in sez.~\ref{sec:sig_gen_beha}, quando un programma si trova in
 stato di \texttt{sleep} durante l'esecuzione di una system call, questa viene
 interrotta alla ricezione di un segnale. Per questo motivo, alla fine
 dell'esecuzione del gestore del segnale, se questo ritorna, il programma
-riprenderà l'esecuzione ritornando dalla system call interrotta con un errore
+riprenderà l'esecuzione ritornando dalla system call interrotta con un errore
 di \errcode{EINTR}.
 
 Vediamo allora cosa comporta tutto questo nel nostro caso: quando si chiude il
-client, il processo figlio che gestisce la connessione terminerà, ed il padre,
-per evitare la creazione di zombie, riceverà il segnale \const{SIGCHLD}
-eseguendo il relativo gestore. Al ritorno del gestore però l'esecuzione nel
-padre ripartirà subito con il ritorno della funzione \func{accept} (a meno di
+client, il processo figlio che gestisce la connessione terminerà, ed il padre,
+per evitare la creazione di zombie, riceverà il segnale \const{SIGCHLD}
+eseguendo il relativo gestore. Al ritorno del gestore però l'esecuzione nel
+padre ripartirà subito con il ritorno della funzione \func{accept} (a meno di
 un caso fortuito in cui il segnale arriva durante l'esecuzione del programma
 in risposta ad una connessione) con un errore di \errcode{EINTR}. Non avendo
-previsto questa eventualità il programma considera questo un errore fatale
+previsto questa eventualità il programma considera questo un errore fatale
 terminando a sua volta con un messaggio del tipo:
 \begin{verbatim}
 [root@gont sources]# ./echod -i
@@ -2088,13 +2088,13 @@ accept error: Interrupted system call
 
 Come accennato in sez.~\ref{sec:sig_gen_beha} le conseguenze di questo
 comportamento delle system call possono essere superate in due modi diversi,
-il più semplice è quello di modificare il codice di \func{Signal} per
+il più semplice è quello di modificare il codice di \func{Signal} per
 richiedere il riavvio automatico delle system call interrotte secondo la
 semantica di BSD, usando l'opzione \const{SA\_RESTART} di \func{sigaction};
 rispetto a quanto visto in fig.~\ref{fig:sig_Signal_code}. Definiremo allora la
-nuova funzione \func{SignalRestart}\footnote{anche questa è definita, insieme
+nuova funzione \func{SignalRestart}\footnote{anche questa è definita, insieme
   alle altre funzioni riguardanti la gestione dei segnali, nel file
-  \file{SigHand.c}, il cui contento completo può essere trovato negli esempi
+  \file{SigHand.c}, il cui contento completo può essere trovato negli esempi
   allegati.} come mostrato in fig.~\ref{fig:sig_SignalRestart_code}, ed
 installeremo il gestore usando quest'ultima.
 
@@ -2110,50 +2110,50 @@ installeremo il gestore usando quest'ultima.
   \label{fig:sig_SignalRestart_code}
 \end{figure}
 
-Come si può notare questa funzione è identica alla precedente \func{Signal},
+Come si può notare questa funzione è identica alla precedente \func{Signal},
 illustrata in fig.~\ref{fig:sig_Signal_code}, solo che in questo caso invece di
 inizializzare a zero il campo \var{sa\_flags} di \struct{sigaction}, lo si
 inizializza (\texttt{\small 5}) al valore \const{SA\_RESTART}. Usando questa
-funzione al posto di \func{Signal} nel server non è necessaria nessuna altra
+funzione al posto di \func{Signal} nel server non è necessaria nessuna altra
 modifica: le system call interrotte saranno automaticamente riavviate, e
-l'errore \errcode{EINTR} non si manifesterà più.
+l'errore \errcode{EINTR} non si manifesterà più.
 
-La seconda soluzione è più invasiva e richiede di controllare tutte le volte
+La seconda soluzione è più invasiva e richiede di controllare tutte le volte
 l'errore restituito dalle varie system call, ripetendo la chiamata qualora
-questo corrisponda ad \errcode{EINTR}. Questa soluzione ha però il pregio
-della portabilità, infatti lo standard POSIX dice che la funzionalità di
-riavvio automatico delle system call, fornita da \const{SA\_RESTART}, è
-opzionale, per cui non è detto che essa sia disponibile su qualunque sistema.
+questo corrisponda ad \errcode{EINTR}. Questa soluzione ha però il pregio
+della portabilità, infatti lo standard POSIX dice che la funzionalità di
+riavvio automatico delle system call, fornita da \const{SA\_RESTART}, è
+opzionale, per cui non è detto che essa sia disponibile su qualunque sistema.
 Inoltre in certi casi,\footnote{Stevens in \cite{UNP1} accenna che la maggior
   parte degli Unix derivati da BSD non fanno ripartire \func{select}; altri
   non riavviano neanche \func{accept} e \func{recvfrom}, cosa che invece nel
-  caso di Linux viene sempre fatta.} anche quando questa è presente, non è
+  caso di Linux viene sempre fatta.} anche quando questa è presente, non è
 detto possa essere usata con \func{accept}. 
 
 
-La portabilità nella gestione dei segnali però viene al costo di una
+La portabilità nella gestione dei segnali però viene al costo di una
 riscrittura parziale del server, la nuova versione di questo, in cui si sono
-introdotte una serie di nuove opzioni che ci saranno utili per il debug, è
+introdotte una serie di nuove opzioni che ci saranno utili per il debug, è
 mostrata in fig.~\ref{fig:TCP_echo_server_code_second}, dove si sono riportate
 la sezioni di codice modificate nella seconda versione del programma, il
 codice completo di quest'ultimo si trova nel file
 \texttt{TCP\_echod\_second.c} dei sorgenti allegati alla guida.
 
-La prima modifica effettuata è stata quella di introdurre una nuova opzione a
+La prima modifica effettuata è stata quella di introdurre una nuova opzione a
 riga di comando, \texttt{-c}, che permette di richiedere il comportamento
 compatibile nella gestione di \const{SIGCHLD} al posto della semantica BSD
-impostando la variabile \var{compat} ad un valore non nullo. Questa è
-preimpostata al valore nullo, cosicché se non si usa questa opzione il
-comportamento di default del server è di usare la semantica BSD. 
+impostando la variabile \var{compat} ad un valore non nullo. Questa è
+preimpostata al valore nullo, cosicché se non si usa questa opzione il
+comportamento di default del server è di usare la semantica BSD. 
 
-Una seconda opzione aggiunta è quella di inserire un tempo di attesa fisso
+Una seconda opzione aggiunta è quella di inserire un tempo di attesa fisso
 specificato in secondi fra il ritorno della funzione \func{listen} e la
 chiamata di \func{accept}, specificabile con l'opzione \texttt{-w}, che
-permette di impostare la variabile \var{waiting}.  Infine si è introdotta una
+permette di impostare la variabile \var{waiting}.  Infine si è introdotta una
 opzione \texttt{-d} per abilitare il debugging che imposta ad un valore non
-nullo la variabile \var{debugging}. Al solito si è omessa da
+nullo la variabile \var{debugging}. Al solito si è omessa da
 fig.~\ref{fig:TCP_echo_server_code_second} la sezione di codice relativa alla
-gestione di tutte queste opzioni, che può essere trovata nel sorgente del
+gestione di tutte queste opzioni, che può essere trovata nel sorgente del
 programma.
 
 \begin{figure}[!htb]
@@ -2168,28 +2168,28 @@ programma.
   \label{fig:TCP_echo_server_code_second}
 \end{figure}
 
-Vediamo allora come è cambiato il nostro server; una volta definite le
-variabili e trattate le opzioni il primo passo (\texttt{\small 9--13}) è
+Vediamo allora come è cambiato il nostro server; una volta definite le
+variabili e trattate le opzioni il primo passo (\texttt{\small 9--13}) è
 verificare la semantica scelta per la gestione di \const{SIGCHLD}, a seconda
 del valore di \var{compat} (\texttt{\small 9}) si installa il gestore con la
 funzione \func{Signal} (\texttt{\small 10}) o con \texttt{SignalRestart}
 (\texttt{\small 12}), essendo quest'ultimo il valore di default.
 
 Tutta la sezione seguente, che crea il socket, cede i privilegi di
-amministratore ed eventualmente lancia il programma come demone, è rimasta
-invariata e pertanto è stata omessa in
+amministratore ed eventualmente lancia il programma come demone, è rimasta
+invariata e pertanto è stata omessa in
 fig.~\ref{fig:TCP_echo_server_code_second}; l'unica modifica effettuata prima
-dell'entrata nel ciclo principale è stata quella di aver introdotto, subito
+dell'entrata nel ciclo principale è stata quella di aver introdotto, subito
 dopo la chiamata (\texttt{\small 17--20}) alla funzione \func{listen}, una
 eventuale pausa con una condizione (\texttt{\small 21}) sulla variabile
 \var{waiting}, che viene inizializzata, con l'opzione \texttt{-w Nsec}, al
-numero di secondi da aspettare (il valore preimpostato è nullo).
+numero di secondi da aspettare (il valore preimpostato è nullo).
 
-Si è potuto lasciare inalterata tutta la sezione di creazione del socket
-perché nel server l'unica chiamata ad una system call lenta, che può essere
-interrotta dall'arrivo di \const{SIGCHLD}, è quella ad \func{accept}, che è
-l'unica funzione che può mettere il processo padre in stato di sleep nel
-periodo in cui un figlio può terminare; si noti infatti come le altre
+Si è potuto lasciare inalterata tutta la sezione di creazione del socket
+perché nel server l'unica chiamata ad una system call lenta, che può essere
+interrotta dall'arrivo di \const{SIGCHLD}, è quella ad \func{accept}, che è
+l'unica funzione che può mettere il processo padre in stato di sleep nel
+periodo in cui un figlio può terminare; si noti infatti come le altre
 \index{system~call~lente} \textit{slow system call}\footnote{si ricordi la
   distinzione fatta in sez.~\ref{sec:sig_gen_beha}.} o sono chiamate prima di
 entrare nel ciclo principale, quando ancora non esistono processi figli, o
@@ -2197,18 +2197,18 @@ sono chiamate dai figli stessi e non risentono di \const{SIGCHLD}.
 
 Per questo l'unica modifica sostanziale nel ciclo principale (\texttt{\small
   23--42}), rispetto precedente versione di fig.~\ref{fig:TCP_ServEcho_first},
-è nella sezione (\texttt{\small 25--31}) in cui si effettua la chiamata di
+è nella sezione (\texttt{\small 25--31}) in cui si effettua la chiamata di
 \func{accept}.  Quest'ultima viene effettuata (\texttt{\small 26--27})
 all'interno di un ciclo di \code{while}\footnote{la sintassi del C relativa a
-  questo ciclo può non essere del tutto chiara. In questo caso infatti si è
+  questo ciclo può non essere del tutto chiara. In questo caso infatti si è
   usato un ciclo vuoto che non esegue nessuna istruzione, in questo modo
-  quello che viene ripetuto con il ciclo è soltanto il codice che esprime la
+  quello che viene ripetuto con il ciclo è soltanto il codice che esprime la
   condizione all'interno del \code{while}.}  che la ripete indefinitamente
 qualora in caso di errore il valore di \var{errno} sia \errcode{EINTR}. Negli
 altri casi si esce in caso di errore effettivo (\texttt{\small 27--29}),
 altrimenti il programma prosegue.
 
-Si noti che in questa nuova versione si è aggiunta una ulteriore sezione
+Si noti che in questa nuova versione si è aggiunta una ulteriore sezione
 (\texttt{\small 32--40}) di aiuto per il debug del programma, che eseguita con
 un controllo (\texttt{\small 33}) sul valore della variabile \var{debugging}
 impostato dall'opzione \texttt{-d}. Qualora questo sia nullo, come
@@ -2217,9 +2217,9 @@ ricevuto da \var{accept} viene convertito in una stringa che poi
 (\texttt{\small 34--39}) viene opportunamente stampata o sullo schermo o nei
 log.
 
-Infine come ulteriore miglioria si è perfezionata la funzione \code{ServEcho},
-sia per tenere conto della nuova funzionalità di debugging, che per effettuare
-un controllo in caso di errore; il codice della nuova versione è mostrato in
+Infine come ulteriore miglioria si è perfezionata la funzione \code{ServEcho},
+sia per tenere conto della nuova funzionalità di debugging, che per effettuare
+un controllo in caso di errore; il codice della nuova versione è mostrato in
 fig.~\ref{fig:TCP_ServEcho_second}.
 
 \begin{figure}[!htb] 
@@ -2234,14 +2234,14 @@ fig.~\ref{fig:TCP_ServEcho_second}.
 \end{figure}
 
 Rispetto alla precedente versione di fig.~\ref{fig:TCP_ServEcho_first} in
-questo caso si è provveduto a controllare (\texttt{\small 7--10}) il valore di
+questo caso si è provveduto a controllare (\texttt{\small 7--10}) il valore di
 ritorno di \func{read} per rilevare un eventuale errore, in modo da stampare
 (\texttt{\small 8}) un messaggio di errore e ritornare (\texttt{\small 9})
 concludendo la connessione.
 
-Inoltre qualora sia stata attivata la funzionalità di debug (avvalorando
-\var{debugging} tramite l'apposita opzione \texttt{-d}) si provvederà a
-stampare (tenendo conto della modalità di invocazione del server, se
+Inoltre qualora sia stata attivata la funzionalità di debug (avvalorando
+\var{debugging} tramite l'apposita opzione \texttt{-d}) si provvederà a
+stampare (tenendo conto della modalità di invocazione del server, se
 interattiva o in forma di demone) il numero di byte e la stringa letta dal
 client (\texttt{\small 16--24}).
 
@@ -2253,7 +2253,7 @@ Con le modifiche viste in sez.~\ref{sec:TCP_child_hand} il nostro esempio
 diventa in grado di affrontare la gestione ordinaria delle connessioni, ma un
 server di rete deve tenere conto che, al contrario di quanto avviene per i
 server che operano nei confronti di processi presenti sulla stessa macchina,
-la rete è di sua natura inaffidabile, per cui è necessario essere in grado di
+la rete è di sua natura inaffidabile, per cui è necessario essere in grado di
 gestire tutta una serie di situazioni critiche che non esistono per i processi
 locali.
 
@@ -2261,16 +2261,16 @@ locali.
 \subsection{La terminazione precoce della connessione}
 \label{sec:TCP_conn_early_abort}
 
-La prima situazione critica è quella della terminazione precoce, causata da un
+La prima situazione critica è quella della terminazione precoce, causata da un
 qualche errore sulla rete, della connessione effettuata da un client. Come
 accennato in sez.~\ref{sec:TCP_func_accept} la funzione \func{accept} riporta
 tutti gli eventuali errori di rete pendenti su una connessione sul
-\textit{connected socket}. Di norma questo non è un problema, in quanto non
-appena completata la connessione, \func{accept} ritorna e l'errore sarà
+\textit{connected socket}. Di norma questo non è un problema, in quanto non
+appena completata la connessione, \func{accept} ritorna e l'errore sarà
 rilevato in seguito, dal processo che gestisce la connessione, alla prima
 chiamata di una funzione che opera sul socket.
 
-È però possibile, dal punto di vista teorico, incorrere anche in uno scenario
+È però possibile, dal punto di vista teorico, incorrere anche in uno scenario
 del tipo di quello mostrato in fig.~\ref{fig:TCP_early_abort}, in cui la
 connessione viene abortita sul lato client per un qualche errore di rete con
 l'invio di un segmento RST, prima che nel server sia stata chiamata la
@@ -2283,10 +2283,10 @@ funzione \func{accept}.
   \label{fig:TCP_early_abort}
 \end{figure}
 
-Benché questo non sia un fatto comune, un evento simile può essere osservato
+Benché questo non sia un fatto comune, un evento simile può essere osservato
 con dei server molto occupati. In tal caso, con una struttura del server
 simile a quella del nostro esempio, in cui la gestione delle singole
-connessioni è demandata a processi figli, può accadere che il \textit{three
+connessioni è demandata a processi figli, può accadere che il \textit{three
   way handshake} \itindex{three~way~handshake} venga completato e la relativa
 connessione abortita subito dopo, prima che il padre, per via del carico della
 macchina, abbia fatto in tempo ad eseguire la chiamata ad \func{accept}. Di
@@ -2307,14 +2307,14 @@ ritorno di \func{accept}, sono \errcode{ENETDOWN}, \errcode{EPROTO},
 \errcode{ENOPROTOOPT}, \errcode{EHOSTDOWN}, \errcode{ENONET},
 \errcode{EHOSTUNREACH}, \errcode{EOPNOTSUPP} e \errcode{ENETUNREACH}.
 
-Si tenga presente che questo tipo di terminazione non è riproducibile
+Si tenga presente che questo tipo di terminazione non è riproducibile
 terminando il client prima della chiamata ad \func{accept}, come si potrebbe
 fare usando l'opzione \texttt{-w} per introdurre una pausa dopo il lancio del
 demone, in modo da poter avere il tempo per lanciare e terminare una
 connessione usando il programma client. In tal caso infatti, alla terminazione
 del client, il socket associato alla connessione viene semplicemente chiuso,
 attraverso la sequenza vista in sez.~\ref{sec:TCP_conn_term}, per cui la
-\func{accept} ritornerà senza errori, e si avrà semplicemente un end-of-file
+\func{accept} ritornerà senza errori, e si avrà semplicemente un end-of-file
 al primo accesso al socket. Nel caso di Linux inoltre, anche qualora si
 modifichi il client per fargli gestire l'invio di un segmento di RST alla
 chiusura dal socket (usando l'opzione \const{SO\_LINGER}, vedi
@@ -2327,19 +2327,19 @@ accesso al socket.
 \subsection{La terminazione precoce del server}
 \label{sec:TCP_server_crash}
 
-Un secondo caso critico è quello in cui si ha una terminazione precoce del
-server, ad esempio perché il programma ha un crash. In tal caso si suppone che
+Un secondo caso critico è quello in cui si ha una terminazione precoce del
+server, ad esempio perché il programma ha un crash. In tal caso si suppone che
 il processo termini per un errore fatale, cosa che potremo simulare
 inviandogli un segnale di terminazione. La conclusione del processo comporta
 la chiusura di tutti i file descriptor aperti, compresi tutti i socket
 relativi a connessioni stabilite; questo significa che al momento del crollo
-del servizio il client riceverà un FIN dal server in corrispondenza della
+del servizio il client riceverà un FIN dal server in corrispondenza della
 chiusura del socket.
 
 Vediamo allora cosa succede nel nostro caso, facciamo partire una connessione
 con il server e scriviamo una prima riga, poi terminiamo il server con un
 \texttt{C-c}. A questo punto scriviamo una seconda riga e poi un'altra riga
-ancora. Il risultato finale della sessione è il seguente:
+ancora. Il risultato finale della sessione è il seguente:
 \begin{verbatim}
 [piccardi@gont sources]$ ./echo 192.168.1.141
 Prima riga
@@ -2354,13 +2354,13 @@ prima dell'invio della seconda riga, non solo accetta di inviarla, ma prende
 anche un'altra riga prima di terminare senza riportare nessun
 errore. 
 
-Per capire meglio cosa è successo conviene analizzare il flusso dei pacchetti
+Per capire meglio cosa è successo conviene analizzare il flusso dei pacchetti
 utilizzando un analizzatore di traffico come \cmd{tcpdump}. Il comando
 permette di selezionare, nel traffico di rete generato su una macchina, i
 pacchetti che interessano, stampando a video (o salvando su disco) il loro
 contenuto. Non staremo qui ad entrare nei dettagli dell'uso del programma, che
 sono spiegati dalla pagina di manuale; per l'uso che vogliamo farne quello che
-ci interessa è, posizionandosi sulla macchina che fa da client, selezionare
+ci interessa è, posizionandosi sulla macchina che fa da client, selezionare
 tutti i pacchetti che sono diretti o provengono dalla macchina che fa da
 server. In questo modo (posto che non ci siano altre connessioni col server,
 cosa che avremo cura di evitare) tutti i pacchetti rilevati apparterranno alla
@@ -2376,7 +2376,7 @@ formato configurabile in maniera molto precisa).
 
 Lanciando il comando prima di ripetere la sessione di lavoro mostrata
 nell'esempio precedente potremo allora catturare tutti pacchetti scambiati fra
-il client ed il server; i risultati\footnote{in realtà si è ridotta la
+il client ed il server; i risultati\footnote{in realtà si è ridotta la
   lunghezza dell'output rispetto al reale tagliando alcuni dati non necessari
   alla comprensione del flusso.} prodotti in questa occasione da \cmd{tcpdump}
 sono allora i seguenti:
@@ -2405,7 +2405,7 @@ sempre attivo il campo \texttt{ack}, seguito dal numero di sequenza per il
 quale si da il ricevuto; quest'ultimo, a partire dal terzo pacchetto, viene
 espresso in forma relativa per maggiore compattezza.  Il campo \texttt{win} in
 ogni riga indica la \itindex{advertised~window} \textit{advertised window} di
-cui parlavamo in sez.~\ref{sec:TCP_TCP_opt}.  Allora si può verificare
+cui parlavamo in sez.~\ref{sec:TCP_TCP_opt}.  Allora si può verificare
 dall'output del comando come venga appunto realizzata la sequenza di pacchetti
 descritta in sez.~\ref{sec:TCP_conn_cre}: prima viene inviato dal client un
 primo pacchetto con il SYN che inizia la connessione, a cui il server risponde
@@ -2417,25 +2417,25 @@ del \itindex{three~way~handshake} \textit{three way handshake} non avremo
 nulla fin tanto che non scriveremo una prima riga sul client; al momento in
 cui facciamo questo si genera una sequenza di altri quattro pacchetti. Il
 primo, dal client al server, contraddistinto da una lettera \texttt{P} che
-significa che il flag PSH è impostato, contiene la nostra riga (che è appunto
+significa che il flag PSH è impostato, contiene la nostra riga (che è appunto
 di 11 caratteri), e ad esso il server risponde immediatamente con un pacchetto
-vuoto di ricevuto. Poi tocca al server riscrivere indietro quanto gli è stato
-inviato, per cui sarà lui a mandare indietro un terzo pacchetto con lo stesso
-contenuto appena ricevuto, e a sua volta riceverà dal client un ACK nel quarto
-pacchetto.  Questo causerà la ricezione dell'eco nel client che lo stamperà a
+vuoto di ricevuto. Poi tocca al server riscrivere indietro quanto gli è stato
+inviato, per cui sarà lui a mandare indietro un terzo pacchetto con lo stesso
+contenuto appena ricevuto, e a sua volta riceverà dal client un ACK nel quarto
+pacchetto.  Questo causerà la ricezione dell'eco nel client che lo stamperà a
 video.
 
 A questo punto noi procediamo ad interrompere l'esecuzione del server con un
-\texttt{C-c} (cioè con l'invio di \const{SIGTERM}): nel momento in cui
+\texttt{C-c} (cioè con l'invio di \const{SIGTERM}): nel momento in cui
 facciamo questo vengono immediatamente generati altri due pacchetti. La
 terminazione del processo infatti comporta la chiusura di tutti i suoi file
 descriptor, il che comporta, per il socket che avevamo aperto, l'inizio della
 sequenza di chiusura illustrata in sez.~\ref{sec:TCP_conn_term}.  Questo
-significa che dal server partirà un FIN, che è appunto il primo dei due
-pacchetti, contraddistinto dalla lettera \texttt{F}, cui seguirà al solito un
+significa che dal server partirà un FIN, che è appunto il primo dei due
+pacchetti, contraddistinto dalla lettera \texttt{F}, cui seguirà al solito un
 ACK da parte del client.  
 
-A questo punto la connessione dalla parte del server è chiusa, ed infatti se
+A questo punto la connessione dalla parte del server è chiusa, ed infatti se
 usiamo \cmd{netstat} per controllarne lo stato otterremo che sul server si ha:
 \begin{verbatim}
 anarres:/home/piccardi# netstat -ant
@@ -2444,8 +2444,8 @@ Proto Recv-Q Send-Q Local Address           Foreign Address         State
 ...      ...    ... ...                     ...                     ...
 tcp        0      0 192.168.1.141:7         192.168.1.2:34626       FIN_WAIT2
 \end{verbatim}
-cioè essa è andata nello stato \texttt{FIN\_WAIT2}, che indica l'avvenuta
-emissione del segmento FIN, mentre sul client otterremo che essa è andata
+cioè essa è andata nello stato \texttt{FIN\_WAIT2}, che indica l'avvenuta
+emissione del segmento FIN, mentre sul client otterremo che essa è andata
 nello stato \texttt{CLOSE\_WAIT}:
 \begin{verbatim}
 [root@gont gapil]# netstat -ant
@@ -2455,57 +2455,57 @@ Proto Recv-Q Send-Q Local Address           Foreign Address         State
 tcp        1      0 192.168.1.2:34582       192.168.1.141:7         CLOSE_WAIT 
 \end{verbatim}
 
-Il problema è che in questo momento il client è bloccato dentro la funzione
+Il problema è che in questo momento il client è bloccato dentro la funzione
 \texttt{ClientEcho} nella chiamata a \func{fgets}, e sta attendendo dell'input
-dal terminale, per cui non è in grado di accorgersi di nulla. Solo quando
-inseriremo la seconda riga il comando uscirà da \func{fgets} e proverà a
+dal terminale, per cui non è in grado di accorgersi di nulla. Solo quando
+inseriremo la seconda riga il comando uscirà da \func{fgets} e proverà a
 scriverla sul socket. Questo comporta la generazione degli ultimi due
 pacchetti riportati da \cmd{tcpdump}: il primo, inviato dal client contenente
 i 25 caratteri della riga appena letta, e ad esso la macchina server
-risponderà, non essendoci più niente in ascolto sulla porta 7, con un segmento
+risponderà, non essendoci più niente in ascolto sulla porta 7, con un segmento
 di RST, contraddistinto dalla lettera \texttt{R}, che causa la conclusione
-definitiva della connessione anche nel client, dove non comparirà più
+definitiva della connessione anche nel client, dove non comparirà più
 nell'output di \cmd{netstat}.
 
-Come abbiamo accennato in sez.~\ref{sec:TCP_conn_term} e come vedremo più
+Come abbiamo accennato in sez.~\ref{sec:TCP_conn_term} e come vedremo più
 avanti in sez.~\ref{sec:TCP_shutdown} la chiusura di un solo capo di un socket
-è una operazione lecita, per cui la nostra scrittura avrà comunque successo
-(come si può constatare lanciando usando \cmd{strace}\footnote{il comando
-  \cmd{strace} è un comando di debug molto utile che prende come argomento un
+è una operazione lecita, per cui la nostra scrittura avrà comunque successo
+(come si può constatare lanciando usando \cmd{strace}\footnote{il comando
+  \cmd{strace} è un comando di debug molto utile che prende come argomento un
   altro comando e ne stampa a video tutte le invocazioni di una system call,
   coi relativi argomenti e valori di ritorno, per cui usandolo in questo
   contesto potremo verificare che effettivamente la \func{write} ha scritto la
-  riga, che in effetti è stata pure trasmessa via rete.}), in quanto il nostro
+  riga, che in effetti è stata pure trasmessa via rete.}), in quanto il nostro
 programma non ha a questo punto alcun modo di sapere che dall'altra parte non
-c'è più nessuno processo in grado di leggere quanto scriverà. Questo sarà
+c'è più nessuno processo in grado di leggere quanto scriverà. Questo sarà
 chiaro solo dopo il tentativo di scrittura, e la ricezione del segmento RST di
-risposta che indica che dall'altra parte non si è semplicemente chiuso un capo
-del socket, ma è completamente terminato il programma.
+risposta che indica che dall'altra parte non si è semplicemente chiuso un capo
+del socket, ma è completamente terminato il programma.
 
-Per questo motivo il nostro client proseguirà leggendo dal socket, e dato che
-questo è stato chiuso avremo che, come spiegato in
+Per questo motivo il nostro client proseguirà leggendo dal socket, e dato che
+questo è stato chiuso avremo che, come spiegato in
 sez.~\ref{sec:TCP_conn_term}, la funzione \func{read} ritorna normalmente con
 un valore nullo. Questo comporta che la seguente chiamata a \func{fputs} non
 ha effetto (viene stampata una stringa nulla) ed il client si blocca di nuovo
 nella successiva chiamata a \func{fgets}. Per questo diventa possibile
-inserire una terza riga e solo dopo averlo fatto si avrà la terminazione del
+inserire una terza riga e solo dopo averlo fatto si avrà la terminazione del
 programma.
 
 Per capire come questa avvenga comunque, non avendo inserito nel codice nessun
-controllo di errore, occorre ricordare che, a parte la bidirezionalità del
+controllo di errore, occorre ricordare che, a parte la bidirezionalità del
 flusso dei dati, dal punto di vista del funzionamento nei confronti delle
 funzioni di lettura e scrittura, i socket sono del tutto analoghi a delle
 pipe. Allora, da quanto illustrato in sez.~\ref{sec:ipc_pipes}, sappiamo che
-tutte le volte che si cerca di scrivere su una pipe il cui altro capo non è
-aperto il lettura il processo riceve un segnale di \const{SIGPIPE}, e questo è
+tutte le volte che si cerca di scrivere su una pipe il cui altro capo non è
+aperto il lettura il processo riceve un segnale di \const{SIGPIPE}, e questo è
 esattamente quello che avviene in questo caso, e siccome non abbiamo un
-gestore per questo segnale, viene eseguita l'azione preimpostata, che è quella
+gestore per questo segnale, viene eseguita l'azione preimpostata, che è quella
 di terminare il processo.
 
-Per gestire in maniera più corretta questo tipo di evento dovremo allora
-modificare il nostro client perché sia in grado di trattare le varie tipologie
+Per gestire in maniera più corretta questo tipo di evento dovremo allora
+modificare il nostro client perché sia in grado di trattare le varie tipologie
 di errore, per questo dovremo riscrivere la funzione \func{ClientEcho}, in
-modo da controllare gli stati di uscita delle varie chiamate. Si è riportata
+modo da controllare gli stati di uscita delle varie chiamate. Si è riportata
 la nuova versione della funzione in fig.~\ref{fig:TCP_ClientEcho_second}.
 
 \begin{figure}[!htb]
@@ -2520,7 +2520,7 @@ la nuova versione della funzione in fig.~\ref{fig:TCP_ClientEcho_second}.
   \label{fig:TCP_ClientEcho_second}
 \end{figure}
 
-Come si può vedere in questo caso si controlla il valore di ritorno di tutte
+Come si può vedere in questo caso si controlla il valore di ritorno di tutte
 le funzioni, ed inoltre si verifica la presenza di un eventuale end of file in
 caso di lettura. Con questa modifica il nostro client echo diventa in grado di
 accorgersi della chiusura del socket da parte del server, per cui ripetendo la
@@ -2532,18 +2532,18 @@ Prima riga
 Seconda riga dopo il C-c
 EOF sul socket
 \end{verbatim}%$
-ma di nuovo si tenga presente che non c'è modo di accorgersi della chiusura
+ma di nuovo si tenga presente che non c'è modo di accorgersi della chiusura
 del socket fin quando non si esegue la scrittura della seconda riga; il
 protocollo infatti prevede che ci debba essere una scrittura prima di ricevere
 un RST che confermi la chiusura del file, e solo alle successive scritture si
-potrà ottenere un errore.
+potrà ottenere un errore.
 
 Questa caratteristica dei socket ci mette di fronte ad un altro problema
-relativo al nostro client, e che cioè esso non è in grado di accorgersi di
-nulla fintanto che è bloccato nella lettura del terminale fatta con
-\func{gets}. In questo caso il problema è minimo, ma esso riemergerà più
-avanti, ed è quello che si deve affrontare tutte le volte quando si ha a che
-fare con la necessità di lavorare con più descrittori, nel qual caso diventa
+relativo al nostro client, e che cioè esso non è in grado di accorgersi di
+nulla fintanto che è bloccato nella lettura del terminale fatta con
+\func{gets}. In questo caso il problema è minimo, ma esso riemergerà più
+avanti, ed è quello che si deve affrontare tutte le volte quando si ha a che
+fare con la necessità di lavorare con più descrittori, nel qual caso diventa
 si pone la questione di come fare a non restare bloccati su un socket quando
 altri potrebbero essere liberi. Vedremo come affrontare questa problematica in
 sez.~\ref{sec:TCP_sock_multiplexing}.
@@ -2552,21 +2552,21 @@ sez.~\ref{sec:TCP_sock_multiplexing}.
 \subsection{Altri scenari di terminazione della connessione}
 \label{sec:TCP_conn_crash}
 
-La terminazione del server è solo uno dei possibili scenari di terminazione
-della connessione, un altro caso è ad esempio quello in cui si ha un crollo
+La terminazione del server è solo uno dei possibili scenari di terminazione
+della connessione, un altro caso è ad esempio quello in cui si ha un crollo
 della rete, cosa che potremo simulare facilmente staccando il cavo di rete.
-Un'altra condizione è quella di un blocco della macchina completo della su cui
+Un'altra condizione è quella di un blocco della macchina completo della su cui
 gira il server che deve essere riavviata, cosa che potremo simulare sia
 premendo il bottone di reset,\footnote{un normale shutdown non va bene; in tal
   caso infatti il sistema provvede a terminare tutti i processi, per cui la
   situazione sarebbe sostanzialmente identica alla precedente.} che, in
-maniera più gentile, riavviando la macchina dopo aver interrotto la
+maniera più gentile, riavviando la macchina dopo aver interrotto la
 connessione di rete.
 
 Cominciamo ad analizzare il primo caso, il crollo della rete. Ripetiamo la
 nostra sessione di lavoro precedente, lanciamo il client, scriviamo una prima
 riga, poi stacchiamo il cavo e scriviamo una seconda riga. Il risultato che
-otterremo è:
+otterremo è:
 \begin{verbatim}
 [piccardi@gont sources]$ ./echo 192.168.1.141
 Prima riga
@@ -2575,11 +2575,11 @@ Seconda riga dopo l'interruzione
 Errore in lettura: No route to host
 \end{verbatim}%$
 
-Quello che succede in questo è che il programma, dopo aver scritto la seconda
+Quello che succede in questo è che il programma, dopo aver scritto la seconda
 riga, resta bloccato per un tempo molto lungo, prima di dare l'errore
 \errcode{EHOSTUNREACH}.  Se andiamo ad osservare con \cmd{strace} cosa accade
-nel periodo in cui il programma è bloccato vedremo che stavolta, a differenza
-del caso precedente, il programma è bloccato nella lettura dal socket.
+nel periodo in cui il programma è bloccato vedremo che stavolta, a differenza
+del caso precedente, il programma è bloccato nella lettura dal socket.
 
 Se poi, come nel caso precedente, usiamo l'accortezza di analizzare il
 traffico di rete fra client e server con \cmd{tcpdump}, otterremo il seguente
@@ -2612,10 +2612,10 @@ arp who-has anarres tell gont
 ...
 \end{verbatim}
 
-In questo caso l'andamento dei primi sette pacchetti è esattamente lo stesso
+In questo caso l'andamento dei primi sette pacchetti è esattamente lo stesso
 di prima. Solo che stavolta, non appena inviata la seconda riga, il programma
-si bloccherà nella successiva chiamata a \func{read}, non ottenendo nessuna
-risposta. Quello che succede è che nel frattempo il kernel provvede, come
+si bloccherà nella successiva chiamata a \func{read}, non ottenendo nessuna
+risposta. Quello che succede è che nel frattempo il kernel provvede, come
 richiesto dal protocollo TCP, a tentare la ritrasmissione della nostra riga un
 certo numero di volte, con tempi di attesa crescente fra un tentativo ed il
 successivo, per tentare di ristabilire la connessione.
@@ -2628,10 +2628,10 @@ in questo caso in particolare da
 sez.~\ref{sec:sock_ipv4_sysctl}). Questo parametro infatti specifica il numero
 di volte che deve essere ritentata la ritrasmissione di un pacchetto nel mezzo
 di una connessione prima di riportare un errore di timeout.  Il valore
-preimpostato è pari a 15, il che comporterebbe 15 tentativi di ritrasmissione,
+preimpostato è pari a 15, il che comporterebbe 15 tentativi di ritrasmissione,
 ma nel nostro caso le cose sono andate diversamente, dato che le
 ritrasmissioni registrate da \cmd{tcpdump} sono solo 8; inoltre l'errore
-riportato all'uscita del client non è stato \errcode{ETIMEDOUT}, come dovrebbe
+riportato all'uscita del client non è stato \errcode{ETIMEDOUT}, come dovrebbe
 essere in questo caso, ma \errcode{EHOSTUNREACH}.
 
 Per capire l'accaduto continuiamo ad analizzare l'output di \cmd{tcpdump}:
@@ -2639,11 +2639,11 @@ esso ci mostra che a un certo punto i tentativi di ritrasmissione del
 pacchetto sono cessati, per essere sostituiti da una serie di richieste di
 protocollo ARP in cui il client richiede l'indirizzo del server.
 
-Come abbiamo accennato in sez.~\ref{sec:net_tcpip_general} ARP è il protocollo
+Come abbiamo accennato in sez.~\ref{sec:net_tcpip_general} ARP è il protocollo
 che si incarica di trovare le corrispondenze fra indirizzo IP e indirizzo
-hardware sulla scheda di rete. È evidente allora che nel nostro caso, essendo
-client e server sulla stessa rete, è scaduta la voce nella \textit{ARP
-  cache}\footnote{la \textit{ARP cache} è una tabella mantenuta internamente
+hardware sulla scheda di rete. È evidente allora che nel nostro caso, essendo
+client e server sulla stessa rete, è scaduta la voce nella \textit{ARP
+  cache}\footnote{la \textit{ARP cache} è una tabella mantenuta internamente
   dal kernel che contiene tutte le corrispondenze fra indirizzi IP e indirizzi
   fisici, ottenute appunto attraverso il protocollo ARP; le voci della tabella
   hanno un tempo di vita limitato, passato il quale scadono e devono essere
@@ -2651,21 +2651,21 @@ client e server sulla stessa rete, 
 iniziato ad effettuare richieste ARP sulla rete per sapere l'IP di
 quest'ultimo, che essendo scollegato non poteva rispondere. Anche per questo
 tipo di richieste esiste un timeout, per cui dopo un certo numero di tentativi
-il meccanismo si è interrotto, e l'errore riportato al programma a questo
-punto è stato \errcode{EHOSTUNREACH}, in quanto non si era più in grado di
+il meccanismo si è interrotto, e l'errore riportato al programma a questo
+punto è stato \errcode{EHOSTUNREACH}, in quanto non si era più in grado di
 contattare il server.
 
-Un altro errore possibile in questo tipo di situazione, che si può avere
-quando la macchina è su una rete remota, è \errcode{ENETUNREACH}; esso viene
+Un altro errore possibile in questo tipo di situazione, che si può avere
+quando la macchina è su una rete remota, è \errcode{ENETUNREACH}; esso viene
 riportato alla ricezione di un pacchetto ICMP di \textit{destination
   unreachable} da parte del router che individua l'interruzione della
-connessione. Di nuovo anche qui il risultato finale dipende da quale è il
-meccanismo più veloce ad accorgersi del problema.
+connessione. Di nuovo anche qui il risultato finale dipende da quale è il
+meccanismo più veloce ad accorgersi del problema.
 
-Se però agiamo sui parametri del kernel, e scriviamo in \file{tcp\_retries2}
-un valore di tentativi più basso, possiamo evitare la scadenza della
-\textit{ARP cache} e vedere cosa succede. Così se ad esempio richiediamo 4
-tentativi di ritrasmissione, l'analisi di \cmd{tcpdump} ci riporterà il
+Se però agiamo sui parametri del kernel, e scriviamo in \file{tcp\_retries2}
+un valore di tentativi più basso, possiamo evitare la scadenza della
+\textit{ARP cache} e vedere cosa succede. Così se ad esempio richiediamo 4
+tentativi di ritrasmissione, l'analisi di \cmd{tcpdump} ci riporterà il
 seguente scambio di pacchetti:
 \begin{verbatim}
 [root@gont gapil]# tcpdump src 192.168.1.141 or dst 192.168.1.141 -N -t
@@ -2685,9 +2685,9 @@ gont.34752 > anarres.echo: P 12:45(33) ack 12 win 5840
 \end{verbatim}
 e come si vede in questo caso i tentativi di ritrasmissione del pacchetto
 iniziale sono proprio 4 (per un totale di 5 voci con quello trasmesso la prima
-volta), ed in effetti, dopo un tempo molto più breve rispetto a prima ed in
+volta), ed in effetti, dopo un tempo molto più breve rispetto a prima ed in
 corrispondenza dell'invio dell'ultimo tentativo, quello che otterremo come
-errore all'uscita del client sarà diverso, e cioè:
+errore all'uscita del client sarà diverso, e cioè:
 \begin{verbatim}
 [piccardi@gont sources]$ ./echo 192.168.1.141
 Prima riga
@@ -2702,7 +2702,7 @@ Analizziamo ora il secondo scenario, in cui si ha un crollo della macchina che
 fa da server. Al solito lanciamo il nostro client, scriviamo una prima riga
 per verificare che sia tutto a posto, poi stacchiamo il cavo e riavviamo il
 server. A questo punto, ritornato attivo il server, scriviamo una seconda
-riga. Quello che otterremo in questo caso è:
+riga. Quello che otterremo in questo caso è:
 \begin{verbatim}
 [piccardi@gont sources]$ ./echo 192.168.1.141
 Prima riga
@@ -2710,7 +2710,7 @@ Prima riga
 Seconda riga dopo l'interruzione
 Errore in lettura Connection reset by peer
 \end{verbatim}%$
-e l'errore ricevuti da \func{read} stavolta è \errcode{ECONNRESET}. Se al
+e l'errore ricevuti da \func{read} stavolta è \errcode{ECONNRESET}. Se al
 solito riportiamo l'analisi dei pacchetti effettuata con \cmd{tcpdump},
 avremo:
 \begin{verbatim}
@@ -2728,20 +2728,20 @@ anarres.echo > gont.34756: R 4254564883:4254564883(0) win 0
 \end{verbatim}
 
 Ancora una volta i primi sette pacchetti sono gli stessi; ma in questo caso
-quello che succede dopo lo scambio iniziale è che, non avendo inviato nulla
-durante il periodo in cui si è riavviato il server, il client è del tutto
-ignaro dell'accaduto per cui quando effettuerà una scrittura, dato che la
-macchina server è stata riavviata e che tutti gli stati relativi alle
+quello che succede dopo lo scambio iniziale è che, non avendo inviato nulla
+durante il periodo in cui si è riavviato il server, il client è del tutto
+ignaro dell'accaduto per cui quando effettuerà una scrittura, dato che la
+macchina server è stata riavviata e che tutti gli stati relativi alle
 precedenti connessioni sono completamente persi, anche in presenza di una
-nuova istanza del server echo non sarà possibile consegnare i dati in arrivo,
-per cui alla loro ricezione il kernel risponderà con un segmento di RST.
+nuova istanza del server echo non sarà possibile consegnare i dati in arrivo,
+per cui alla loro ricezione il kernel risponderà con un segmento di RST.
 
-Il client da parte sua, dato che neanche in questo caso non è stato emesso un
-FIN, dopo aver scritto verrà bloccato nella successiva chiamata a \func{read},
-che però adesso ritornerà immediatamente alla ricezione del segmento RST,
+Il client da parte sua, dato che neanche in questo caso non è stato emesso un
+FIN, dopo aver scritto verrà bloccato nella successiva chiamata a \func{read},
+che però adesso ritornerà immediatamente alla ricezione del segmento RST,
 riportando appunto come errore \errcode{ECONNRESET}. Occorre precisare che se
 si vuole che il client sia in grado di accorgersi del crollo del server anche
-quando non sta effettuando uno scambio di dati, è possibile usare una
+quando non sta effettuando uno scambio di dati, è possibile usare una
 impostazione speciale del socket (ci torneremo in
 sez.~\ref{sec:sock_generic_options}) che provvede all'esecuzione di questo
 controllo.
@@ -2751,17 +2751,17 @@ controllo.
 \label{sec:TCP_sock_multiplexing}
 
 Affronteremo in questa sezione l'utilizzo dell'I/O multiplexing, affrontato in
-sez.~\ref{sec:file_multiplexing}, nell'ambito delle applicazioni di rete. Già
+sez.~\ref{sec:file_multiplexing}, nell'ambito delle applicazioni di rete. Già
 in sez.~\ref{sec:TCP_server_crash} era emerso il problema relativo al client
 del servizio echo che non era in grado di accorgersi della terminazione
 precoce del server, essendo bloccato nella lettura dei dati immessi da
 tastiera.
 
-Abbiamo visto in sez.~\ref{sec:file_multiplexing} quali sono le funzionalità
-del sistema che ci permettono di tenere sotto controllo più file descriptor in
+Abbiamo visto in sez.~\ref{sec:file_multiplexing} quali sono le funzionalità
+del sistema che ci permettono di tenere sotto controllo più file descriptor in
 contemporanea; in quella occasione non abbiamo fatto esempi, in quanto quando
 si tratta con file normali questa tipologia di I/O normalmente non viene
-usata, è invece un caso tipico delle applicazioni di rete quello di dover
+usata, è invece un caso tipico delle applicazioni di rete quello di dover
 gestire varie connessioni da cui possono arrivare dati comuni in maniera
 asincrona, per cui riprenderemo l'argomento in questa sezione.
 
@@ -2770,14 +2770,14 @@ asincrona, per cui riprenderemo l'argomento in questa sezione.
 \label{sec:TCP_sock_select}
 
 Iniziamo con la prima delle funzioni usate per l'I/O multiplexing,
-\func{select}; il suo funzionamento è già stato descritto in dettaglio in
-sez.~\ref{sec:file_multiplexing} e non staremo a ripetere quanto detto lì; 
-sappiamo che la funzione ritorna quando uno o più dei file descriptor messi
-sotto controllo è pronto per la relativa operazione.
+\func{select}; il suo funzionamento è già stato descritto in dettaglio in
+sez.~\ref{sec:file_multiplexing} e non staremo a ripetere quanto detto lì; 
+sappiamo che la funzione ritorna quando uno o più dei file descriptor messi
+sotto controllo è pronto per la relativa operazione.
 
-In quell'occasione non abbiamo però definito cosa si intende per pronto,
+In quell'occasione non abbiamo però definito cosa si intende per pronto,
 infatti per dei normali file, o anche per delle pipe, la condizione di essere
-pronti per la lettura o la scrittura è ovvia; invece lo è molto meno nel caso
+pronti per la lettura o la scrittura è ovvia; invece lo è molto meno nel caso
 dei socket, visto che possono intervenire tutte una serie di possibili
 condizioni di errore dovute alla rete. Occorre allora specificare chiaramente
 quali sono le condizioni per cui un socket risulta essere ``\textsl{pronto}''
@@ -2785,64 +2785,64 @@ quando viene passato come membro di uno dei tre \itindex{file~descriptor~set}
 \textit{file descriptor set} usati da \func{select}.
 
 Le condizioni che fanno si che la funzione \func{select} ritorni segnalando
-che un socket (che sarà riportato nel primo insieme di file descriptor) è
+che un socket (che sarà riportato nel primo insieme di file descriptor) è
 pronto per la lettura sono le seguenti:
 \begin{itemize*}
-\item nel buffer di ricezione del socket sono arrivati dei dati in quantità
+\item nel buffer di ricezione del socket sono arrivati dei dati in quantità
   sufficiente a superare il valore di una \textsl{soglia di basso livello} (il
-  cosiddetto \textit{low watermark}). Questo valore è espresso in numero di
-  byte e può essere impostato con l'opzione del socket \const{SO\_RCVLOWAT}
+  cosiddetto \textit{low watermark}). Questo valore è espresso in numero di
+  byte e può essere impostato con l'opzione del socket \const{SO\_RCVLOWAT}
   (tratteremo l'uso di questa opzione in sez.~\ref{sec:sock_generic_options});
-  il suo valore di default è 1 per i socket TCP e UDP. In questo caso una
-  operazione di lettura avrà successo e leggerà un numero di byte maggiore di
+  il suo valore di default è 1 per i socket TCP e UDP. In questo caso una
+  operazione di lettura avrà successo e leggerà un numero di byte maggiore di
   zero.
-\item il lato in lettura della connessione è stato chiuso; si è cioè ricevuto
+\item il lato in lettura della connessione è stato chiuso; si è cioè ricevuto
   un segmento FIN (si ricordi quanto illustrato in
   sez.~\ref{sec:TCP_conn_term}) sulla connessione. In questo caso una
-  operazione di lettura avrà successo, ma non risulteranno presenti dati (in
-  sostanza \func{read} ritornerà con un valore nullo) per indicare la
+  operazione di lettura avrà successo, ma non risulteranno presenti dati (in
+  sostanza \func{read} ritornerà con un valore nullo) per indicare la
   condizione di end-of-file.
-\item c'è stato un errore sul socket. In questo caso una operazione di lettura
-  non si bloccherà ma restituirà una condizione di errore (ad esempio
-  \func{read} restituirà -1) e imposterà la variabile \var{errno} al relativo
+\item c'è stato un errore sul socket. In questo caso una operazione di lettura
+  non si bloccherà ma restituirà una condizione di errore (ad esempio
+  \func{read} restituirà -1) e imposterà la variabile \var{errno} al relativo
   valore. Vedremo in sez.~\ref{sec:sock_generic_options} come sia possibile
   estrarre e cancellare gli errori pendenti su un socket senza usare
   \func{read} usando l'opzione \const{SO\_ERROR}.
 \item quando si sta utilizzando un \textit{listening socket} ed ci sono delle
   connessioni completate. In questo caso la funzione \func{accept} non si
-  bloccherà.\footnote{in realtà questo non è sempre vero, come accennato in
-    sez.~\ref{sec:TCP_conn_early_abort} una connessione può essere abortita
-    dalla ricezione di un segmento RST una volta che è stata completata,
-    allora se questo avviene dopo che \func{select} è ritornata, ma prima
+  bloccherà.\footnote{in realtà questo non è sempre vero, come accennato in
+    sez.~\ref{sec:TCP_conn_early_abort} una connessione può essere abortita
+    dalla ricezione di un segmento RST una volta che è stata completata,
+    allora se questo avviene dopo che \func{select} è ritornata, ma prima
     della chiamata ad \func{accept}, quest'ultima, in assenza di altre
-    connessioni, potrà bloccarsi.}
+    connessioni, potrà bloccarsi.}
 \end{itemize*}
 
 Le condizioni che fanno si che la funzione \func{select} ritorni segnalando
-che un socket (che sarà riportato nel secondo insieme di file descriptor) è
+che un socket (che sarà riportato nel secondo insieme di file descriptor) è
 pronto per la scrittura sono le seguenti:
 \begin{itemize*}
-\item nel buffer di invio è disponibile una quantità di spazio superiore al
+\item nel buffer di invio è disponibile una quantità di spazio superiore al
   valore della \textsl{soglia di basso livello} in scrittura ed inoltre o il
-  socket è già connesso o non necessita (ad esempio è UDP) di connessione.  Il
-  valore della soglia è espresso in numero di byte e può essere impostato con
+  socket è già connesso o non necessita (ad esempio è UDP) di connessione.  Il
+  valore della soglia è espresso in numero di byte e può essere impostato con
   l'opzione del socket \const{SO\_SNDLOWAT} (trattata in
-  sez.~\ref{sec:sock_generic_options}); il suo valore di default è 2048 per i
+  sez.~\ref{sec:sock_generic_options}); il suo valore di default è 2048 per i
   socket TCP e UDP. In questo caso una operazione di scrittura non si
-  bloccherà e restituirà un valore positivo pari al numero di byte accettati
+  bloccherà e restituirà un valore positivo pari al numero di byte accettati
   dal livello di trasporto.
-\item il lato in scrittura della connessione è stato chiuso. In questo caso
-  una operazione di scrittura sul socket genererà il segnale \const{SIGPIPE}.
-\item c'è stato un errore sul socket. In questo caso una operazione di
-  scrittura non si bloccherà ma restituirà una condizione di errore ed
-  imposterà opportunamente la variabile \var{errno}. Vedremo in
+\item il lato in scrittura della connessione è stato chiuso. In questo caso
+  una operazione di scrittura sul socket genererà il segnale \const{SIGPIPE}.
+\item c'è stato un errore sul socket. In questo caso una operazione di
+  scrittura non si bloccherà ma restituirà una condizione di errore ed
+  imposterà opportunamente la variabile \var{errno}. Vedremo in
   sez.~\ref{sec:sock_generic_options} come sia possibile estrarre e cancellare
   errori pendenti su un socket usando l'opzione \const{SO\_ERROR}.
 \end{itemize*}
 
-Infine c'è una sola condizione che fa si che \func{select} ritorni segnalando
-che un socket (che sarà riportato nel terzo insieme di file descriptor) ha una
-condizione di eccezione pendente, e cioè la ricezione sul socket di
+Infine c'è una sola condizione che fa si che \func{select} ritorni segnalando
+che un socket (che sarà riportato nel terzo insieme di file descriptor) ha una
+condizione di eccezione pendente, e cioè la ricezione sul socket di
 \textsl{dati urgenti} (o \itindex{out-of-band} \textit{out-of-band}), una
 caratteristica specifica dei socket TCP su cui torneremo in
 sez.~\ref{sec:TCP_urgent_data}.
@@ -2850,22 +2850,22 @@ sez.~\ref{sec:TCP_urgent_data}.
 Si noti come nel caso della lettura \func{select} si applichi anche ad
 operazioni che non hanno nulla a che fare con l'I/O di dati come il
 riconoscimento della presenza di connessioni pronte, in modo da consentire
-anche l'utilizzo di \func{accept} in modalità non bloccante. Si noti infine
+anche l'utilizzo di \func{accept} in modalità non bloccante. Si noti infine
 come in caso di errore un socket venga sempre riportato come pronto sia per la
 lettura che per la scrittura.
 
-Lo scopo dei due valori di soglia per i buffer di ricezione e di invio è
-quello di consentire maggiore flessibilità nell'uso di \func{select} da parte
-dei programmi, se infatti si sa che una applicazione non è in grado di fare
-niente fintanto che non può ricevere o inviare una certa quantità di dati, si
+Lo scopo dei due valori di soglia per i buffer di ricezione e di invio è
+quello di consentire maggiore flessibilità nell'uso di \func{select} da parte
+dei programmi, se infatti si sa che una applicazione non è in grado di fare
+niente fintanto che non può ricevere o inviare una certa quantità di dati, si
 possono utilizzare questi valori per far si che \func{select} ritorni solo
-quando c'è la certezza di avere dati a sufficienza.\footnote{questo tipo di
-  controllo è utile di norma solo per la lettura, in quanto in genere le
-  operazioni di scrittura sono già controllate dall'applicazione, che sa
-  sempre quanti dati invia, mentre non è detto possa conoscere la quantità di
+quando c'è la certezza di avere dati a sufficienza.\footnote{questo tipo di
+  controllo è utile di norma solo per la lettura, in quanto in genere le
+  operazioni di scrittura sono già controllate dall'applicazione, che sa
+  sempre quanti dati invia, mentre non è detto possa conoscere la quantità di
   dati in ricezione; per cui, nella situazione in cui si conosce almeno un
   valore minimo, per evitare la penalizzazione dovuta alla ripetizione delle
-  operazioni di lettura per accumulare dati sufficienti, si può lasciare al
+  operazioni di lettura per accumulare dati sufficienti, si può lasciare al
   kernel il compito di impostare un minimo al di sotto del quale il socket,
   pur avendo disponibili dei dati, non viene dato per pronto in lettura.}
 
@@ -2880,22 +2880,22 @@ sez.~\ref{sec:TCP_conn_early_abort}, quando il nostro client non era in grado
 di rendersi conto di errori sulla connessione essendo impegnato nella attesa
 di dati in ingresso dallo standard input.
 
-In questo caso il problema è quello di dover tenere sotto controllo due
+In questo caso il problema è quello di dover tenere sotto controllo due
 diversi file descriptor, lo standard input, da cui viene letto il testo che
 vogliamo inviare al server, e il socket connesso con il server su cui detto
-testo sarà scritto e dal quale poi si vorrà ricevere la risposta. L'uso
+testo sarà scritto e dal quale poi si vorrà ricevere la risposta. L'uso
 dell'I/O multiplexing consente di tenere sotto controllo entrambi, senza
 restare bloccati.
 
-Nel nostro caso quello che ci interessa è non essere bloccati in lettura sullo
+Nel nostro caso quello che ci interessa è non essere bloccati in lettura sullo
 standard input in caso di errori sulla connessione o chiusura della stessa da
 parte del server. Entrambi questi casi possono essere rilevati usando
 \func{select}, per quanto detto in sez.~\ref{sec:TCP_sock_select}, mettendo
 sotto osservazione i file descriptor per la condizione di essere pronti in
 lettura: sia infatti che si ricevano dati, che la connessione sia chiusa
 regolarmente (con la ricezione di un segmento FIN) che si riceva una
-condizione di errore (con un segmento RST) il socket connesso sarà pronto in
-lettura (nell'ultimo caso anche in scrittura, ma questo non è necessario ai
+condizione di errore (con un segmento RST) il socket connesso sarà pronto in
+lettura (nell'ultimo caso anche in scrittura, ma questo non è necessario ai
 nostri scopi).
 
 \begin{figure}[!htb]
@@ -2911,11 +2911,11 @@ nostri scopi).
 \end{figure}
 
 Riprendiamo allora il codice del client, modificandolo per l'uso di
-\func{select}. Quello che dobbiamo modificare è la funzione \func{ClientEcho}
+\func{select}. Quello che dobbiamo modificare è la funzione \func{ClientEcho}
 di fig.~\ref{fig:TCP_ClientEcho_second}, dato che tutto il resto, che riguarda
-le modalità in cui viene stabilita la connessione con il server, resta
+le modalità in cui viene stabilita la connessione con il server, resta
 assolutamente identico. La nostra nuova versione di \func{ClientEcho}, la
-terza della serie, è riportata in fig.~\ref{fig:TCP_ClientEcho_third}, il
+terza della serie, è riportata in fig.~\ref{fig:TCP_ClientEcho_third}, il
 codice completo si trova nel file \file{TCP\_echo\_third.c} dei sorgenti
 allegati alla guida.
 
@@ -2924,40 +2924,40 @@ del \itindex{file~descriptor~set} \textit{file descriptor set} \var{fset} e
 l'impostazione del valore \var{maxfd}, da passare a \func{select} come massimo
 per il numero di file descriptor. Per determinare quest'ultimo si usa la macro
 \code{max} definita nel nostro file \file{macro.h} che raccoglie una
-collezione di macro di preprocessore di varia utilità.
+collezione di macro di preprocessore di varia utilità.
 
 La funzione prosegue poi (\texttt{\small 10--41}) con il ciclo principale, che
 viene ripetuto indefinitamente. Per ogni ciclo si reinizializza
 (\texttt{\small 11--12}) il \itindex{file~descriptor~set} \textit{file
   descriptor set}, impostando i valori per il file descriptor associato al
 socket \var{socket} e per lo standard input (il cui valore si recupera con la
-funzione \func{fileno}). Questo è necessario in quanto la successiva
+funzione \func{fileno}). Questo è necessario in quanto la successiva
 (\texttt{\small 13}) chiamata a \func{select} comporta una modifica dei due
 bit relativi, che quindi devono essere reimpostati all'inizio di ogni ciclo.
 
 Si noti come la chiamata a \func{select} venga eseguita usando come primo
 argomento il valore di \var{maxfd}, precedentemente calcolato, e passando poi
 il solo \itindex{file~descriptor~set} \textit{file descriptor set} per il
-controllo dell'attività in lettura, negli altri argomenti sono passati tutti
-puntatori nulli, non interessando né il controllo delle altre attività, né
+controllo dell'attività in lettura, negli altri argomenti sono passati tutti
+puntatori nulli, non interessando né il controllo delle altre attività, né
 l'impostazione di un valore di timeout.
 
 Al ritorno di \func{select} si provvede a controllare quale dei due file
-descriptor presenta attività in lettura, cominciando (\texttt{\small 14--24})
-con il file descriptor associato allo standard input. In caso di attività
-(quando cioè \macro{FD\_ISSET} ritorna una valore diverso da zero) si esegue
+descriptor presenta attività in lettura, cominciando (\texttt{\small 14--24})
+con il file descriptor associato allo standard input. In caso di attività
+(quando cioè \macro{FD\_ISSET} ritorna una valore diverso da zero) si esegue
 (\texttt{\small 15}) una \func{fgets} per leggere gli eventuali dati presenti;
 se non ve ne sono (e la funzione restituisce pertanto un puntatore nullo) si
-ritorna immediatamente (\texttt{\small 16}) dato che questo significa che si è
+ritorna immediatamente (\texttt{\small 16}) dato che questo significa che si è
 chiuso lo standard input e quindi concluso l'utilizzo del client; altrimenti
 (\texttt{\small 18--22}) si scrivono i dati appena letti sul socket,
 prevedendo una uscita immediata in caso di errore di scrittura.
 
 Controllato lo standard input si passa a controllare (\texttt{\small 25--40})
-il socket connesso, in caso di attività (\texttt{\small 26}) si esegue subito
-una \func{read} di cui si controlla il valore di ritorno; se questo è negativo
-(\texttt{\small 27--30}) si è avuto un errore e pertanto si esce
-immediatamente segnalandolo, se è nullo (\texttt{\small 31--34}) significa che
+il socket connesso, in caso di attività (\texttt{\small 26}) si esegue subito
+una \func{read} di cui si controlla il valore di ritorno; se questo è negativo
+(\texttt{\small 27--30}) si è avuto un errore e pertanto si esce
+immediatamente segnalandolo, se è nullo (\texttt{\small 31--34}) significa che
 il server ha chiuso la connessione, e di nuovo si esce con stampando prima un
 messaggio di avviso, altrimenti (\texttt{\small 35--39}) si effettua la
 terminazione della stringa e la si stampa a sullo standard output (uscendo in
@@ -2965,19 +2965,19 @@ caso di errore), per ripetere il ciclo da capo.
 
 Con questo meccanismo il programma invece di essere bloccato in lettura sullo
 standard input resta bloccato sulla \func{select}, che ritorna soltanto quando
-viene rilevata attività su uno dei due file descriptor posti sotto controllo.
-Questo di norma avviene solo quando si è scritto qualcosa sullo standard
+viene rilevata attività su uno dei due file descriptor posti sotto controllo.
+Questo di norma avviene solo quando si è scritto qualcosa sullo standard
 input, o quando si riceve dal socket la risposta a quanto si era appena
 scritto. Ma adesso il client diventa capace di accorgersi immediatamente della
-terminazione del server; in tal caso infatti il server chiuderà il socket
-connesso, ed alla ricezione del FIN la funzione \func{select} ritornerà (come
+terminazione del server; in tal caso infatti il server chiuderà il socket
+connesso, ed alla ricezione del FIN la funzione \func{select} ritornerà (come
 illustrato in sez.~\ref{sec:TCP_sock_select}) segnalando una condizione di end
-of file, per cui il nostro client potrà uscire immediatamente.
+of file, per cui il nostro client potrà uscire immediatamente.
 
 Riprendiamo la situazione affrontata in sez.~\ref{sec:TCP_server_crash},
 terminando il server durante una connessione, in questo caso quello che
 otterremo, una volta scritta una prima riga ed interrotto il server con un
-\texttt{C-c}, sarà:
+\texttt{C-c}, sarà:
 \begin{verbatim}
 [piccardi@gont sources]$ ./echo 192.168.1.1
 Prima riga
@@ -2985,23 +2985,23 @@ Prima riga
 EOF sul socket
 \end{verbatim}%$
 dove l'ultima riga compare immediatamente dopo aver interrotto il server. Il
-nostro client infatti è in grado di accorgersi immediatamente che il socket
-connesso è stato chiuso ed uscire immediatamente.
+nostro client infatti è in grado di accorgersi immediatamente che il socket
+connesso è stato chiuso ed uscire immediatamente.
 
 Veniamo allora agli altri scenari di terminazione anomala visti in
-sez.~\ref{sec:TCP_conn_crash}. Il primo di questi è l'interruzione fisica della
+sez.~\ref{sec:TCP_conn_crash}. Il primo di questi è l'interruzione fisica della
 connessione; in questo caso avremo un comportamento analogo al precedente, in
 cui si scrive una riga e non si riceve risposta dal server e non succede
 niente fino a quando non si riceve un errore di \errcode{EHOSTUNREACH} o
 \errcode{ETIMEDOUT} a seconda dei casi.
 
-La differenza è che stavolta potremo scrivere più righe dopo l'interruzione,
-in quanto il nostro client dopo aver inviato i dati non si bloccherà più nella
-lettura dal socket, ma nella \func{select}; per questo potrà accettare
-ulteriore dati che scriverà di nuovo sul socket, fintanto che c'è spazio sul
-buffer di uscita (ecceduto il quale si bloccherà in scrittura). Si ricordi
-infatti che il client non ha modo di determinare se la connessione è attiva o
-meno (dato che in molte situazioni reali l'inattività può essere temporanea).
+La differenza è che stavolta potremo scrivere più righe dopo l'interruzione,
+in quanto il nostro client dopo aver inviato i dati non si bloccherà più nella
+lettura dal socket, ma nella \func{select}; per questo potrà accettare
+ulteriore dati che scriverà di nuovo sul socket, fintanto che c'è spazio sul
+buffer di uscita (ecceduto il quale si bloccherà in scrittura). Si ricordi
+infatti che il client non ha modo di determinare se la connessione è attiva o
+meno (dato che in molte situazioni reali l'inattività può essere temporanea).
 Tra l'altro se si ricollega la rete prima della scadenza del timeout, potremo
 anche verificare come tutto quello che si era scritto viene poi effettivamente
 trasmesso non appena la connessione ridiventa attiva, per cui otterremo
@@ -3022,16 +3022,16 @@ il periodo di disconnessione restituito indietro e stampato immediatamente.
 
 Lo stesso comportamento visto in sez.~\ref{sec:TCP_server_crash} si riottiene
 nel caso di un crollo completo della macchina su cui sta il server. In questo
-caso di nuovo il client non è in grado di accorgersi di niente dato che si
+caso di nuovo il client non è in grado di accorgersi di niente dato che si
 suppone che il programma server non venga terminato correttamente, ma si
-blocchi tutto senza la possibilità di avere l'emissione di un segmento FIN che
+blocchi tutto senza la possibilità di avere l'emissione di un segmento FIN che
 segnala la terminazione della connessione. Di nuovo fintanto che la
 connessione non si riattiva (con il riavvio della macchina del server) il
-client non è in grado di fare altro che accettare dell'input e tentare di
-inviarlo. La differenza in questo caso è che non appena la connessione
-ridiventa attiva i dati verranno sì trasmessi, ma essendo state perse tutte le
+client non è in grado di fare altro che accettare dell'input e tentare di
+inviarlo. La differenza in questo caso è che non appena la connessione
+ridiventa attiva i dati verranno sì trasmessi, ma essendo state perse tutte le
 informazioni relative alle precedenti connessioni ai tentativi di scrittura
-del client sarà risposto con un segmento RST che provocherà il ritorno di
+del client sarà risposto con un segmento RST che provocherà il ritorno di
 \func{select} per la ricezione di un errore di \errcode{ECONNRESET}.
 
 
@@ -3039,81 +3039,81 @@ del client sar
 \label{sec:TCP_shutdown}
 
 Come spiegato in sez.~\ref{sec:TCP_conn_term} il procedimento di chiusura di un
-socket TCP prevede che da entrambe le parti venga emesso un segmento FIN. È
+socket TCP prevede che da entrambe le parti venga emesso un segmento FIN. È
 pertanto del tutto normale dal punto di vista del protocollo che uno dei due
 capi chiuda la connessione, quando l'altro capo la lascia
 aperta.\footnote{abbiamo incontrato questa situazione nei vari scenari critici
   di sez.~\ref{sec:TCP_echo_critical}.}
 
-È pertanto possibile avere una situazione in cui un capo della connessione non
-avendo più nulla da scrivere, possa chiudere il socket, segnalando così
-l'avvenuta terminazione della trasmissione (l'altro capo riceverà infatti un
-end-of-file in lettura) mentre dall'altra parte si potrà proseguire la
-trasmissione dei dati scrivendo sul socket che da quel lato è ancora aperto.
-Questa è quella situazione in cui si dice che il socket è \textit{half
+È pertanto possibile avere una situazione in cui un capo della connessione non
+avendo più nulla da scrivere, possa chiudere il socket, segnalando così
+l'avvenuta terminazione della trasmissione (l'altro capo riceverà infatti un
+end-of-file in lettura) mentre dall'altra parte si potrà proseguire la
+trasmissione dei dati scrivendo sul socket che da quel lato è ancora aperto.
+Questa è quella situazione in cui si dice che il socket è \textit{half
   closed}.
 
-Il problema che si pone è che se la chiusura del socket è effettuata con la
+Il problema che si pone è che se la chiusura del socket è effettuata con la
 funzione \func{close}, come spiegato in sez.~\ref{sec:TCP_func_close}, si perde
-ogni possibilità di poter rileggere quanto l'altro capo può continuare a
-scrivere. Per poter permettere allora di segnalare che si è concluso con la
-scrittura, continuando al contempo a leggere quanto può provenire dall'altro
-capo del socket si può allora usare la funzione \funcd{shutdown}, il cui
-prototipo è:
+ogni possibilità di poter rileggere quanto l'altro capo può continuare a
+scrivere. Per poter permettere allora di segnalare che si è concluso con la
+scrittura, continuando al contempo a leggere quanto può provenire dall'altro
+capo del socket si può allora usare la funzione \funcd{shutdown}, il cui
+prototipo è:
 \begin{prototype}{sys/socket.h}
 {int shutdown(int sockfd, int how)}
 
 Chiude un lato della connessione fra due socket.
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
-    errore, nel qual caso \var{errno} assumerà i valori:
+    errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
   \item[\errcode{ENOTSOCK}] il file descriptor non corrisponde a un socket.
-  \item[\errcode{ENOTCONN}] il socket non è connesso.
+  \item[\errcode{ENOTCONN}] il socket non è connesso.
   \end{errlist}
   ed inoltre \errval{EBADF}.}
 \end{prototype}
 
 La funzione prende come primo argomento il socket \param{sockfd} su cui si
 vuole operare e come secondo argomento un valore intero \param{how} che indica
-la modalità di chiusura del socket, quest'ultima può prendere soltanto tre
+la modalità di chiusura del socket, quest'ultima può prendere soltanto tre
 valori: 
 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\macro{SHUT\_RD}] chiude il lato in lettura del socket, non sarà più
+\item[\macro{SHUT\_RD}] chiude il lato in lettura del socket, non sarà più
   possibile leggere dati da esso, tutti gli eventuali dati trasmessi
   dall'altro capo del socket saranno automaticamente scartati dal kernel, che,
-  in caso di socket TCP, provvederà comunque ad inviare i relativi segmenti di
+  in caso di socket TCP, provvederà comunque ad inviare i relativi segmenti di
   ACK.
-\item[\macro{SHUT\_WR}] chiude il lato in scrittura del socket, non sarà più
+\item[\macro{SHUT\_WR}] chiude il lato in scrittura del socket, non sarà più
   possibile scrivere dati su di esso. Nel caso di socket TCP la chiamata causa
   l'emissione di un segmento FIN, secondo la procedura chiamata
   \itindex{half-close} \textit{half-close}. Tutti i dati presenti nel buffer
   di scrittura prima della chiamata saranno inviati, seguiti dalla sequenza di
   chiusura illustrata in sez.~\ref{sec:TCP_conn_term}.
 \item[\macro{SHUT\_RDWR}] chiude sia il lato in lettura che quello in
-  scrittura del socket. È equivalente alla chiamata in sequenza con
+  scrittura del socket. È equivalente alla chiamata in sequenza con
   \macro{SHUT\_RD} e \macro{SHUT\_WR}.
 \end{basedescript}
 
-Ci si può chiedere quale sia l'utilità di avere introdotto \macro{SHUT\_RDWR}
+Ci si può chiedere quale sia l'utilità di avere introdotto \macro{SHUT\_RDWR}
 quando questa sembra rendere \funcd{shutdown} del tutto equivalente ad una
-\func{close}. In realtà non è così, esiste infatti un'altra differenza con
-\func{close}, più sottile. Finora infatti non ci siamo presi la briga di
+\func{close}. In realtà non è così, esiste infatti un'altra differenza con
+\func{close}, più sottile. Finora infatti non ci siamo presi la briga di
 sottolineare in maniera esplicita che, come per i file e le fifo, anche per i
-socket possono esserci più riferimenti contemporanei ad uno stesso socket. Per
+socket possono esserci più riferimenti contemporanei ad uno stesso socket. Per
 cui si avrebbe potuto avere l'impressione che sia una corrispondenza univoca
-fra un socket ed il file descriptor con cui vi si accede. Questo non è
-assolutamente vero, (e lo abbiamo già visto nel codice del server di
-fig.~\ref{fig:TCP_echo_server_first_code}), ed è invece assolutamente normale
-che, come per gli altri oggetti, ci possano essere più file descriptor che
+fra un socket ed il file descriptor con cui vi si accede. Questo non è
+assolutamente vero, (e lo abbiamo già visto nel codice del server di
+fig.~\ref{fig:TCP_echo_server_first_code}), ed è invece assolutamente normale
+che, come per gli altri oggetti, ci possano essere più file descriptor che
 fanno riferimento allo stesso socket.
 
-Allora se avviene uno di questi casi quello che succederà è che la chiamata a
-\func{close} darà effettivamente avvio alla sequenza di chiusura di un socket
-soltanto quando il numero di riferimenti a quest'ultimo diventerà nullo.
+Allora se avviene uno di questi casi quello che succederà è che la chiamata a
+\func{close} darà effettivamente avvio alla sequenza di chiusura di un socket
+soltanto quando il numero di riferimenti a quest'ultimo diventerà nullo.
 Fintanto che ci sono file descriptor che fanno riferimento ad un socket l'uso
-di \func{close} si limiterà a deallocare nel processo corrente il file
-descriptor utilizzato, ma il socket resterà pienamente accessibile attraverso
+di \func{close} si limiterà a deallocare nel processo corrente il file
+descriptor utilizzato, ma il socket resterà pienamente accessibile attraverso
 tutti gli altri riferimenti. Se torniamo all'esempio originale del server di
 fig.~\ref{fig:TCP_echo_server_first_code} abbiamo infatti che ci sono due
 \func{close}, una sul socket connesso nel padre, ed una sul socket in ascolto
@@ -3124,19 +3124,19 @@ ed uno a quello in ascolto nel padre.
 Questo non avviene affatto se si usa \func{shutdown} con argomento
 \macro{SHUT\_RDWR} al posto di \func{close}; in questo caso infatti la
 chiusura del socket viene effettuata immediatamente, indipendentemente dalla
-presenza di altri riferimenti attivi, e pertanto sarà efficace anche per tutti
+presenza di altri riferimenti attivi, e pertanto sarà efficace anche per tutti
 gli altri file descriptor con cui, nello stesso o in altri processi, si fa
 riferimento allo stesso socket.
 
-Il caso più comune di uso di \func{shutdown} è comunque quello della chiusura
-del lato in scrittura, per segnalare all'altro capo della connessione che si è
+Il caso più comune di uso di \func{shutdown} è comunque quello della chiusura
+del lato in scrittura, per segnalare all'altro capo della connessione che si è
 concluso l'invio dei dati, restando comunque in grado di ricevere quanto
-questi potrà ancora inviarci. Questo è ad esempio l'uso che ci serve per
+questi potrà ancora inviarci. Questo è ad esempio l'uso che ci serve per
 rendere finalmente completo il nostro esempio sul servizio \textit{echo}. Il
 nostro client infatti presenta ancora un problema, che nell'uso che finora ne
-abbiamo fatto non è emerso, ma che ci aspetta dietro l'angolo non appena
+abbiamo fatto non è emerso, ma che ci aspetta dietro l'angolo non appena
 usciamo dall'uso interattivo e proviamo ad eseguirlo redirigendo standard
-input e standard output. Così se eseguiamo:
+input e standard output. Così se eseguiamo:
 \begin{verbatim}
 [piccardi@gont sources]$ ./echo 192.168.1.1 < ../fileadv.tex  > copia
 \end{verbatim}%$
@@ -3144,37 +3144,37 @@ vedremo che il file \texttt{copia} risulta mancare della parte finale.
 
 Per capire cosa avviene in questo caso occorre tenere presente come avviene la
 comunicazione via rete; quando redirigiamo lo standard input il nostro client
-inizierà a leggere il contenuto del file \texttt{../fileadv.tex} a blocchi di
+inizierà a leggere il contenuto del file \texttt{../fileadv.tex} a blocchi di
 dimensione massima pari a \texttt{MAXLINE} per poi scriverlo, alla massima
-velocità consentitagli dalla rete, sul socket. Dato che la connessione è con
-una macchina remota occorre un certo tempo perché i pacchetti vi arrivino,
+velocità consentitagli dalla rete, sul socket. Dato che la connessione è con
+una macchina remota occorre un certo tempo perché i pacchetti vi arrivino,
 vengano processati, e poi tornino indietro. Considerando trascurabile il tempo
-di processo, questo tempo è quello impiegato nella trasmissione via rete, che
+di processo, questo tempo è quello impiegato nella trasmissione via rete, che
 viene detto RTT (dalla denominazione inglese \itindex{Round~Trip~Time}
-\textit{Round Trip Time}) ed è quello che viene stimato con l'uso del comando
+\textit{Round Trip Time}) ed è quello che viene stimato con l'uso del comando
 \cmd{ping}.
 
 A questo punto, se torniamo al codice mostrato in
 fig.~\ref{fig:TCP_ClientEcho_third}, possiamo vedere che mentre i pacchetti
 sono in transito sulla rete il client continua a leggere e a scrivere fintanto
-che il file in ingresso finisce. Però non appena viene ricevuto un end-of-file
+che il file in ingresso finisce. Però non appena viene ricevuto un end-of-file
 in ingresso il nostro client termina. Nel caso interattivo, in cui si
 inviavano brevi stringhe una alla volta, c'era sempre il tempo di eseguire la
 lettura completa di quanto il server rimandava indietro. In questo caso
 invece, quando il client termina, essendo la comunicazione saturata e a piena
-velocità, ci saranno ancora pacchetti in transito sulla rete che devono
+velocità, ci saranno ancora pacchetti in transito sulla rete che devono
 arrivare al server e poi tornare indietro, ma siccome il client esce
 immediatamente dopo la fine del file in ingresso, questi non faranno a tempo a
 completare il percorso e verranno persi.
 
 Per evitare questo tipo di problema, invece di uscire una volta completata la
 lettura del file in ingresso, occorre usare \func{shutdown} per effettuare la
-chiusura del lato in scrittura del socket. In questo modo il client segnalerà
-al server la chiusura del flusso dei dati, ma potrà continuare a leggere
+chiusura del lato in scrittura del socket. In questo modo il client segnalerà
+al server la chiusura del flusso dei dati, ma potrà continuare a leggere
 quanto il server gli sta ancora inviando indietro, fino a quando anch'esso,
 riconosciuta la chiusura del socket in scrittura da parte del client,
-effettuerà la chiusura dalla sua parte. Solo alla ricezione della chiusura del
-socket da parte del server il client potrà essere sicuro della ricezione di
+effettuerà la chiusura dalla sua parte. Solo alla ricezione della chiusura del
+socket da parte del server il client potrà essere sicuro della ricezione di
 tutti i dati e della terminazione effettiva della connessione.
 
 \begin{figure}[!htb]
@@ -3189,23 +3189,23 @@ tutti i dati e della terminazione effettiva della connessione.
   \label{fig:TCP_ClientEcho}
 \end{figure}
 
-Si è allora riportato in fig.~\ref{fig:TCP_ClientEcho} la versione finale
+Si è allora riportato in fig.~\ref{fig:TCP_ClientEcho} la versione finale
 della nostra funzione \func{ClientEcho}, in grado di gestire correttamente
 l'intero flusso di dati fra client e server. Il codice completo del client,
 comprendente la gestione delle opzioni a riga di comando e le istruzioni per
 la creazione della connessione, si trova nel file
 \texttt{TCP\_echo\_fourth.c}, distribuito coi sorgenti allegati alla guida.
 
-La nuova versione è molto simile alla precedente di
-fig.~\ref{fig:TCP_ClientEcho_third}; la prima differenza è l'introduzione
+La nuova versione è molto simile alla precedente di
+fig.~\ref{fig:TCP_ClientEcho_third}; la prima differenza è l'introduzione
 (\texttt{\small 7}) della variabile \var{eof}, inizializzata ad un valore
 nullo, che serve a mantenere traccia dell'avvenuta conclusione della lettura
 del file in ingresso.
 
-La seconda modifica (\texttt{\small 12--15}) è stata quella di rendere
+La seconda modifica (\texttt{\small 12--15}) è stata quella di rendere
 subordinato ad un valore nullo di \var{eof} l'impostazione del file descriptor
 set per l'osservazione dello standard input. Se infatti il valore di \var{eof}
-è non nullo significa che si è già raggiunta la fine del file in ingresso ed è
+è non nullo significa che si è già raggiunta la fine del file in ingresso ed è
 pertanto inutile continuare a tenere sotto controllo lo standard input nella
 successiva (\texttt{\small 16}) chiamata a \func{select}.
 
@@ -3219,7 +3219,7 @@ in scrittura del socket con \func{shutdown}. Infine (\texttt{\small 21}) si
 usa la macro \macro{FD\_CLR} per togliere lo standard input dal
 \itindex{file~descriptor~set} \textit{file descriptor set}.
 
-In questo modo anche se la lettura del file in ingresso è conclusa, la
+In questo modo anche se la lettura del file in ingresso è conclusa, la
 funzione non esce dal ciclo principale (\texttt{\small 11--50}), ma continua
 ad eseguirlo ripetendo la chiamata a \func{select} per tenere sotto controllo
 soltanto il socket connesso, dal quale possono arrivare altri dati, che
@@ -3229,11 +3229,11 @@ saranno letti (\texttt{\small 31}), ed opportunamente trascritti
 Il ritorno della funzione, e la conseguente terminazione normale del client,
 viene invece adesso gestito all'interno (\texttt{\small 30--49}) della lettura
 dei dati dal socket; se infatti dalla lettura del socket si riceve una
-condizione di end-of-file, la si tratterà (\texttt{\small 36--43}) in maniera
-diversa a seconda del valore di \var{eof}. Se infatti questa è diversa da zero
+condizione di end-of-file, la si tratterà (\texttt{\small 36--43}) in maniera
+diversa a seconda del valore di \var{eof}. Se infatti questa è diversa da zero
 (\texttt{\small 37--39}), essendo stata completata la lettura del file in
-ingresso, vorrà dire che anche il server ha concluso la trasmissione dei dati
-restanti, e si potrà uscire senza errori, altrimenti si stamperà
+ingresso, vorrà dire che anche il server ha concluso la trasmissione dei dati
+restanti, e si potrà uscire senza errori, altrimenti si stamperà
 (\texttt{\small 40--42}) un messaggio di errore per la chiusura precoce della
 connessione.
 
@@ -3248,11 +3248,11 @@ modo da evitare di dover creare un nuovo processo tutte le volte che si ha una
 connessione.\footnote{ne faremo comunque una implementazione diversa rispetto
   a quella presentata da Stevens in \cite{UNP1}.}
 
-La struttura del nuovo server è illustrata in
+La struttura del nuovo server è illustrata in
 fig.~\ref{fig:TCP_echo_multiplex}, in questo caso avremo un solo processo che
 ad ogni nuova connessione da parte di un client sul socket in ascolto si
-limiterà a registrare l'entrata in uso di un nuovo file descriptor ed
-utilizzerà \func{select} per rilevare la presenza di dati in arrivo su tutti i
+limiterà a registrare l'entrata in uso di un nuovo file descriptor ed
+utilizzerà \func{select} per rilevare la presenza di dati in arrivo su tutti i
 file descriptor attivi, operando direttamente su ciascuno di essi.
 
 \begin{figure}[htb]
@@ -3262,13 +3262,13 @@ file descriptor attivi, operando direttamente su ciascuno di essi.
   \label{fig:TCP_echo_multiplex}
 \end{figure}
 
-La sezione principale del codice del nuovo server è illustrata in
-fig.~\ref{fig:TCP_SelectEchod}. Si è tralasciata al solito la gestione delle
-opzioni, che è identica alla versione precedente. Resta invariata anche tutta
+La sezione principale del codice del nuovo server è illustrata in
+fig.~\ref{fig:TCP_SelectEchod}. Si è tralasciata al solito la gestione delle
+opzioni, che è identica alla versione precedente. Resta invariata anche tutta
 la parte relativa alla gestione dei segnali, degli errori, e della cessione
-dei privilegi, così come è identica la gestione della creazione del socket (si
-può fare riferimento al codice già illustrato in
-sez.~\ref{sec:TCPsimp_server_main}); al solito il codice completo del server è
+dei privilegi, così come è identica la gestione della creazione del socket (si
+può fare riferimento al codice già illustrato in
+sez.~\ref{sec:TCPsimp_server_main}); al solito il codice completo del server è
 disponibile coi sorgenti allegati nel file \texttt{select\_echod.c}.
 
 \begin{figure}[!htbp]
@@ -3283,40 +3283,40 @@ disponibile coi sorgenti allegati nel file \texttt{select\_echod.c}.
 \end{figure}
 
 In questo caso, una volta aperto e messo in ascolto il socket, tutto quello
-che ci servirà sarà chiamare \func{select} per rilevare la presenza di nuove
+che ci servirà sarà chiamare \func{select} per rilevare la presenza di nuove
 connessioni o di dati in arrivo, e processarli immediatamente. Per
 implementare lo schema mostrato in fig.~\ref{fig:TCP_echo_multiplex}, il
 programma usa una tabella dei socket connessi mantenuta nel vettore
 \var{fd\_open} dimensionato al valore di \const{FD\_SETSIZE}, ed una variabile
-\var{max\_fd} per registrare il valore più alto dei file descriptor aperti.
+\var{max\_fd} per registrare il valore più alto dei file descriptor aperti.
 
 Prima di entrare nel ciclo principale (\texttt{\small 6--56}) la nostra
 tabella viene inizializzata (\texttt{\small 2}) a zero (valore che
-utilizzeremo come indicazione del fatto che il relativo file descriptor non è
+utilizzeremo come indicazione del fatto che il relativo file descriptor non è
 aperto), mentre il valore massimo (\texttt{\small 3}) per i file descriptor
 aperti viene impostato a quello del socket in ascolto,\footnote{in quanto esso
-  è l'unico file aperto, oltre i tre standard, e pertanto avrà il valore più
-  alto.} che verrà anche (\texttt{\small 4}) inserito nella tabella.
+  è l'unico file aperto, oltre i tre standard, e pertanto avrà il valore più
+  alto.} che verrà anche (\texttt{\small 4}) inserito nella tabella.
 
 La prima sezione (\texttt{\small 7--10}) del ciclo principale esegue la
 costruzione del \itindex{file~descriptor~set} \textit{file descriptor set}
-\var{fset} in base ai socket connessi in un certo momento; all'inizio ci sarà
+\var{fset} in base ai socket connessi in un certo momento; all'inizio ci sarà
 soltanto il socket in ascolto, ma nel prosieguo delle operazioni, verranno
 utilizzati anche tutti i socket connessi registrati nella tabella
 \var{fd\_open}.  Dato che la chiamata di \func{select} modifica il valore del
-\itindex{file~descriptor~set} \textit{file descriptor set}, è necessario
+\itindex{file~descriptor~set} \textit{file descriptor set}, è necessario
 ripetere (\texttt{\small 7}) ogni volta il suo azzeramento, per poi procedere
 con il ciclo (\texttt{\small 8--10}) in cui si impostano i socket trovati
 attivi.
 
 Per far questo si usa la caratteristica dei file descriptor, descritta in
 sez.~\ref{sec:file_open}, per cui il kernel associa sempre ad ogni nuovo file
-il file descriptor con il valore più basso disponibile. Questo fa sì che si
+il file descriptor con il valore più basso disponibile. Questo fa sì che si
 possa eseguire il ciclo (\texttt{\small 8}) a partire da un valore minimo, che
-sarà sempre quello del socket in ascolto, mantenuto in \var{list\_fd}, fino al
+sarà sempre quello del socket in ascolto, mantenuto in \var{list\_fd}, fino al
 valore massimo di \var{max\_fd} che dovremo aver cura di tenere aggiornato.
-Dopo di che basterà controllare (\texttt{\small 9}) nella nostra tabella se il
-file descriptor è in uso o meno,\footnote{si tenga presente che benché il
+Dopo di che basterà controllare (\texttt{\small 9}) nella nostra tabella se il
+file descriptor è in uso o meno,\footnote{si tenga presente che benché il
   kernel assegni sempre il primo valore libero, dato che nelle operazioni i
   socket saranno aperti e chiusi in corrispondenza della creazione e
   conclusione delle connessioni, si potranno sempre avere dei \textsl{buchi}
@@ -3326,7 +3326,7 @@ Una volta inizializzato con i socket aperti il nostro \textit{file descriptor
   set} potremo chiamare \func{select} per fargli osservare lo stato degli
 stessi (in lettura, presumendo che la scrittura sia sempre consentita). Come
 per il precedente esempio di sez.~\ref{sec:TCP_child_hand}, essendo questa
-l'unica funzione che può bloccarsi, ed essere interrotta da un segnale, la
+l'unica funzione che può bloccarsi, ed essere interrotta da un segnale, la
 eseguiremo (\texttt{\small 11--12}) all'interno di un ciclo di \code{while}
 che la ripete indefinitamente qualora esca con un errore di \errcode{EINTR}.
 Nel caso invece di un errore normale si provvede (\texttt{\small 13--16}) ad
@@ -3334,9 +3334,9 @@ uscire stampando un messaggio di errore.
 
 Se invece la funzione ritorna normalmente avremo in \var{n} il numero di
 socket da controllare. Nello specifico si danno due possibili casi diversi per
-cui \func{select} può essere ritornata: o si è ricevuta una nuova connessione
-ed è pronto il socket in ascolto, sul quale si può eseguire \func{accept} o
-c'è attività su uno dei socket connessi, sui quali si può eseguire
+cui \func{select} può essere ritornata: o si è ricevuta una nuova connessione
+ed è pronto il socket in ascolto, sul quale si può eseguire \func{accept} o
+c'è attività su uno dei socket connessi, sui quali si può eseguire
 \func{read}.
 
 Il primo caso viene trattato immediatamente (\texttt{\small 17--26}): si
@@ -3345,48 +3345,48 @@ nel qual caso anzitutto (\texttt{\small 18}) se ne decrementa il numero in
 \var{n}; poi, inizializzata (\texttt{\small 19}) la lunghezza della struttura
 degli indirizzi, si esegue \func{accept} per ottenere il nuovo socket connesso
 controllando che non ci siano errori (\texttt{\small 20--23}). In questo caso
-non c'è più la necessità di controllare per interruzioni dovute a segnali, in
-quanto siamo sicuri che \func{accept} non si bloccherà. Per completare la
+non c'è più la necessità di controllare per interruzioni dovute a segnali, in
+quanto siamo sicuri che \func{accept} non si bloccherà. Per completare la
 trattazione occorre a questo punto aggiungere (\texttt{\small 24}) il nuovo
-file descriptor alla tabella di quelli connessi, ed inoltre, se è il caso,
+file descriptor alla tabella di quelli connessi, ed inoltre, se è il caso,
 aggiornare (\texttt{\small 25}) il valore massimo in \var{max\_fd}.
 
 Una volta controllato l'arrivo di nuove connessioni si passa a verificare se
 vi sono dati sui socket connessi, per questo si ripete un ciclo
 (\texttt{\small 29--55}) fintanto che il numero di socket attivi \var{n} resta
-diverso da zero; in questo modo se l'unico socket con attività era quello
-connesso, avendo opportunamente decrementato il contatore, il ciclo verrà
-saltato, e si ritornerà immediatamente (ripetuta l'inizializzazione del
+diverso da zero; in questo modo se l'unico socket con attività era quello
+connesso, avendo opportunamente decrementato il contatore, il ciclo verrà
+saltato, e si ritornerà immediatamente (ripetuta l'inizializzazione del
 \itindex{file~descriptor~set} \textit{file descriptor set} con i nuovi valori
-nella tabella) alla chiamata di \func{accept}. Se il socket attivo non è
+nella tabella) alla chiamata di \func{accept}. Se il socket attivo non è
 quello in ascolto, o ce ne sono comunque anche altri, il valore di \var{n} non
-sarà nullo ed il controllo sarà eseguito. Prima di entrare nel ciclo comunque
+sarà nullo ed il controllo sarà eseguito. Prima di entrare nel ciclo comunque
 si inizializza (\texttt{\small 28}) il valore della variabile \var{i} che
 useremo come indice nella tabella \var{fd\_open} al valore minimo,
 corrispondente al file descriptor del socket in ascolto.
 
-Il primo passo (\texttt{\small 30}) nella verifica è incrementare il valore
+Il primo passo (\texttt{\small 30}) nella verifica è incrementare il valore
 dell'indice \var{i} per posizionarsi sul primo valore possibile per un file
 descriptor associato ad un eventuale socket connesso, dopo di che si controlla
-(\texttt{\small 31}) se questo è nella tabella dei socket connessi, chiedendo
+(\texttt{\small 31}) se questo è nella tabella dei socket connessi, chiedendo
 la ripetizione del ciclo in caso contrario. Altrimenti si passa a verificare
 (\texttt{\small 32}) se il file descriptor corrisponde ad uno di quelli
 attivi, e nel caso si esegue (\texttt{\small 33}) una lettura, uscendo con un
 messaggio in caso di errore (\texttt{\small 34--38}).
 
-Se (\texttt{\small 39}) il numero di byte letti \var{nread} è nullo si è in
+Se (\texttt{\small 39}) il numero di byte letti \var{nread} è nullo si è in
 presenza del caso di un \textit{end-of-file}, indice che una connessione che
-si è chiusa, che deve essere trattato (\texttt{\small 39--48}) opportunamente.
-Il primo passo è chiudere (\texttt{\small 40}) anche il proprio capo del
+si è chiusa, che deve essere trattato (\texttt{\small 39--48}) opportunamente.
+Il primo passo è chiudere (\texttt{\small 40}) anche il proprio capo del
 socket e rimuovere (\texttt{\small 41}) il file descriptor dalla tabella di
 quelli aperti, inoltre occorre verificare (\texttt{\small 42}) se il file
-descriptor chiuso è quello con il valore più alto, nel qual caso occorre
+descriptor chiuso è quello con il valore più alto, nel qual caso occorre
 trovare (\texttt{\small 42--46}) il nuovo massimo, altrimenti (\texttt{\small
-  47}) si può ripetere il ciclo da capo per esaminare (se ne restano)
+  47}) si può ripetere il ciclo da capo per esaminare (se ne restano)
 ulteriori file descriptor attivi.
 
-Se però è stato chiuso il file descriptor più alto, dato che la scansione dei
-file descriptor attivi viene fatta a partire dal valore più basso, questo
+Se però è stato chiuso il file descriptor più alto, dato che la scansione dei
+file descriptor attivi viene fatta a partire dal valore più basso, questo
 significa che siamo anche arrivati alla fine della scansione, per questo
 possiamo utilizzare direttamente il valore dell'indice \var{i} con un ciclo
 all'indietro (\texttt{\small 43}) che trova il primo valore per cui la tabella
@@ -3395,26 +3395,26 @@ nuovo massimo, per poi tornare (\texttt{\small 44}) al ciclo principale con un
 \code{break}, e rieseguire \func{select}.
 
 Se infine si sono effettivamente letti dei dati dal socket (ultimo caso
-rimasto) si potrà invocare immediatamente (\texttt{\small 49})
+rimasto) si potrà invocare immediatamente (\texttt{\small 49})
 \func{FullWrite} per riscriverli indietro sul socket stesso, avendo cura di
 uscire con un messaggio in caso di errore (\texttt{\small 50--53}). Si noti
 che nel ciclo si esegue una sola lettura, contrariamente a quanto fatto con la
 precedente versione (si riveda il codice di fig.~\ref{fig:TCP_ServEcho_second})
 in cui si continuava a leggere fintanto che non si riceveva un
-\textit{end-of-file}, questo perché usando l'\textit{I/O multiplexing} non si
+\textit{end-of-file}, questo perché usando l'\textit{I/O multiplexing} non si
 vuole essere bloccati in lettura.  L'uso di \func{select} ci permette di
-trattare automaticamente anche il caso in cui la \func{read} non è stata in
+trattare automaticamente anche il caso in cui la \func{read} non è stata in
 grado di leggere tutti i dati presenti sul socket, dato che alla iterazione
-successiva \func{select} ritornerà immediatamente segnalando l'ulteriore
-disponibilità.
+successiva \func{select} ritornerà immediatamente segnalando l'ulteriore
+disponibilità.
 
-Il nostro server comunque soffre di una vulnerabilità per un attacco di tipo
-\itindex{Denial~of~Service~(DoS)} \textit{Denial of Service}. Il problema è
+Il nostro server comunque soffre di una vulnerabilità per un attacco di tipo
+\itindex{Denial~of~Service~(DoS)} \textit{Denial of Service}. Il problema è
 che in caso di blocco di una qualunque delle funzioni di I/O, non avendo usato
-processi separati, tutto il server si ferma e non risponde più a nessuna
+processi separati, tutto il server si ferma e non risponde più a nessuna
 richiesta. Abbiamo scongiurato questa evenienza per l'I/O in ingresso con
 l'uso di \func{select}, ma non vale altrettanto per l'I/O in uscita. Il
-problema pertanto può sorgere qualora una delle chiamate a \func{write}
+problema pertanto può sorgere qualora una delle chiamate a \func{write}
 effettuate da \func{FullWrite} si blocchi. Con il funzionamento normale questo
 non accade in quanto il server si limita a scrivere quanto riceve in ingresso,
 ma qualora venga utilizzato un client malevolo che esegua solo scritture e non
@@ -3425,7 +3425,7 @@ una \func{write}.
 Le possibili soluzioni in questo caso sono quelle di ritornare ad eseguire il
 ciclo di risposta alle richieste all'interno di processi separati, utilizzare
 un timeout per le operazioni di scrittura, o eseguire queste ultime in
-modalità non bloccante, concludendo le operazioni qualora non vadano a buon
+modalità non bloccante, concludendo le operazioni qualora non vadano a buon
 fine.
 
 
@@ -3434,9 +3434,9 @@ fine.
 \label{sec:TCP_serv_poll}
 
 Finora abbiamo trattato le problematiche risolubili con l'I/O multiplexing
-impiegando la funzione \func{select}; questo è quello che avviene nella
-maggior parte dei casi, in quanto essa è nata sotto BSD proprio per affrontare
-queste problematiche con i socket.  Abbiamo però visto in
+impiegando la funzione \func{select}; questo è quello che avviene nella
+maggior parte dei casi, in quanto essa è nata sotto BSD proprio per affrontare
+queste problematiche con i socket.  Abbiamo però visto in
 sez.~\ref{sec:file_multiplexing} come la funzione \func{poll} possa costituire
 una alternativa a \func{select}, con alcuni vantaggi.\footnote{non soffrendo
   delle limitazioni dovute all'uso dei \itindex{file~descriptor~set}
@@ -3457,18 +3457,18 @@ pertanto:
   sez.~\ref{sec:TCP_urgent_data}) su un socket TCP vengono considerati
   traffico prioritario e vengono rilevati da una condizione \const{POLLIN},
   \const{POLLPRI} o \const{POLLRDBAND}.
-\item la chiusura di una connessione (cioè la ricezione di un segmento FIN)
+\item la chiusura di una connessione (cioè la ricezione di un segmento FIN)
   viene considerato traffico normale, pertanto viene rilevato da una
   condizione \const{POLLIN} o \const{POLLRDNORM}, ma una conseguente chiamata
-  a \func{read} restituirà 0.
-\item la disponibilità di spazio sul socket per la scrittura di dati viene
+  a \func{read} restituirà 0.
+\item la disponibilità di spazio sul socket per la scrittura di dati viene
   segnalata con una condizione \const{POLLOUT}.
 \item quando uno dei due capi del socket chiude un suo lato della connessione
   con \func{shutdown} si riceve una condizione di \const{POLLHUP}.
 \item la presenza di un errore sul socket (sia dovuta ad un segmento RST che a
   timeout) viene considerata traffico normale, ma viene segnalata anche dalla
   condizione \const{POLLERR}.
-\item la presenza di una nuova connessione su un socket in ascolto può essere
+\item la presenza di una nuova connessione su un socket in ascolto può essere
   considerata sia traffico normale che prioritario, nel caso di Linux
   l'implementazione la classifica come normale.
 \end{itemize}
@@ -3491,8 +3491,8 @@ ma la struttura del programma resta sostanzialmente la stessa.
   \label{fig:TCP_PollEchod}
 \end{figure}
 
-In fig.~\ref{fig:TCP_PollEchod} è riportata la sezione principale della nuova
-versione del server, la versione completa del codice è riportata nel file
+In fig.~\ref{fig:TCP_PollEchod} è riportata la sezione principale della nuova
+versione del server, la versione completa del codice è riportata nel file
 \texttt{poll\_echod.c} dei sorgenti allegati alla guida. Al solito nella
 figura si sono tralasciate la gestione delle opzioni, la creazione del socket
 in ascolto, la cessione dei privilegi e le operazioni necessarie a far
@@ -3500,28 +3500,28 @@ funzionare il programma come demone, privilegiando la sezione principale del
 programma.
 
 Come per il precedente server basato su \func{select} il primo passo
-(\texttt{\small 2--8}) è quello di inizializzare le variabili necessarie. Dato
+(\texttt{\small 2--8}) è quello di inizializzare le variabili necessarie. Dato
 che in questo caso dovremo usare un vettore di strutture occorre anzitutto
 (\texttt{\small 2}) allocare la memoria necessaria utilizzando il numero
 massimo \var{n} di socket osservabili, che viene impostato attraverso
 l'opzione \texttt{-n} ed ha un valore di default di 256. 
 
 Dopo di che si preimposta (\texttt{\small 3}) il valore \var{max\_fd} del file
-descriptor aperto con valore più alto a quello del socket in ascolto (al
+descriptor aperto con valore più alto a quello del socket in ascolto (al
 momento l'unico), e si provvede (\texttt{\small 4--7}) ad inizializzare le
 strutture, disabilitando (\texttt{\small 5}) l'osservazione con un valore
 negativo del campo \var{fd} ma predisponendo (\texttt{\small 6}) il campo
 \var{events} per l'osservazione dei dati normali con \const{POLLRDNORM}.
 Infine (\texttt{\small 8}) si attiva l'osservazione del socket in ascolto
 inizializzando la corrispondente struttura. Questo metodo comporta, in
-modalità interattiva, lo spreco di tre strutture (quelle relative a standard
-input, output ed error) che non vengono mai utilizzate in quanto la prima è
+modalità interattiva, lo spreco di tre strutture (quelle relative a standard
+input, output ed error) che non vengono mai utilizzate in quanto la prima è
 sempre quella relativa al socket in ascolto.
 
 Una volta completata l'inizializzazione tutto il lavoro viene svolto
 all'interno del ciclo principale \texttt{\small 10--55}) che ha una struttura
 sostanzialmente identica a quello usato per il precedente esempio basato su
-\func{select}. La prima istruzione (\texttt{\small 11--12}) è quella di
+\func{select}. La prima istruzione (\texttt{\small 11--12}) è quella di
 eseguire \func{poll} all'interno di un ciclo che la ripete qualora venisse
 interrotta da un segnale, da cui si esce soltanto quando la funzione ritorna,
 restituendo nella variabile \var{n} il numero di file descriptor trovati
@@ -3529,10 +3529,10 @@ attivi.  Qualora invece si sia ottenuto un errore si procede (\texttt{\small
   13--16}) alla terminazione immediata del processo provvedendo a stampare una
 descrizione dello stesso.
 
-Una volta ottenuta dell'attività su un file descriptor si hanno di nuovo due
-possibilità. La prima possibilità è che ci sia attività sul socket in ascolto,
+Una volta ottenuta dell'attività su un file descriptor si hanno di nuovo due
+possibilità. La prima possibilità è che ci sia attività sul socket in ascolto,
 indice di una nuova connessione, nel qual caso si controlla (\texttt{\small
-  17}) se il campo \var{revents} della relativa struttura è attivo; se è così
+  17}) se il campo \var{revents} della relativa struttura è attivo; se è così
 si provvede (\texttt{\small 18}) a decrementare la variabile \var{n} (che
 assume il significato di numero di file descriptor attivi rimasti da
 controllare) per poi (\texttt{\small 19--23}) effettuare la chiamata ad
@@ -3542,42 +3542,42 @@ struttura relativa al nuovo file descriptor da essa ottenuto, modificando
 (\texttt{\small 24}) infine quando necessario il valore massimo dei file
 descriptor aperti mantenuto in \var{max\_fd}.
 
-La seconda possibilità è che vi sia dell'attività su uno dei socket aperti in
+La seconda possibilità è che vi sia dell'attività su uno dei socket aperti in
 precedenza, nel qual caso si inizializza (\texttt{\small 27}) l'indice \var{i}
 del vettore delle strutture \struct{pollfd} al valore del socket in ascolto,
 dato che gli ulteriori socket aperti avranno comunque un valore superiore.  Il
 ciclo (\texttt{\small 28--54}) prosegue fintanto che il numero di file
-descriptor attivi, mantenuto nella variabile \var{n}, è diverso da zero. Se
+descriptor attivi, mantenuto nella variabile \var{n}, è diverso da zero. Se
 pertanto ci sono ancora socket attivi da individuare si comincia con
 l'incrementare (\texttt{\small 30}) l'indice e controllare (\texttt{\small
   31}) se corrisponde ad un file descriptor in uso analizzando il valore del
 campo \var{fd} della relativa struttura e chiudendo immediatamente il ciclo
-qualora non lo sia. Se invece il file descriptor è in uso si verifica
-(\texttt{\small 31}) se c'è stata attività controllando il campo
+qualora non lo sia. Se invece il file descriptor è in uso si verifica
+(\texttt{\small 31}) se c'è stata attività controllando il campo
 \var{revents}. 
 
-Di nuovo se non si verifica la presenza di attività il ciclo si chiude subito,
-altrimenti si provvederà (\texttt{\small 32}) a decrementare il numero \var{n}
+Di nuovo se non si verifica la presenza di attività il ciclo si chiude subito,
+altrimenti si provvederà (\texttt{\small 32}) a decrementare il numero \var{n}
 di file descriptor attivi da controllare e ad eseguire (\texttt{\small 33}) la
 lettura, ed in caso di errore (\texttt{\small 34--37}) al solito lo si
-notificherà uscendo immediatamente. Qualora invece si ottenga una condizione
-di end-of-file (\texttt{\small 38--47}) si provvederà a chiudere
+notificherà uscendo immediatamente. Qualora invece si ottenga una condizione
+di end-of-file (\texttt{\small 38--47}) si provvederà a chiudere
 (\texttt{\small 39}) anche il nostro capo del socket e a marcarlo
 (\texttt{\small 40}) nella struttura ad esso associata come inutilizzato.
-Infine dovrà essere ricalcolato (\texttt{\small 41--45}) un eventuale nuovo
-valore di \var{max\_fd}. L'ultimo passo è (\texttt{\small 46}) chiudere il
-ciclo in quanto in questo caso non c'è più niente da riscrivere all'indietro
+Infine dovrà essere ricalcolato (\texttt{\small 41--45}) un eventuale nuovo
+valore di \var{max\_fd}. L'ultimo passo è (\texttt{\small 46}) chiudere il
+ciclo in quanto in questo caso non c'è più niente da riscrivere all'indietro
 sul socket.
 
 Se invece si sono letti dei dati si provvede (\texttt{\small 48}) ad
 effettuarne la riscrittura all'indietro, con il solito controllo ed eventuale
 uscita e notifica in caso si errore (\texttt{\small 49--52}).
 
-Come si può notare la logica del programma è identica a quella vista in
+Come si può notare la logica del programma è identica a quella vista in
 fig.~\ref{fig:TCP_SelectEchod} per l'analogo server basato su \func{select};
-la sola differenza significativa è che in questo caso non c'è bisogno di
+la sola differenza significativa è che in questo caso non c'è bisogno di
 rigenerare i \itindex{file~descriptor~set} \textit{file descriptor set} in
-quanto l'uscita è indipendente dai dati in ingresso. Si applicano comunque
+quanto l'uscita è indipendente dai dati in ingresso. Si applicano comunque
 anche a questo server le considerazioni finali di
 sez.~\ref{sec:TCP_serv_select}.
 
diff --git a/thread.tex b/thread.tex
index d2b77ba..8cc4fac 100644
--- a/thread.tex
+++ b/thread.tex
@@ -19,7 +19,7 @@ Tratteremo in questo capitolo un modello di programmazione multitasking,
 quello dei \textit{thread}, alternativo al modello classico dei processi,
 tipico di Unix. Ne esamineremo le caratteristiche, vantaggi e svantaggi, e le
 diverse realizzazioni che sono disponibili per Linux; nella seconda parte
-tratteremo in dettaglio quella che è l'implementazione principale, che fa
+tratteremo in dettaglio quella che è l'implementazione principale, che fa
 riferimento all'interfaccia standardizzata da POSIX.1e.
 
 
@@ -27,7 +27,7 @@ riferimento all'interfaccia standardizzata da POSIX.1e.
 \label{sec:thread_intro}
 
 Questa prima sezione costituisce una introduzione ai \textit{thread} e
-tratterà i concetti principali del relativo modello di programmazione,
+tratterà i concetti principali del relativo modello di programmazione,
 esamineremo anche quali modelli sono disponibili per Linux, dando una breve
 panoramica sulle implementazioni alternative.
 
@@ -41,12 +41,12 @@ panoramica sulle implementazioni alternative.
 % http://www.humanfactor.com/pthreads/
 
 Il modello classico dell'esecuzione dei programmi nei sistemi Unix, illustrato
-in sez.~\ref{cha:process_interface}, è fondato sui processi. Il modello nasce
-per assicurare la massima stabilità al sistema e prevede una rigida
+in sez.~\ref{cha:process_interface}, è fondato sui processi. Il modello nasce
+per assicurare la massima stabilità al sistema e prevede una rigida
 separazione fra i diversi processi, in modo che questi non possano disturbarsi
 a vicenda. 
 
-Le applicazioni moderne però sono altamente concorrenti, e necessitano quindi
+Le applicazioni moderne però sono altamente concorrenti, e necessitano quindi
 di un gran numero di processi; questo ha portato a scontrarsi con alcuni
 limiti dell'architettura precedente. In genere i fautori del modello di
 programmazione a \texttt{thread} sottolineano due problemi connessi all'uso
@@ -80,9 +80,9 @@ dei processi:
 
 
 Tratteremo in questa sezione l'interfaccia di programmazione con i
-\textit{thread} standardizzata dallo standard POSIX 1.c, che è quella che è
+\textit{thread} standardizzata dallo standard POSIX 1.c, che è quella che è
 stata seguita anche dalle varie implementazioni dei \textit{thread} realizzate
-su Linux, ed in particolare dalla \textit{Native Thread Posix Library} che è
+su Linux, ed in particolare dalla \textit{Native Thread Posix Library} che è
 stata integrata con i kernel della serie 2.6 e che fa parte a pieno titolo
 delle \acr{glibc}.
 
diff --git a/trasplayer.tex b/trasplayer.tex
index 75640be..c0fc934 100644
--- a/trasplayer.tex
+++ b/trasplayer.tex
@@ -15,27 +15,27 @@
 In questa appendice tratteremo i vari protocolli relativi al livello di
 trasporto.\footnote{al solito per la definizione dei livelli si faccia
   riferimento alle spiegazioni fornite in sez.~\ref{sec:net_protocols}.} In
-particolare gran parte del capitolo sarà dedicato al più importante di questi,
-il TCP, che è pure il più complesso ed utilizzato su internet.
+particolare gran parte del capitolo sarà dedicato al più importante di questi,
+il TCP, che è pure il più complesso ed utilizzato su internet.
 
 
 \section{Il protocollo TCP}
 \label{sec:tcp_protocol}
 
 In questa sezione prenderemo in esame i vari aspetti del protocollo TCP, il
-protocollo più comunemente usato dalle applicazioni di rete.
+protocollo più comunemente usato dalle applicazioni di rete.
 
 
 
 \subsection{Gli stati del TCP}
 \label{sec:TCP_states}
 
-In sez.~\ref{sec:TCP_connession} abbiamo descritto in dettaglio le modalità con
+In sez.~\ref{sec:TCP_connession} abbiamo descritto in dettaglio le modalità con
 cui il protocollo TCP avvia e conclude una connessione, ed abbiamo accennato
 alla presenza dei vari stati del protocollo. In generale infatti il
 funzionamento del protocollo segue una serie di regole, che possono essere
 riassunte nel comportamento di una macchina a stati, il cui diagramma di
-transizione è riportato in fig.~\ref{fig:TCP_state_diag}.
+transizione è riportato in fig.~\ref{fig:TCP_state_diag}.
 
 
 \begin{figure}[htb]
@@ -75,7 +75,7 @@ comando \cmd{netstat} nel campo \textit{State}.
 \label{sec:udp_protocol}
 
 In questa sezione prenderemo in esame i vari aspetti del protocollo UDP, che
-dopo il TCP è il protocollo più usato dalle applicazioni di rete. 
+dopo il TCP è il protocollo più usato dalle applicazioni di rete. 
 
 
 \begin{figure}[htb]