Ancora indicizzazioni
authorSimone Piccardi <piccardi@gnulinux.it>
Wed, 14 Oct 2015 20:38:45 +0000 (20:38 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Wed, 14 Oct 2015 20:38:45 +0000 (20:38 +0000)
15 files changed:
errors.tex
fileadv.tex
filedir.tex
fileio.tex
intro.tex
ipc.tex
macro.tex
netlayer.tex
network.tex
process.tex
prochand.tex
sockctrl.tex
socket.tex
system.tex
tcpsock.tex

index 57bf5a2..28af8f5 100644 (file)
@@ -137,8 +137,8 @@ gestione dei 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.
+  cerca di impostare lo \textit{sticky bit} su un file che non è una
+  directory.
 \end{basedescript}
 
 \section{Gli errori dei processi}
@@ -150,8 +150,8 @@ gestione dei processi.
 
 \begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
 \item[\errcode{ESRCH} \textit{No process matches the specified process ID}.]
-  Non esiste un processo o un \itindex{process~group} \textit{process group}
-  corrispondenti al valore dell'identificativo specificato.
+  Non esiste un processo o un \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
   la lista degli argomenti passata ad una delle funzioni \func{exec} occupa
index 027cbaa..9737bb0 100644 (file)
@@ -1182,7 +1182,7 @@ 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
 l'interfaccia creata da BSD, ma prevede che tutte le funzioni ad esso relative
-vengano dichiarate nell'header \headfile{sys/select.h}, che sostituisce i
+vengano dichiarate nell'header \headfiled{sys/select.h}, che sostituisce i
 precedenti, ed inoltre aggiunge a \func{select} una nuova funzione
 \funcd{pselect},\footnote{il supporto per lo standard POSIX 1003.1-2001, ed
   l'header \headfile{sys/select.h}, compaiono in Linux a partire dalle
@@ -3517,7 +3517,7 @@ Lo standard POSIX 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 \headfile{aio.h}, è riportata in
+effettuata in \headfiled{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.
index 4e7ead4..cac5bc4 100644 (file)
@@ -698,7 +698,7 @@ indietro al kernel ad ogni scrittura.\footnote{costituiscono quindi un
 
 Il tipo di filesystem che si vuole montare è specificato
 dall'argomento \param{filesystemtype}, che deve essere una delle stringhe
-riportate nel file \procfile{/proc/filesystems} che, come accennato in
+riportate nel file \procfilem{/proc/filesystems} che, come accennato in
 sez.~\ref{sec:file_vfs_work}, contiene l'elenco dei filesystem supportati dal
 kernel. Nel caso si sia indicato un filesystem virtuale, che non è associato a
 nessun file di dispositivo, il contenuto di \param{source} viene ignorato.
@@ -1248,18 +1248,17 @@ del filesystem stesso.
   \label{fig:sys_statfs}
 \end{figure}
 
-\conffilebeg{/etc/mtab}
-La \acr{glibc} provvede infine una serie di funzioni per la gestione dei due
-file \conffiled{/etc/fstab}\footnote{più precisamente \funcm{setfsent},
-  \funcm{getfsent}, \funcm{getfsfile}, \funcm{getfsspec}, \funcm{endfsent}.}
-ed \conffile{/etc/mtab}\footnote{più precisamente \funcm{setmntent},
-  \funcm{getmntent},\funcm{getmntent\_r}, \funcm{addmntent},\funcm{endmntent},
-  \funcm{hasmntopt}.} che convenzionalmente sono usati in quasi tutti i
-sistemi unix-like per mantenere rispettivamente le informazioni riguardo ai
-filesystem da montare e a quelli correntemente montati. Le funzioni servono a
-leggere il contenuto di questi file in opportune strutture \struct{fstab} e
-\struct{mntent}, e, nel caso di \conffile{/etc/mtab}, per inserire e rimuovere
-le voci presenti nel file.
+\conffilebeg{/etc/mtab} La \acr{glibc} provvede infine una serie di funzioni
+per la gestione dei due file \conffiled{/etc/fstab}\footnote{più precisamente
+  \funcm{setfsent}, \funcm{getfsent}, \funcm{getfsfile}, \funcm{getfsspec},
+  \funcm{endfsent}.}  ed \conffile{/etc/mtab}\footnote{più precisamente
+  \funcm{setmntent}, \funcm{getmntent},\funcm{getmntent\_r},
+  \funcm{addmntent},\funcm{endmntent}, \funcm{hasmntopt}.} che
+convenzionalmente sono usati in quasi tutti i sistemi unix-like per mantenere
+rispettivamente le informazioni riguardo ai filesystem da montare e a quelli
+correntemente montati. Le funzioni servono a leggere il contenuto di questi
+file in opportune strutture \structd{fstab} e \structd{mntent}, e, nel caso di
+\conffile{/etc/mtab}, per inserire e rimuovere le voci presenti nel file.
 
 In generale si dovrebbero usare queste funzioni, in particolare quelle
 relative a \conffile{/etc/mtab}, quando si debba scrivere un programma che
@@ -2747,8 +2746,8 @@ comportato il fatto che \type{dev\_t} è diventato un 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 \headfile{sys/sysmacros.h},\footnote{se si usa
-  la \acr{glibc} dalla versione 2.3.3 queste macro sono degli alias alle
+Le macro sono definite nel file \headfiled{sys/sysmacros.h},\footnote{se si
+  usa la \acr{glibc} dalla versione 2.3.3 queste macro sono degli alias alle
   versioni specifiche di questa libreria, \macrod{gnu\_dev\_major},
   \macrod{gnu\_dev\_minor} e \macrod{gnu\_dev\_makedev} che si possono usare
   direttamente, al costo di una minore portabilità.} che viene automaticamente
@@ -3100,7 +3099,7 @@ informazioni relative ad esso e non al file a cui fa riferimento. Infine
 tramite il suo file descriptor \param{filedes}.
 
 La struttura \struct{stat} usata da queste funzioni è definita nell'header
-\headfile{sys/stat.h} e in generale dipende dall'implementazione; la versione
+\headfiled{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
 effettivamente usata nel kernel dipende dall'architettura e ha altri campi
@@ -6433,7 +6432,7 @@ cui a ciascun processo sono stati associati tre distinti insiemi di
 \textit{inheritable} ed \textit{effective}. Questi insiemi vengono mantenuti
 in forma di tre diverse maschere binarie,\footnote{il kernel li mantiene, come
   i vari identificatori di sez.~\ref{sec:proc_setuid}, all'interno della
-  \struct{task\_struct} di ciascun processo (vedi
+  \texttt{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 era, fino al kernel 2.6.25 definito come
@@ -7048,7 +7047,7 @@ fig.~\ref{fig:cap_kernel_struct}.  Per un certo periodo di tempo era anche
 indicato che per poterle utilizzare fosse necessario che la macro
 \macro{\_POSIX\_SOURCE} risultasse non definita (ed era richiesto di inserire
 una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
-\headfile{sys/capability.h}) requisito che non risulta più
+\headfiled{sys/capability.h}) requisito che non risulta più
 presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
   necessario.}
 
@@ -7057,7 +7056,7 @@ presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
   \centering
   \begin{minipage}[c]{0.8\textwidth}
     \includestruct{listati/cap_user_header_t.h}
-  \end{minipage} 
+  \end{minipage}
   \normalsize 
   \caption{Definizione delle strutture a cui fanno riferimento i puntatori
     \structd{cap\_user\_header\_t} e \structd{cap\_user\_data\_t} usati per
index 6abde2f..a044eec 100644 (file)
@@ -93,8 +93,7 @@ queste strutture, che, come illustrato in fig.~\ref{fig:kstruct_file},
 contengono le informazioni necessarie per la gestione dei file, ed in
 particolare:
 \begin{itemize*}
-\item i flag di stato \itindex{file~status~flag} del file nel campo
-  \var{f\_flags}.
+\item i flag di stato del file nel campo \var{f\_flags}.
 \item la posizione corrente nel file, il cosiddetto \textit{offset}, nel campo
   \var{f\_pos}.
 \item un puntatore alla struttura \kstruct{inode} che identifica
@@ -119,6 +118,7 @@ In fig.~\ref{fig:file_proc_file} si è riportato uno schema semplificato in cui
 interrelazioni fra la \textit{file table}, la \textit{process table} e le
 varie strutture di dati che il kernel mantiene per ciascun file e ciascun
 processo.
+
 \itindend{process~table}
 
 Come si può notare alla fine il collegamento che consente di porre in
@@ -152,13 +152,15 @@ posto che non ne sia stato chiuso nessuno in precedenza.
 
 In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
 processo si aspetta di avere sempre tre file aperti che, per quanto appena
-detto, avranno come \itindex{file~descriptor} \textit{file descriptor} i
-valori 0, 1 e 2.  Il primo file è sempre associato al cosiddetto
-\textit{standard input}, è cioè il file da cui un processo si aspetta di dover
-leggere i dati in ingresso. Il secondo file è il cosiddetto \textit{standard
-  output}, cioè quello su cui ci si aspetta di dover scrivere i dati in
-uscita. Il terzo è lo  \textit{standard error}, su cui
-vengono scritti i dati relativi agli errori.
+detto, avranno come \textit{file descriptor} i valori 0, 1 e 2.  Il primo file
+è sempre associato al cosiddetto \textit{standard input}, è cioè il file da
+cui un processo si aspetta di dover leggere i dati in ingresso. Il secondo
+file è il cosiddetto \textit{standard output}, cioè quello su cui ci si
+aspetta di dover scrivere i dati in uscita. Il terzo è lo \textit{standard
+  error}, su cui vengono scritti i dati relativi agli errori.
+
+\itindend{file~descriptor} 
+
 
 Benché questa sia soltanto una convenzione, essa è seguita dalla gran parte
 delle applicazioni, e non aderirvi potrebbe portare a problemi di
@@ -176,14 +178,12 @@ tab.~\ref{tab:file_std_files}.
     \textbf{File} & \textbf{Significato} \\
     \hline
     \hline
-    \const{STDIN\_FILENO}  & \textit{file descriptor} dello
-                             \itindex{standard~input} \textit{standard
-                               input}.\\ 
-    \const{STDOUT\_FILENO} & \textit{file descriptor} dello
-                             \itindex{standard~output} \textit{standard
-                               output}.\\
+    \const{STDIN\_FILENO}  & \textit{file descriptor} dello \textit{standard
+                             input}.\\ 
+    \const{STDOUT\_FILENO} & \textit{file descriptor} dello \textit{standard
+                             output}.\\
     \const{STDERR\_FILENO} & \textit{file descriptor} dello \textit{standard
-                               error}.\\
+                             error}.\\
     \hline
   \end{tabular}
   \caption{Costanti definite in \headfile{unistd.h} per i file standard.}
@@ -231,7 +231,7 @@ La funzione di sistema \funcd{open} è la principale funzione dell'interfaccia
 di gestione dei file, quella che dato un \textit{pathname} consente di
 ottenere un file descriptor ``\textsl{aprendo}'' il file
 corrispondente,\footnote{è \func{open} che alloca \kstruct{file}, la inserisce
-  nella \itindex{file~table} \textit{file table} e crea il riferimento nella
+  nella \textit{file table} e crea il riferimento nella
   \kstruct{files\_struct} del processo.} il suo prototipo è:
 
 \begin{funcproto}{
@@ -287,17 +287,16 @@ venga creato, questo argomento consente di indicare quali permessi dovranno
 essergli assegnati. I valori possibili sono gli stessi già visti in
 sez.~\ref{sec:file_perm_overview} e possono essere specificati come OR binario
 delle costanti descritte in tab.~\ref{tab:file_bit_perm}. Questi permessi sono
-comunque filtrati dal valore della \itindex{umask} \textit{umask} (vedi
+comunque filtrati dal valore della \textit{umask} (vedi
 sez.~\ref{sec:file_perm_management}) del processo.
 
 La funzione restituisce sempre il primo file descriptor libero, una
 caratteristica che permette di prevedere qual è il valore del file descriptor
 che si otterrà al ritorno di \func{open}, e che viene spesso usata dalle
 applicazioni per sostituire i file corrispondenti ai file standard visti in
-tab.~\ref{tab:file_std_files}. Se ad esempio si chiude lo
-\itindex{standard~input} \textit{standard input} e si apre subito dopo un
-nuovo file questo diventerà il nuovo \itindex{standard~input} \textit{standard
-  input} dato che avrà il file descriptor 0.
+tab.~\ref{tab:file_std_files}. Se ad esempio si chiude lo \textit{standard
+  input} e si apre subito dopo un nuovo file questo diventerà il nuovo
+\textit{standard input} dato che avrà il file descriptor 0.
 
 Al momento dell'apertura il nuovo file descriptor non è condiviso con nessun
 altro processo (torneremo sul significato della condivisione dei file
@@ -309,14 +308,15 @@ impostata all'inizio del file. Una volta aperto un file si potrà operare su di
 esso direttamente tramite il file descriptor, e quanto avviene al
 \textit{pathname} con cui lo si è aperto sarà del tutto ininfluente.
 
+\itindbeg{file~status~flag}
+
 Il comportamento della funzione, e le diverse modalità con cui può essere
 aperto il file, vengono controllati dall'argomento \param{flags} il cui valore
 deve essere indicato come maschera binaria in cui ciascun bit ha un
 significato specifico.  Alcuni di questi bit vanno anche a costituire i
-cosiddetti \textsl{flag di stato} del file (i cosiddetti
-\itindex{file~status~flag} \textit{file status flags}), che vengono mantenuti
-nel campo \var{f\_flags} della struttura \kstruct{file} che abbiamo riportato
-anche in fig.~\ref{fig:file_proc_file}).
+cosiddetti \textsl{flag di stato} del file (i cosiddetti \textit{file status
+  flags}), che vengono mantenuti nel campo \var{f\_flags} della struttura
+\kstruct{file} che abbiamo riportato anche in fig.~\ref{fig:file_proc_file}).
 
 Ciascun flag viene identificato da una apposita costante, ed il valore
 di \param{flags} deve essere specificato come OR aritmetico di queste
@@ -365,17 +365,19 @@ equivalente a \const{O\_RDWR}, e non deve essere usata.\footnote{in realtà
   sez.~\ref{sec:file_fcntl_ioctl}).}
 
 La modalità di accesso deve sempre essere specificata quando si apre un file,
-il valore indicato in \param{flags} viene salvato nei
-\itindex{file~status~flag} \textit{file status flags}, e può essere riletto
-con \func{fcntl} (vedi sez.~\ref{sec:file_fcntl_ioctl}), il relativo valore
-può essere poi ottenuto un AND aritmetico della maschera binaria
-\const{O\_ACCMODE}, ma non può essere modificato. Nella \acr{glibc} sono
-definite inoltre \const{O\_READ} come sinonimo di \const{O\_RDONLY} e
-\const{O\_WRITE} come sinonimo di \const{O\_WRONLY}.\footnote{si tratta di
-  definizioni completamente fuori standard, attinenti, insieme a
-  \const{O\_EXEC} che permetterebbe l'apertura di un file per l'esecuzione, ad
-  un non meglio precisato ``\textit{GNU system}''; pur essendo equivalenti
-  alle definizioni classiche non è comunque il caso di utilizzarle.}
+il valore indicato in \param{flags} viene salvato nei \textit{file status
+  flags}, e può essere riletto con \func{fcntl} (vedi
+sez.~\ref{sec:file_fcntl_ioctl}), il relativo valore può essere poi ottenuto
+un AND aritmetico della maschera binaria \const{O\_ACCMODE}, ma non può essere
+modificato. Nella \acr{glibc} sono definite inoltre \const{O\_READ} come
+sinonimo di \const{O\_RDONLY} e \const{O\_WRITE} come sinonimo di
+\const{O\_WRONLY}.\footnote{si tratta di definizioni completamente fuori
+  standard, attinenti, insieme a \const{O\_EXEC} che permetterebbe l'apertura
+  di un file per l'esecuzione, ad un non meglio precisato ``\textit{GNU
+    system}''; pur essendo equivalenti alle definizioni classiche non è
+  comunque il caso di utilizzarle.}
+
+\itindend{file~status~flag}
 
 Il secondo gruppo di flag è quello delle \textsl{modalità di
   apertura},\footnote{la pagina di manuale di \func{open} parla di
@@ -386,8 +388,8 @@ Il secondo gruppo di flag è quello delle \textsl{modalità di
 permettono di specificare alcune delle caratteristiche del comportamento di
 \func{open} nel momento in viene eseguita per aprire un file. Questi flag
 hanno effetto solo nella chiamata della funzione, non sono memorizzati fra i
-\itindex{file~status~flag} \textit{file status flags} e non possono essere
-riletti da \func{fcntl} (vedi sez.~\ref{sec:file_fcntl_ioctl}).
+\textit{file status flags} e non possono essere riletti da \func{fcntl} (vedi
+sez.~\ref{sec:file_fcntl_ioctl}).
 
 \begin{table}[htb]
   \centering
@@ -498,16 +500,15 @@ si tronca il file con \const{O\_TRUNC} verranno impostati soltanto il
       \textbf{Flag} & \textbf{Significato} \\
       \hline
       \hline
-      \const{O\_APPEND}  & Il file viene aperto in \itindex{append~mode}
-                           \textit{append mode}. La posizione sul file (vedi
-                           sez.~\ref{sec:file_lseek}) viene sempre mantenuta
-                           sulla sua coda, per cui quanto si scrive
-                           viene sempre aggiunto al contenuto precedente. Con
-                           NFS questa funzionalità non è supportata 
-                           e viene emulata, per questo possono verificarsi
-                           \textit{race condition} con una sovrapposizione dei
-                           dati se più di un processo scrive allo stesso
-                           tempo.\\ 
+      \const{O\_APPEND}  & Il file viene aperto in \textit{append mode}. La
+                           posizione sul file (vedi sez.~\ref{sec:file_lseek})
+                           viene sempre mantenuta sulla sua coda, per cui
+                           quanto si scrive viene sempre aggiunto al contenuto
+                           precedente. Con NFS questa funzionalità non è
+                           supportata  e viene emulata, per questo possono
+                           verificarsi \textit{race condition} con una
+                           sovrapposizione dei dati se più di un processo
+                           scrive allo stesso tempo.\\ 
       \const{O\_ASYNC}   & Apre il file per l'I/O in modalità asincrona (vedi
                            sez.~\ref{sec:signal_driven_io}). Quando è
                            impostato viene generato il segnale \signal{SIGIO}
@@ -520,14 +521,14 @@ si tronca il file con \const{O\_TRUNC} verranno impostati soltanto il
                            invece essere attivato successivamente con
                            \func{fcntl}.\\
       \const{O\_CLOEXEC}&  Attiva la modalità di \textit{close-on-exec} (vedi
-                           sez.~\ref{sec:proc_exec}) sul file. Il flag è 
-                           previsto dallo standard POSIX.1-2008, ed è stato
-                           introdotto con il kernel 2.6.23 per evitare una
-                           \textit{race condition} che si potrebbe verificare
-                           con i \textit{thread} fra l'apertura del file e
-                           l'impostazione della suddetta modalità con
-                           \func{fcntl} (vedi
-                           sez.~\ref{sec:file_fcntl_ioctl}).\\ 
+                          sez.~\ref{sec:proc_exec}) sul file. Il flag è 
+                          previsto dallo standard POSIX.1-2008, ed è stato
+                          introdotto con il kernel 2.6.23 per evitare una
+                          \textit{race condition} che si potrebbe verificare
+                          con i \textit{thread} fra l'apertura del file e
+                          l'impostazione della suddetta modalità con
+                          \func{fcntl} (vedi
+                          sez.~\ref{sec:file_fcntl_ioctl}).\\ 
       \const{O\_DIRECT}  & Esegue l'I/O direttamente dalla memoria in
                            \textit{user space} in maniera sincrona, in modo da
                            scavalcare i meccanismi di bufferizzazione del
@@ -708,13 +709,13 @@ disponibile; il suo prototipo è:
 \end{funcproto}
 
 La funzione chiude il file descriptor \param{fd}. La chiusura rilascia ogni
-eventuale blocco (il \textit{file locking} \itindex{file~locking} è trattato
-in sez.~\ref{sec:file_locking}) che il processo poteva avere acquisito su di
+eventuale blocco (il \textit{file locking} è trattato in
+sez.~\ref{sec:file_locking}) che il processo poteva avere acquisito su di
 esso. Se \param{fd} è l'ultimo riferimento (di eventuali copie, vedi
 sez.~\ref{sec:file_shared_access} e \ref{sec:file_dup}) ad un file aperto,
-tutte le risorse nella \itindex{file~table} \textit{file table} vengono
-rilasciate. Infine se il file descriptor era l'ultimo riferimento ad un file
-su disco quest'ultimo viene cancellato.
+tutte le risorse nella \textit{file table} vengono rilasciate. Infine se il
+file descriptor era l'ultimo riferimento ad un file su disco quest'ultimo
+viene cancellato.
 
 Si ricordi che quando un processo termina tutti i suoi file descriptor vengono
 automaticamente chiusi, molti programmi sfruttano questa caratteristica e non
@@ -749,10 +750,11 @@ intero positivo che esprime il 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à di \textit{append} con
-\const{O\_APPEND}, questa posizione viene impostata a zero all'apertura del
-file. È possibile impostarla ad un valore qualsiasi con la funzione di sistema
-\funcd{lseek}, il cui prototipo è:
+In genere, a meno di non avere richiesto la modalità di scrittura in
+\textit{append} (vedi sez.~\ref{sec:file_write}) con \const{O\_APPEND}, questa
+posizione viene impostata a zero all'apertura del file. È possibile impostarla
+ad un valore qualsiasi con la funzione di sistema \funcd{lseek}, il cui
+prototipo è:
 
 \begin{funcproto}{
 \fhead{sys/types.h}
@@ -860,7 +862,7 @@ vuota.
 Questa è una delle caratteristiche specifiche della gestione dei file di un
 sistema unix-like e si dice che il file in questione è uno \textit{sparse
   file}. In sostanza, se si ricorda la struttura di un filesystem illustrata
-in fig.~\ref{fig:file_filesys_detail}, quello che accade è che \itindex{inode}
+in fig.~\ref{fig:file_filesys_detail}, quello che accade è che
 nell'\textit{inode} del file viene segnata l'allocazione di un blocco di dati
 a partire dalla nuova posizione, ma non viene allocato nulla per le posizioni
 intermedie; in caso di lettura sequenziale del contenuto del file il kernel si
@@ -877,12 +879,11 @@ 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
-effettivamente allocato, e viene registrata \itindex{inode}
-sull'\textit{inode} come le altre proprietà del file. La dimensione viene
-aggiornata automaticamente quando si estende un file scrivendoci, e viene
-riportata dal campo \var{st\_size} di una struttura \struct{stat} quando si
-effettua la chiamata ad una delle funzioni \texttt{*stat} viste in
-sez.~\ref{sec:file_stat}.
+effettivamente allocato, e viene registrata sull'\textit{inode} come le altre
+proprietà del file. La dimensione viene aggiornata automaticamente quando si
+estende un file scrivendoci, e viene riportata dal campo \var{st\_size} di una
+struttura \struct{stat} quando si effettua la chiamata ad una delle funzioni
+\texttt{*stat} viste in sez.~\ref{sec:file_stat}.
 
 Questo comporta che in generale, fintanto che lo si è scritto sequenzialmente,
 la dimensione di un file sarà più o meno corrispondente alla quantità di
@@ -1087,6 +1088,8 @@ prototipo è:
 \end{funcproto}
 
 
+\itindbeg{append~mode}
+
 Come nel caso di \func{read} la funzione tenta di scrivere \param{count} byte
 a partire dalla posizione corrente nel file e sposta automaticamente la
 posizione in avanti del numero di byte scritti. Se il file è aperto in
@@ -1096,6 +1099,8 @@ immediatamente disponibili ad una \func{read} chiamata dopo che la
 \func{write} che li ha scritti è ritornata; ma dati i meccanismi di caching
 non è detto che tutti i filesystem supportino questa capacità.
 
+\itindend{append~mode}
+
 Se \param{count} è zero la funzione restituisce zero senza fare nient'altro.
 Per i file ordinari il numero di byte scritti è sempre uguale a quello
 indicato da \param{count}, a meno di un errore. Negli altri casi si ha lo
@@ -1152,30 +1157,29 @@ 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
 diverso file descriptor nella sua \kstruct{file\_struct}. Entrambe le voci
-nella \itindex{file~table} \textit{file table} faranno però riferimento allo
-stesso \itindex{inode} \textit{inode} su disco.
+nella \textit{file table} faranno però riferimento allo stesso \textit{inode}
+su disco.
 
 Questo significa che ciascun processo avrà la sua posizione corrente sul file,
 la sua modalità di accesso e versioni proprie di tutte le proprietà che
-vengono mantenute nella sua voce della \itindex{file~table} \textit{file
-  table}. Questo ha conseguenze specifiche sugli effetti della possibile
-azione simultanea sullo stesso file, in particolare occorre tenere presente
-che:
+vengono mantenute nella sua voce della \textit{file table}. Questo ha
+conseguenze specifiche sugli effetti della possibile azione simultanea sullo
+stesso file, in particolare occorre tenere presente che:
 \begin{itemize}
 \item ciascun processo può scrivere indipendentemente, dopo ciascuna
   \func{write} la posizione corrente sarà cambiata solo nel processo
   scrivente. Se la scrittura eccede la dimensione corrente del file questo
   verrà esteso automaticamente con l'aggiornamento del campo \var{i\_size}
   della struttura \kstruct{inode}.
-\item se un file è in modalità \itindex{append~mode} \const{O\_APPEND} tutte
-  le volte che viene effettuata una scrittura la posizione corrente viene
-  prima impostata alla dimensione corrente del file letta dalla struttura
-  \kstruct{inode}. Dopo la scrittura il file viene automaticamente esteso.
+\item se un file è in modalità \const{O\_APPEND} tutte le volte che viene
+  effettuata una scrittura la posizione corrente viene prima impostata alla
+  dimensione corrente del file letta dalla struttura \kstruct{inode}. Dopo la
+  scrittura il file viene automaticamente esteso.
 \item l'effetto di \func{lseek} è solo quello di cambiare il campo
-  \var{f\_pos} nella struttura \kstruct{file} della \itindex{file~table}
-  \textit{file table}, non c'è nessuna operazione sul file su disco. Quando la
-  si usa per porsi alla fine del file la posizione viene impostata leggendo la
-  dimensione corrente dalla struttura \kstruct{inode}.
+  \var{f\_pos} nella struttura \kstruct{file} della \textit{file table}, non
+  c'è nessuna operazione sul file su disco. Quando la si usa per porsi alla
+  fine del file la posizione viene impostata leggendo la dimensione corrente
+  dalla struttura \kstruct{inode}.
 \end{itemize}
 
 \begin{figure}[!htb]
@@ -1186,38 +1190,36 @@ che:
 \end{figure}
 
 Il secondo caso è quello in cui due file descriptor di due processi diversi
-puntino alla stessa voce nella \itindex{file~table} \textit{file table}.
-Questo è ad esempio il caso dei file aperti che vengono ereditati dal processo
-figlio all'esecuzione di una \func{fork} (si ricordi quanto detto in
-sez.~\ref{sec:proc_fork}). La situazione è illustrata in
-fig.~\ref{fig:file_acc_child}; dato che il processo figlio riceve una copia
-dello spazio di indirizzi del padre, riceverà anche una copia di
-\kstruct{file\_struct} e della relativa tabella dei file aperti.
+puntino alla stessa voce nella \textit{file table}.  Questo è ad esempio il
+caso dei file aperti che vengono ereditati dal processo figlio all'esecuzione
+di una \func{fork} (si ricordi quanto detto in sez.~\ref{sec:proc_fork}). La
+situazione è illustrata in fig.~\ref{fig:file_acc_child}; dato che il processo
+figlio riceve una copia dello spazio di indirizzi del padre, riceverà anche
+una copia di \kstruct{file\_struct} e della relativa tabella dei file aperti.
 
 Questo significa che il figlio avrà gli stessi file aperti del padre, in
 quanto la sua \kstruct{file\_struct}, pur essendo allocata in maniera
 indipendente, contiene gli stessi valori di quella del padre e quindi i suoi
-file descriptor faranno riferimento alla stessa voce nella
-\itindex{file~table} \textit{file table}, condividendo così la posizione
-corrente sul file. Questo ha le conseguenze descritte a suo tempo in
-sez.~\ref{sec:proc_fork}: in caso di scrittura o lettura da parte di uno dei
-due processi, la posizione corrente nel file varierà per entrambi, in quanto
-verrà modificato il campo \var{f\_pos} della struttura \kstruct{file}, che è
-la stessa per entrambi. Questo consente una sorta di
-``\textsl{sincronizzazione}'' automatica della posizione sul file fra padre e
-figlio che occorre tenere presente.
-
-Si noti inoltre che in questo caso anche i \itindex{file~status~flag} flag di
-stato del file, essendo mantenuti nella struttura \kstruct{file} della
-\textit{file table}, vengono condivisi, per cui una modifica degli stessi con
-\func{fcntl} (vedi sez.~\ref{sec:file_fcntl_ioctl}) si applicherebbe a tutti
-processi che condividono la voce nella \itindex{file~table} \textit{file
-  table}. Ai file però sono associati anche altri flag, dei quali l'unico
-usato al momento è \const{FD\_CLOEXEC}, detti \itindex{file~descriptor~flags}
-\textit{file descriptor flags}; questi invece sono mantenuti in
-\kstruct{file\_struct}, e perciò sono locali per ciascun processo e non
-vengono modificati dalle azioni degli altri anche in caso di condivisione
-della stessa voce della \itindex{file~table} \textit{file table}.
+file descriptor faranno riferimento alla stessa voce nella \textit{file
+  table}, condividendo così la posizione corrente sul file. Questo ha le
+conseguenze descritte a suo tempo in sez.~\ref{sec:proc_fork}: in caso di
+scrittura o lettura da parte di uno dei due processi, la posizione corrente
+nel file varierà per entrambi, in quanto verrà modificato il campo
+\var{f\_pos} della struttura \kstruct{file}, che è la stessa per
+entrambi. Questo consente una sorta di ``\textsl{sincronizzazione}''
+automatica della posizione sul file fra padre e figlio che occorre tenere
+presente.
+
+Si noti inoltre che in questo caso anche i flag di stato del file, essendo
+mantenuti nella struttura \kstruct{file} della \textit{file table}, vengono
+condivisi, per cui una modifica degli stessi con \func{fcntl} (vedi
+sez.~\ref{sec:file_fcntl_ioctl}) si applicherebbe a tutti processi che
+condividono la voce nella \textit{file table}. Ai file però sono associati
+anche altri flag, dei quali l'unico usato al momento è \const{FD\_CLOEXEC},
+detti \itindex{file~descriptor~flags} \textit{file descriptor flags}; questi
+invece sono mantenuti in \kstruct{file\_struct}, e perciò sono locali per
+ciascun processo e non vengono modificati dalle azioni degli altri anche in
+caso di condivisione della stessa voce della \textit{file table}.
 
 Si tenga presente dunque che in un sistema unix-like è sempre possibile per
 più processi accedere in contemporanea allo stesso file e che non esistono, a
@@ -1235,8 +1237,8 @@ sovrapposizioni imprevedibili quando due processi scrivono nella stessa
 sezione di file, dato che ciascuno lo farà in maniera indipendente.  Il
 sistema però fornisce in alcuni casi la possibilità di eseguire alcune
 operazioni di scrittura in maniera coordinata anche senza utilizzare dei
-meccanismi di sincronizzazione espliciti come il \itindex{file~locking}
-\textit{file locking}, che esamineremo in sez.~\ref{sec:file_locking}.
+meccanismi di sincronizzazione espliciti come il \textit{file locking}, che
+esamineremo in sez.~\ref{sec:file_locking}.
 
 Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
 vari processi devono scrivere alla fine di un file (ad esempio un file di
@@ -1251,13 +1253,13 @@ sua successiva \func{write} sovrascriverà i dati del secondo processo.
 Il problema deriva dal fatto che usare due \textit{system call} in successione
 non è mai un'operazione atomica dato che il kernel può interrompere
 l'esecuzione del processo fra le due. Nel caso specifico il problema è stato
-risolto introducendo la modalità di scrittura \itindex{append~mode} in
-\textit{append}, attivabile con il flag \const{O\_APPEND}. In questo caso
-infatti, come abbiamo illustrato in sez.~\ref{sec:file_open_close}, è il
-kernel che aggiorna automaticamente la posizione alla fine del file prima di
-effettuare la scrittura, e poi estende il file.  Tutto questo avviene
-all'interno di una singola \textit{system call}, la \func{write}, che non
-essendo interrompibile da un altro processo realizza un'operazione atomica.
+risolto introducendo la modalità di scrittura in \textit{append}, attivabile
+con il flag \const{O\_APPEND}. In questo caso infatti, come abbiamo illustrato
+in sez.~\ref{sec:file_open_close}, è il kernel che aggiorna automaticamente la
+posizione alla fine del file prima di effettuare la scrittura, e poi estende
+il file.  Tutto questo avviene all'interno di una singola \textit{system
+  call}, la \func{write}, che non essendo interrompibile da un altro processo
+realizza un'operazione atomica.
 
 
 \subsection{La duplicazione dei file descriptor}
@@ -1302,12 +1304,12 @@ da cui il nome della funzione.
 \end{figure}
 
 Si noti che per quanto illustrato in fig.~\ref{fig:file_dup} i file descriptor
-duplicati condivideranno eventuali lock (vedi sez.~\ref{sec:file_locking}),
-\itindex{file~status~flag} i flag di stato, e la posizione corrente sul
-file. Se ad esempio si esegue una \func{lseek} per modificare la posizione su
-uno dei due file descriptor, essa risulterà modificata anche sull'altro, dato
-che quello che viene modificato è lo stesso campo nella voce della
-\textit{file table} a cui entrambi fanno riferimento. 
+duplicati condivideranno eventuali lock (vedi sez.~\ref{sec:file_locking}), i
+flag di stato, e la posizione corrente sul file. Se ad esempio si esegue una
+\func{lseek} per modificare la posizione su uno dei due file descriptor, essa
+risulterà modificata anche sull'altro, dato che quello che viene modificato è
+lo stesso campo nella voce della \textit{file table} a cui entrambi fanno
+riferimento.
 
 L'unica differenza fra due file descriptor duplicati è che ciascuno avrà un
 suo \textit{file descriptor flag} indipendente. A questo proposito deve essere
@@ -1319,9 +1321,9 @@ cancellato nel file descriptor restituito come copia.
 L'uso principale di questa funzione è nella shell per la redirezione dei file
 standard di tab.~\ref{tab:file_std_files} fra l'esecuzione di una \func{fork}
 e la successiva \func{exec}. Diventa così possibile associare un file (o una
-\textit{pipe}) allo \itindex{standard~input} \textit{standard input} o allo
-\itindex{standard~output} \textit{standard output} (vedremo un esempio in
-sez.~\ref{sec:ipc_pipe_use}, quando tratteremo le \textit{pipe}).
+\textit{pipe}) allo \textit{standard input} o allo \textit{standard output}
+(vedremo un esempio in sez.~\ref{sec:ipc_pipe_use}, quando tratteremo le
+\textit{pipe}).
 
 Ci si può chiedere perché non sia in questo caso sufficiente chiudere il file
 standard che si vuole redirigere e poi aprire direttamente con \func{open} il
@@ -1504,13 +1506,12 @@ Entrambe le funzioni forzano la sincronizzazione col disco di tutti i dati del
 file specificato, ed attendono fino alla conclusione delle operazioni. La
 prima, \func{fsync} forza anche la sincronizzazione dei meta-dati del file,
 che riguardano sia le modifiche alle tabelle di allocazione dei settori, che
-gli altri dati contenuti \itindex{inode} nell'\textit{inode} che si leggono
-con \func{fstat}, come i tempi del file. Se lo scopo dell'operazione, come
-avviene spesso per i database, è assicurarsi che i dati raggiungano il disco e
-siano rileggibili immediatamente in maniera corretta, è sufficiente l'uso di
-\func{fdatasync} che non comporta anche l'esecuzione di operazioni non
-necessarie all'integrità dei dati, come l'aggiornamento dei tempi di ultima
-modifica ed ultimo accesso.
+gli altri dati contenuti nell'\textit{inode} che si leggono con \func{fstat},
+come i tempi del file. Se lo scopo dell'operazione, come avviene spesso per i
+database, è assicurarsi che i dati raggiungano il disco e siano rileggibili
+immediatamente in maniera corretta, è sufficiente l'uso di \func{fdatasync}
+che non comporta anche l'esecuzione di operazioni non necessarie all'integrità
+dei dati, come l'aggiornamento dei tempi di ultima modifica ed ultimo accesso.
 
 Si tenga presente che l'uso di queste funzioni non comporta la
 sincronizzazione della directory che contiene il file e la scrittura della
@@ -1598,9 +1599,8 @@ L'uso di queste funzioni prevede una apertura iniziale della directory che
 sarà la base della risoluzione dei \textit{pathname} relativi che verranno
 usati in seguito, dopo di che si dovrà passare il relativo file descriptor
 alle varie funzioni che useranno quella directory come punto di partenza per
-la risoluzione. In questo modo, anche quando si lavora con i \itindex{thread}
-\textit{thread}, si può mantenere una directory di lavoro diversa per ciascuno
-di essi.
+la risoluzione. In questo modo, anche quando si lavora con i \textit{thread},
+si può mantenere una directory di lavoro diversa per ciascuno di essi.
 
 Questo metodo, oltre a risolvere i problemi di \textit{race condition},
 consente anche di ottenere aumenti di prestazioni significativi quando si
@@ -1889,8 +1889,8 @@ Per le operazioni di manipolazione e di controllo delle varie proprietà e
 caratteristiche di un file descriptor, viene usata la funzione di sistema
 \funcd{fcntl},\footnote{ad esempio si gestiscono con questa funzione varie
   modalità di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_operation}) e
-  il \itindex{file~locking} \textit{file locking} (vedi
-  sez.~\ref{sec:file_locking}).} il cui prototipo è:
+  il \textit{file locking} (vedi sez.~\ref{sec:file_locking}).} il cui
+prototipo è:
 
 \begin{funcproto}{
 \fhead{unistd.h}
@@ -2010,28 +2010,28 @@ il nome indicato nel precedente prototipo), è riportata di seguito:
   dettaglio in sez.~\ref{sec:file_posix_lock}.
 
 \item[\const{F\_GETOWN}] restituisce in caso di successo l'identificatore del
-  processo o del \itindex{process~group} \textit{process group} (vedi
-  sez.~\ref{sec:sess_proc_group}) che è preposto alla ricezione del segnale
-  \signal{SIGIO} (o l'eventuale segnale alternativo impostato con
-  \const{F\_SETSIG}) per gli eventi asincroni associati al file
-  descriptor \param{fd} e del segnale \signal{SIGURG} per la notifica dei dati
-  urgenti di un socket (vedi sez.~\ref{sec:TCP_urgent_data}). Restituisce $-1$
-  in caso di errore ed il terzo argomento viene ignorato. Non sono previsti
-  errori diversi da \errval{EBADF}.
+  processo o del \textit{process group} (vedi sez.~\ref{sec:sess_proc_group})
+  che è preposto alla ricezione del segnale \signal{SIGIO} (o l'eventuale
+  segnale alternativo impostato con \const{F\_SETSIG}) per gli eventi
+  asincroni associati al file descriptor \param{fd} e del segnale
+  \signal{SIGURG} per la notifica dei dati urgenti di un socket (vedi
+  sez.~\ref{sec:TCP_urgent_data}). Restituisce $-1$ in caso di errore ed il
+  terzo argomento viene ignorato. Non sono previsti errori diversi da
+  \errval{EBADF}.
 
   Per distinguerlo dal caso in cui il segnale viene inviato a un singolo
   processo, nel caso di un \textit{process group} viene restituito un valore
   negativo il cui valore assoluto corrisponde all'identificatore del
-  \itindex{process~group} \textit{process group}. Con Linux questo comporta un
-  problema perché se il valore restituito dalla \textit{system call} è
-  compreso nell'intervallo fra $-1$ e $-4095$ in alcune architetture questo
-  viene trattato dalla \acr{glibc} come un errore,\footnote{il problema deriva
-    dalle limitazioni presenti in architetture come quella dei normali PC
-    (i386) per via delle modalità in cui viene effettuata l'invocazione delle
-    \textit{system call} che non consentono di restituire un adeguato codice
-    di ritorno.} per cui in tal caso \func{fcntl} ritornerà comunque $-1$
-  mentre il valore restituito dalla \textit{system call} verrà assegnato ad
-  \var{errno}, cambiato di segno.
+  \textit{process group}. Con Linux questo comporta un problema perché se il
+  valore restituito dalla \textit{system call} è compreso nell'intervallo fra
+  $-1$ e $-4095$ in alcune architetture questo viene trattato dalla
+  \acr{glibc} come un errore,\footnote{il problema deriva dalle limitazioni
+    presenti in architetture come quella dei normali PC (i386) per via delle
+    modalità in cui viene effettuata l'invocazione delle \textit{system call}
+    che non consentono di restituire un adeguato codice di ritorno.} per cui
+  in tal caso \func{fcntl} ritornerà comunque $-1$ mentre il valore restituito
+  dalla \textit{system call} verrà assegnato ad \var{errno}, cambiato di
+  segno.
 
   Per questo motivo con il kernel 2.6.32 è stato introdotto il comando
   alternativo \const{F\_GETOWN\_EX}, che vedremo a breve, che consente di
@@ -2039,28 +2039,27 @@ il nome indicato nel precedente prototipo), è riportata di seguito:
   disponibile, usa questa versione alternativa per mascherare il problema
   precedente e restituire un valore corretto in tutti i casi.\footnote{in cui
     cioè viene restituito un valore negativo corretto qualunque sia
-    l'identificatore del \itindex{process~group} \textit{process group}, che
-    non potendo avere valore unitario (non esiste infatti un
-    \itindex{process~group} \textit{process group} per \cmd{init}) non può
-    generare ambiguità con il codice di errore.} Questo però comporta che il
-  comportamento del comando può risultare diverso a seconda delle versioni
+    l'identificatore del \textit{process group}, che non potendo avere valore
+    unitario (non esiste infatti un \textit{process group} per \cmd{init}) non
+    può generare ambiguità con il codice di errore.} Questo però comporta che
+  il comportamento del comando può risultare diverso a seconda delle versioni
   della \acr{glibc} e del kernel.
 
 \item[\const{F\_SETOWN}] imposta, con il valore dell'argomento \param{arg},
-  l'identificatore del processo o del \itindex{process~group} \textit{process
-    group} che riceverà i segnali \signal{SIGIO} e \signal{SIGURG} per gli
-  eventi associati al file descriptor \param{fd}. Ritorna un valore nullo in
-  caso di successo o $-1$ in caso di errore. Oltre a \errval{EBADF} gli errori
-  possibili sono \errcode{ESRCH} se \param{arg} indica un processo o un
-  \itindex{process~group} \textit{process group} inesistente.
+  l'identificatore del processo o del \textit{process group} che riceverà i
+  segnali \signal{SIGIO} e \signal{SIGURG} per gli eventi associati al file
+  descriptor \param{fd}. Ritorna un valore nullo in caso di successo o $-1$ in
+  caso di errore. Oltre a \errval{EBADF} gli errori possibili sono
+  \errcode{ESRCH} se \param{arg} indica un processo o un \textit{process
+    group} inesistente.
 
   L'impostazione è soggetta alle stesse restrizioni presenti sulla funzione
   \func{kill} (vedi sez.~\ref{sec:sig_kill_raise}), per cui un utente non
   privilegiato può inviare i segnali solo ad un processo che gli appartiene,
   in genere comunque si usa il processo corrente.  Come per \const{F\_GETOWN},
-  per indicare un \itindex{process~group} \textit{process group} si deve usare
-  per \param{arg} un valore negativo, il cui valore assoluto corrisponda
-  all'identificatore del \itindex{process~group} \textit{process group}.
+  per indicare un \textit{process group} si deve usare per \param{arg} un
+  valore negativo, il cui valore assoluto corrisponda all'identificatore del
+  \textit{process group}.
 
   A partire dal kernel 2.6.12 se si sta operando con i \textit{thread} della
   implementazione nativa di Linux (quella della NTPL, vedi
@@ -2074,17 +2073,16 @@ il nome indicato nel precedente prototipo), è riportata di seguito:
   caso è anche l'unico, mantiene un valore del \textit{Thread ID} uguale al
   \ids{PID} del processo. Il problema è però che questo comportamento non si
   applica a \signal{SIGURG}, per il quale \param{arg} viene sempre
-  interpretato come l'identificatore di un processo o di un
-  \itindex{process~group} \textit{process group}.
+  interpretato come l'identificatore di un processo o di un \textit{process
+    group}.
 
 \item[\const{F\_GETOWN\_EX}] legge nella struttura puntata
-  dall'argomento \param{owner} l'identificatore del processo, \textit{thread} o
-  \itindex{process~group} \textit{process group} (vedi
-  sez.~\ref{sec:sess_proc_group}) che è preposto alla ricezione dei segnali
-  \signal{SIGIO} e \signal{SIGURG} per gli eventi associati al file
-  descriptor \param{fd}.  Ritorna un valore nullo in caso di successo o $-1$
-  in caso di errore. Oltre a  \errval{EBADF} e da
-  \errval{EFAULT} se \param{owner} non è un puntatore valido.  
+  dall'argomento \param{owner} l'identificatore del processo, \textit{thread}
+  o \textit{process group} (vedi sez.~\ref{sec:sess_proc_group}) che è
+  preposto alla ricezione dei segnali \signal{SIGIO} e \signal{SIGURG} per gli
+  eventi associati al file descriptor \param{fd}.  Ritorna un valore nullo in
+  caso di successo o $-1$ in caso di errore. Oltre a \errval{EBADF} e da
+  \errval{EFAULT} se \param{owner} non è un puntatore valido.
 
   Il comando, che è disponibile solo a partire dal kernel 2.6.32, effettua lo
   stesso compito di \const{F\_GETOWN} di cui costituisce una evoluzione che
@@ -2097,8 +2095,8 @@ il nome indicato nel precedente prototipo), è riportata di seguito:
 
 \item[\const{F\_SETOWN\_EX}] imposta con il valore della struttura
   \struct{f\_owner\_ex} puntata \param{owner}, l'identificatore del processo o
-  del \itindex{process~group} \textit{process group} che riceverà i segnali
-  \signal{SIGIO} e \signal{SIGURG} per gli eventi associati al file
+  del \textit{process group} che riceverà i segnali \signal{SIGIO} e
+  \signal{SIGURG} per gli eventi associati al file
   descriptor \param{fd}. Ritorna un valore nullo in caso di successo o $-1$ in
   caso di errore, con gli stessi errori di \const{F\_SETOWN} più
   \errcode{EINVAL} se il campo \var{type} di \struct{f\_owner\_ex} non indica
@@ -2160,25 +2158,23 @@ il nome indicato nel precedente prototipo), è riportata di seguito:
   sez.~\ref{sec:sig_real_time}), ed in particolare la capacità di essere
   accumulati in una coda prima della notifica.
 
-\item[\const{F\_GETLEASE}] restituisce il tipo di \itindex{file~lease}
-  \textit{file lease} che il processo detiene nei confronti del file
-  descriptor \var{fd} o $-1$ in caso di errore, il terzo argomento viene
-  ignorato. Non sono previsti errori diversi da \errval{EBADF}.  Il comando è
-  specifico di Linux ed utilizzabile solo se si è definita la macro
-  \macro{\_GNU\_SOURCE}.  Questa funzionalità è trattata in dettaglio in
-  sez.~\ref{sec:file_asyncronous_lease}.
+\item[\const{F\_GETLEASE}] restituisce il tipo di \textit{file lease} che il
+  processo detiene nei confronti del file descriptor \var{fd} o $-1$ in caso
+  di errore, il terzo argomento viene ignorato. Non sono previsti errori
+  diversi da \errval{EBADF}.  Il comando è specifico di Linux ed utilizzabile
+  solo se si è definita la macro \macro{\_GNU\_SOURCE}.  Questa funzionalità è
+  trattata in dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
 
 \item[\const{F\_SETLEASE}] imposta o rimuove a seconda del valore
-  di \param{arg} un \itindex{file~lease} \textit{file lease} sul file
-  descriptor \var{fd} a seconda del valore indicato da \param{arg}. Ritorna un
-  valore nullo in caso di successo o $-1$ in caso di errore. Oltre a
-  \errval{EBADF} si otterrà \errcode{EINVAL} se si è specificato un valore non
-  valido per \param{arg} (deve essere usato uno dei valori di
-  tab.~\ref{tab:file_lease_fctnl}), \errcode{ENOMEM} se non c'è memoria
-  sufficiente per creare il \textit{file lease}, \errcode{EACCES} se non si è
-  il proprietario del file e non si hanno i privilegi di
-  amministratore.\footnote{per la precisione occorre la capacità
-     \const{CAP\_LEASE}.}
+  di \param{arg} un \textit{file lease} sul file descriptor \var{fd} a seconda
+  del valore indicato da \param{arg}. Ritorna un valore nullo in caso di
+  successo o $-1$ in caso di errore. Oltre a \errval{EBADF} si otterrà
+  \errcode{EINVAL} se si è specificato un valore non valido per \param{arg}
+  (deve essere usato uno dei valori di tab.~\ref{tab:file_lease_fctnl}),
+  \errcode{ENOMEM} se non c'è memoria sufficiente per creare il \textit{file
+    lease}, \errcode{EACCES} se non si è il proprietario del file e non si
+  hanno i privilegi di amministratore.\footnote{per la precisione occorre la
+    capacità \const{CAP\_LEASE}.}
 
   Il supporto il supporto per i \textit{file lease}, che consente ad un
   processo che detiene un \textit{lease} su un file di riceve una notifica
@@ -2233,9 +2229,9 @@ riprese più avanti quando affronteremo le problematiche ad esse relative. In
 particolare le tematiche relative all'I/O asincrono e ai vari meccanismi di
 notifica saranno trattate in maniera esaustiva in
 sez.~\ref{sec:file_asyncronous_operation} mentre quelle relative al
-\itindex{file~locking} \textit{file locking} saranno esaminate in
-sez.~\ref{sec:file_locking}). L'uso di questa funzione con i socket verrà
-trattato in sez.~\ref{sec:sock_ctrl_func}.
+\textit{file locking} saranno esaminate in sez.~\ref{sec:file_locking}). L'uso
+di questa funzione con i socket verrà trattato in
+sez.~\ref{sec:sock_ctrl_func}.
 
 La gran parte dei comandi di \func{fcntl} (\const{F\_DUPFD}, \const{F\_GETFD},
 \const{F\_SETFD}, \const{F\_GETFL}, \const{F\_SETFL}, \const{F\_GETLK},
@@ -2318,7 +2314,7 @@ elenco di alcuni esempi di esse è il seguente:
 
 In generale ogni dispositivo ha un suo insieme di operazioni specifiche
 effettuabili attraverso \func{ioctl}, tutte queste sono definite nell'header
-file \headfile{sys/ioctl.h}, e devono essere usate solo sui dispositivi cui
+file \headfiled{sys/ioctl.h}, e devono essere usate solo sui dispositivi cui
 fanno riferimento. Infatti anche se in genere i valori di \param{request} sono
 opportunamente differenziati a seconda del dispositivo\footnote{il kernel usa
   un apposito \textit{magic number} per distinguere ciascun dispositivo nella
@@ -2463,8 +2459,6 @@ quanto visto in sez.~\ref{sec:file_shared_access} a proposito dell'accesso
 concorrente ed in sez.~\ref{sec:file_access_control} per il controllo di
 accesso.
 
-\itindend{file~stream}
-
 Per ragioni storiche la struttura di dati che rappresenta uno \textit{stream}
 è stata chiamata \type{FILE}, questi oggetti sono creati dalle funzioni di
 libreria e contengono tutte le informazioni necessarie a gestire le operazioni
@@ -2472,12 +2466,14 @@ sugli \textit{stream}, come la posizione corrente, lo stato del buffer e degli
 indicatori di stato e di fine del file.
 
 Per questo motivo gli utenti non devono mai utilizzare direttamente o allocare
-queste strutture (che sono dei \index{tipo!opaco} \textsl{tipi opachi}) ma
-usare sempre puntatori del tipo \texttt{FILE *} ottenuti dalla libreria
-stessa, tanto che in certi casi il termine di puntatore a file è diventato
-sinonimo di \textit{stream}.  Tutte le funzioni della libreria che operano sui
-file accettano come argomenti solo variabili di questo tipo, che diventa
-accessibile includendo l'header file \headfile{stdio.h}.
+queste strutture (che sono dei \textsl{tipi opachi}) ma usare sempre puntatori
+del tipo \texttt{FILE *} ottenuti dalla libreria stessa, tanto che in certi
+casi il termine di puntatore a file è diventato sinonimo di \textit{stream}.
+Tutte le funzioni della libreria che operano sui file accettano come argomenti
+solo variabili di questo tipo, che diventa accessibile includendo l'header
+file \headfile{stdio.h}.
+
+\itindend{file~stream}
 
 Ai tre file descriptor standard (vedi tab.~\ref{tab:file_std_files}) aperti
 per ogni processo, corrispondono altrettanti \textit{stream}, che
@@ -2486,18 +2482,18 @@ rappresentano i canali standard di input/output prestabiliti; anche questi tre
 nell'header \headfile{stdio.h} che sono:
 
 \begin{basedescript}{\desclabelwidth{3.0cm}}
-\item[\var{FILE *stdin}] Lo \itindex{standard~input} \textit{standard input}
-  cioè il \textit{file stream} da cui il processo riceve ordinariamente i dati
-  in ingresso. Normalmente è associato dalla shell all'input del terminale e
+\item[\var{FILE *stdin}] Lo \textit{standard input} cioè il \textit{file
+    stream} da cui il processo riceve ordinariamente i dati in
+  ingresso. Normalmente è associato dalla shell all'input del terminale e
   prende i caratteri dalla tastiera.
-\item[\var{FILE *stdout}] Lo \itindex{standard~output} \textit{standard
-    output} cioè il \textit{file 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} \textit{standard error}
-  cioè il \textit{file 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.
+\item[\var{FILE *stdout}] Lo \textit{standard output} cioè il \textit{file
+    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è il \textit{file
+    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}
 
 Nella \acr{glibc} \var{stdin}, \var{stdout} e \var{stderr} sono effettivamente
@@ -2554,25 +2550,24 @@ consapevoli, specie in caso di lettura e scrittura da dispositivi interattivi:
   trasmessi da e verso il file in blocchi di dimensione opportuna.
 \end{itemize}
 
-Lo standard ANSI C specifica inoltre che lo \itindex{standard~output}
-\textit{standard output} e lo \itindex{standard~input} \textit{standard input}
-siano aperti in modalità \textit{fully buffered} quando non fanno riferimento
-ad un dispositivo interattivo, e che lo standard error non sia mai aperto in
-modalità \textit{fully buffered}.
+Lo standard ANSI C specifica inoltre che lo \textit{standard output} e lo
+\textit{standard input} siano aperti in modalità \textit{fully buffered}
+quando non fanno riferimento ad un dispositivo interattivo, e che lo standard
+error non sia mai aperto in modalità \textit{fully buffered}.
 
 Linux, come BSD e SVr4, specifica il comportamento predefinito in maniera
 ancora più precisa, e cioè impone che lo standard error sia sempre
 \textit{unbuffered}, in modo che i messaggi di errore siano mostrati il più
-rapidamente possibile, e che \itindex{standard~input} \textit{standard input}
-e \itindex{standard~output} \textit{standard output} siano aperti in modalità
-\textit{line buffered} quando sono associati ad un terminale (od altro
-dispositivo interattivo) ed in modalità \textit{fully buffered} altrimenti.
+rapidamente possibile, e che \textit{standard input} \textit{standard output}
+siano aperti in modalità \textit{line buffered} quando sono associati ad un
+terminale (od altro dispositivo interattivo) ed in modalità \textit{fully
+  buffered} altrimenti.
 
-Il comportamento specificato per \itindex{standard~input} \textit{standard
-  input} e \itindex{standard~output} \textit{standard output} vale anche per
-tutti i nuovi \textit{stream} aperti da un processo; la selezione comunque
-avviene automaticamente, e la libreria apre lo \textit{stream} nella modalità
-più opportuna a seconda del file o del dispositivo scelto.
+Il comportamento specificato per \textit{standard input} e \textit{standard
+  output} vale anche per tutti i nuovi \textit{stream} aperti da un processo;
+la selezione comunque avviene automaticamente, e la libreria apre lo
+\textit{stream} nella modalità più opportuna a seconda del file o del
+dispositivo scelto.
 
 La modalità \textit{line buffered} è quella che necessita di maggiori
 chiarimenti e attenzioni per quel che concerne il suo funzionamento. Come già
@@ -2655,7 +2650,7 @@ essere aperti con le funzioni delle librerie standard del C.
 %    \hline
     \texttt{w} & Il file viene aperto e troncato a lunghezza nulla (o
                  creato se non esiste), l'accesso viene posto in sola
-                 scrittura, lo stream\textit{} è posizionato all'inizio del
+                 scrittura, lo \textit{stream} è posizionato all'inizio del
                  file.\\ 
     \texttt{w+}& Il file viene aperto e troncato a lunghezza nulla (o
                  creato se non esiste), l'accesso viene posto in scrittura e
@@ -2663,11 +2658,11 @@ essere aperti con le funzioni delle librerie standard del C.
                  file.\\ 
 %    \hline
     \texttt{a} & Il file viene aperto (o creato se non esiste) in
-                 \itindex{append~mode} \textit{append mode}, l'accesso viene
-                 posto in sola scrittura.\\
+                 \textit{append mode}, l'accesso viene posto in sola
+                 scrittura.\\
     \texttt{a+}& Il file viene aperto (o creato se non esiste) in
-                 \itindex{append~mode} \textit{append mode}, l'accesso viene
-                 posto in lettura e scrittura.\\
+                 \textit{append mode}, l'accesso viene posto in lettura e
+                 scrittura.\\
     \hline
     \texttt{b} & Specifica che il file è binario, non ha alcun effetto. \\
     \texttt{x} & L'apertura fallisce se il file esiste già. \\
@@ -2712,11 +2707,11 @@ I nuovi file saranno creati secondo quanto visto in
 sez.~\ref{sec:file_ownership_management} ed avranno i permessi di accesso
 impostati al valore
 \code{S\_IRUSR|S\_IWUSR|S\_IRGRP|S\_IWGRP|S\_IROTH|S\_IWOTH} (pari a
-\val{0666}) modificato secondo il valore della \itindex{umask} \textit{umask}
-per il processo (si veda sez.~\ref{sec:file_perm_management}). Una volta
-aperto lo \textit{stream}, si può cambiare la modalità di bufferizzazione (si
-veda sez.~\ref{sec:file_buffering_ctrl}) fintanto che non si è effettuato
-alcuna operazione di I/O sul file.
+\val{0666}) modificato secondo il valore della \textit{umask} per il processo
+(si veda sez.~\ref{sec:file_perm_management}). Una volta aperto lo
+\textit{stream}, si può cambiare la modalità di bufferizzazione (si veda
+sez.~\ref{sec:file_buffering_ctrl}) fintanto che non si è effettuato alcuna
+operazione di I/O sul file.
 
 In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è
 di mezzo una bufferizzazione; per questo motivo lo standard ANSI C
@@ -3049,8 +3044,8 @@ eventuali differenze.
 
 Le \acr{glibc} definiscono altre due funzioni per l'I/O binario,
 \funcd{fread\_unlocked} e \funcd{fwrite\_unlocked} che evitano il lock
-implicito dello \textit{stream}, usato per dalla librerie per la gestione delle
-applicazioni \itindex{thread} \textit{multi-thread} (si veda
+implicito dello \textit{stream}, usato per dalla librerie per la gestione
+delle applicazioni \textit{multi-thread} (si veda
 sez.~\ref{sec:file_stream_thread} per i dettagli), i loro prototipi sono:
 
 \begin{funcproto}{
@@ -3084,7 +3079,7 @@ rispettivi prototipi sono:
 \fdecl{int fgetc(FILE *stream)}
 \fdesc{Leggono un singolo byte da uno \textit{stream}.} 
 \fdecl{int getchar(void)}
-\fdesc{Legge un byte dallo \itindex{standard~input} \textit{standard input}.} 
+\fdesc{Legge un byte dallo \textit{standard input}.} 
 }
 
 {Le funzioni ritornano il byte letto in caso di successo e \val{EOF} per un
@@ -3129,8 +3124,7 @@ carattere in formato esteso (cioè di tipo \ctyp{wint\_t}), il loro prototipo
 \fdecl{wint\_t fgetwc(FILE *stream)}
 \fdesc{Leggono un carattere da uno \textit{stream}.} 
 \fdecl{wint\_t getwchar(void)}
-\fdesc{Legge un carattere dallo \itindex{standard~input} \textit{standard
-    input}.} 
+\fdesc{Legge un carattere dallo \textit{standard input}.} 
 }
 
 {Le funzioni ritornano il carattere letto in caso di successo e \val{WEOF} per
@@ -3152,8 +3146,7 @@ loro prototipi sono:
 \fdecl{int fputc(int c, FILE *stream)}
 \fdesc{Scrive un byte su uno \textit{stream}.}
 \fdecl{int putchar(int c)}
-\fdesc{Scrive un byte sullo  \itindex{standard~output} \textit{standard
-    output}.}
+\fdesc{Scrive un byte sullo \textit{standard output}.}
 }
 
 {Le funzioni ritornano il valore del byte scritto in caso di successo e
@@ -3257,8 +3250,7 @@ prototipi sono:
 \begin{funcproto}{
 \fhead{stdio.h}
 \fdecl{char *gets(char *string)}
-\fdesc{Legge una linea di testo dallo \itindex{standard~input}
-  \textit{standard input}.}
+\fdesc{Legge una linea di testo dallo \textit{standard input}.}
 \fdecl{char *fgets(char *string, int size, FILE *stream)}
 \fdesc{Legge una linea di testo da uno \textit{stream}.} 
 }
@@ -3268,12 +3260,12 @@ prototipi sono:
 \end{funcproto}
  
 Entrambe le funzioni effettuano la lettura, dal file specificato \func{fgets},
-dallo \itindex{standard~input} \textit{standard input} \func{gets}, di una
-linea di caratteri terminata dal carattere ASCII di \textit{newline}, che come
-detto corrisponde a quello generato dalla pressione del tasto di invio sulla
-tastiera. Si tratta del carattere che indica la terminazione di una riga (in
-sostanza del carattere di ``\textsl{a capo}'') che viene rappresentato nelle
-stringhe di formattazione che vedremo in sez.~\ref{sec:file_formatted_io} come
+dallo \textit{standard input} \func{gets}, di una linea di caratteri terminata
+dal carattere ASCII di \textit{newline}, che come detto corrisponde a quello
+generato dalla pressione del tasto di invio sulla tastiera. Si tratta del
+carattere che indica la terminazione di una riga (in sostanza del carattere di
+``\textsl{a capo}'') che viene rappresentato nelle stringhe di formattazione
+che vedremo in sez.~\ref{sec:file_formatted_io} come
 ``\verb|\n|''. Nell'esecuzione delle funzioni \func{gets} sostituisce
 ``\verb|\n|'' con uno zero, mentre \func{fgets} aggiunge uno zero dopo il
 \textit{newline}, che resta dentro la stringa.
@@ -3313,8 +3305,7 @@ rispettivi prototipi sono:
 \begin{funcproto}{
 \fhead{stdio.h}
 \fdecl{int puts(char *string)}
-\fdesc{Scrive una linea di testo sullo  \itindex{standard~output}
-  \textit{standard output}.}
+\fdesc{Scrive una linea di testo sullo \textit{standard output}.}
 \fdecl{int fputs(char *string, int size, FILE *stream)}
 \fdesc{Scrive una linea di testo su uno \textit{stream}.} 
 }
@@ -3324,15 +3315,14 @@ rispettivi prototipi sono:
 \end{funcproto}
 
 La funzione \func{puts} scrive una linea di testo mantenuta
-all'indirizzo \param{string} sullo \itindex{standard~output} \textit{standard
-  output} mentre \func{puts} la scrive sul file indicato da \param{stream}.
-Dato che in questo caso si scrivono i dati in uscita \func{puts} non ha i
-problemi di \func{gets} ed è in genere la forma più immediata per scrivere
-messaggi sullo \itindex{standard~output} \textit{standard output}; la funzione
-prende una stringa terminata da uno zero ed aggiunge automaticamente il
-ritorno a capo. La differenza con \func{fputs} (a parte la possibilità di
-specificare un file diverso da \var{stdout}) è che quest'ultima non aggiunge
-il \textit{newline}, che deve essere previsto esplicitamente.
+all'indirizzo \param{string} sullo \textit{standard output} mentre \func{puts}
+la scrive sul file indicato da \param{stream}.  Dato che in questo caso si
+scrivono i dati in uscita \func{puts} non ha i problemi di \func{gets} ed è in
+genere la forma più immediata per scrivere messaggi sullo \textit{standard
+  output}; la funzione prende una stringa terminata da uno zero ed aggiunge
+automaticamente il ritorno a capo. La differenza con \func{fputs} (a parte la
+possibilità di specificare un file diverso da \var{stdout}) è che quest'ultima
+non aggiunge il \textit{newline}, che deve essere previsto esplicitamente.
 
 Come per le analoghe funzioni di input/output a caratteri, anche per l'I/O di
 linea esistono delle estensioni per leggere e scrivere linee di caratteri
@@ -3473,8 +3463,7 @@ L'output formattato viene eseguito con una delle 13 funzioni della famiglia
 \begin{funcproto}{
 \fhead{stdio.h} 
 \fdecl{int printf(const char *format, ...)}
-\fdesc{Scrive una stringa formattata sullo \itindex{standard~output}
-  \textit{standard output}.}
+\fdesc{Scrive una stringa formattata sullo \textit{standard output}.}
 \fdecl{int fprintf(FILE *stream, const char *format, ...)}
 \fdesc{Scrive una stringa formattata su uno \textit{stream}.} 
 \fdecl{int sprintf(char *str, const char *format, ...)} 
@@ -3490,14 +3479,13 @@ Le funzioni usano la stringa \param{format} come indicatore del formato con
 cui dovrà essere scritto il contenuto degli argomenti, il cui numero è
 variabile e dipende dal formato stesso.
 
-Le prime due servono per scrivere su file (lo \itindex{standard~output}
-\textit{standard output} o quello specificato) la terza permette di scrivere
-su una stringa, in genere l'uso di \func{sprintf} è sconsigliato in quanto è
-possibile, se non si ha la sicurezza assoluta sulle dimensioni del risultato
-della stampa, eccedere le dimensioni di \param{str}, con conseguente
-sovrascrittura di altre variabili e possibili \textit{buffer overflow}. Per
-questo motivo si consiglia l'uso dell'alternativa \funcd{snprintf}, il cui
-prototipo è:
+Le prime due servono per scrivere su file (lo \textit{standard output} o
+quello specificato) la terza permette di scrivere su una stringa, in genere
+l'uso di \func{sprintf} è sconsigliato in quanto è possibile, se non si ha la
+sicurezza assoluta sulle dimensioni del risultato della stampa, eccedere le
+dimensioni di \param{str}, con conseguente sovrascrittura di altre variabili e
+possibili \textit{buffer overflow}. Per questo motivo si consiglia l'uso
+dell'alternativa \funcd{snprintf}, il cui prototipo è:
 
 \begin{funcproto}{
 \fhead{stdio.h}
@@ -3660,8 +3648,7 @@ sez.~\ref{sec:proc_variadic}), sono \funcd{vprintf}, \funcd{vfprintf} e
 \begin{funcproto}{
 \fhead{stdio.h}
 \fdecl{int vprintf(const char *format, va\_list ap)}
-\fdesc{Scrive una stringa formattata sullo \itindex{standard~output}
-  \textit{standard output}.} 
+\fdesc{Scrive una stringa formattata sullo \textit{standard output}.} 
 \fdecl{int vfprintf(FILE *stream, const char *format, va\_list ap)}
 \fdesc{Scrive una stringa formattata su uno \textit{stream}.}
 \fdecl{int vsprintf(char *str, const char *format, va\_list ap)}
@@ -3740,8 +3727,7 @@ famiglia \func{scanf}; fra queste le tre più importanti sono \funcd{scanf},
 \begin{funcproto}{
 \fhead{stdio.h}
 \fdecl{int scanf(const char *format, ...)}
-\fdesc{Esegue la scansione di dati dallo \itindex{standard~input}
-  \textit{standard input}.}
+\fdesc{Esegue la scansione di dati dallo \textit{standard input}.}
 \fdecl{int fscanf(FILE *stream, const char *format, ...)}
 \fdesc{Esegue la scansione di dati da uno \textit{stream}. } 
 \fdecl{int sscanf(char *str, const char *format, ...)}
@@ -3812,7 +3798,7 @@ In questa sezione esamineremo alcune funzioni avanzate che permettono di
 eseguire operazioni di basso livello nella gestione degli \textit{stream},
 come leggerne gli attributi, controllarne le modalità di bufferizzazione,
 gestire in maniera esplicita i lock impliciti presenti ad uso della
-programmazione \itindex{thread} \textit{multi-thread}.
+programmazione \textit{multi-thread}.
 
 
 \subsection{Le funzioni di controllo}
@@ -4105,7 +4091,7 @@ Ci sono comunque situazioni in cui questo non basta, come quando un
 \textit{stream} atomicamente. Per questo motivo le librerie provvedono anche
 le funzioni \funcd{flockfile} e \funcd{funlockfile} che permettono la gestione
 esplicita dei blocchi sugli \textit{stream}. Esse sono disponibili definendo
-\macro{\_POSIX\_THREAD\_SAFE\_FUNCTIONS} ed i loro prototipi sono:
+\macrod{\_POSIX\_THREAD\_SAFE\_FUNCTIONS} ed i loro prototipi sono:
 
 \begin{funcproto}{
 \fhead{stdio.h}
index 2157e74..28f81d6 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -927,7 +927,7 @@ Per questo motivo tutte le funzioni di libreria di solito non fanno
 riferimento ai tipi elementari dello standard del linguaggio C, ma ad una
 serie di \index{tipo!primitivo} \textsl{tipi primitivi} del sistema, riportati
 in tab.~\ref{tab:intro_primitive_types}, e definiti nell'\textit{header file}
-\headfile{sys/types.h}, in modo da mantenere completamente indipendenti i tipi
+\headfiled{sys/types.h}, in modo da mantenere completamente indipendenti i tipi
 utilizzati dalle funzioni di sistema dai tipi elementari supportati dal
 compilatore C.
 
@@ -1375,7 +1375,7 @@ in essi definite, sono illustrate nel seguente elenco:
   \macro{\_XOPEN\_SOURCE\_EXTENDED} e \macro{\_XOPEN\_SOURCE} con valore 600
   (o 500 per le versioni della \acr{glibc} precedenti la 2.2); oltre a queste
   vengono pure attivate le ulteriori due macro \macro{\_ATFILE\_SOURCE} e
-  \macro{\_LARGEFILE64\_SOURCE} che definiscono funzioni previste
+  \macrod{\_LARGEFILE64\_SOURCE} che definiscono funzioni previste
   esclusivamente dalla \acr{glibc}.
  
 \end{basedescript}
diff --git a/ipc.tex b/ipc.tex
index 6f5f8cb..01c4c5b 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -946,7 +946,7 @@ mantiene varie proprietà ed informazioni associate all'oggetto.
   \end{minipage} 
   \normalsize 
   \caption{La struttura \structd{ipc\_perm}, come definita in
-    \headfile{sys/ipc.h}.}
+    \headfiled{sys/ipc.h}.}
   \label{fig:ipc_ipc_perm}
 \end{figure}
 
@@ -1342,7 +1342,7 @@ adeguata i principi di funzionamento delle code di messaggi.
 
 A ciascuna coda è associata una struttura \struct{msqid\_ds} la cui
 definizione è riportata in fig.~\ref{fig:ipc_msqid_ds} ed a cui si accede
-includendo  \headfile{sys/msg.h};
+includendo \headfiled{sys/msg.h};
 %
 % INFO: sotto materiale obsoleto e non interessante
 % In questa struttura il
@@ -4566,7 +4566,7 @@ 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 almeno 600 o la macro \macro{\_POSIX\_C\_SOURCE} ad un valore
 uguale o maggiore di \texttt{200112L} prima di includere
-\headfile{semaphore.h}, la funzione è \funcd{sem\_timedwait}, ed il suo
+\headfiled{semaphore.h}, la funzione è \funcd{sem\_timedwait}, ed il suo
 prototipo è:
 
 \begin{funcproto}{
index 1561d44..67b8525 100644 (file)
--- a/macro.tex
+++ b/macro.tex
 \newcommand{\ctyp}[1]{\texttt{#1}}    % C standard type
 
 \newcommand{\headfile}[1]{%
-%\index{file!include!{#1}@{{\tt {#1}}}}\texttt{#1}%
+%\index{file!include!menzione{#1}@{{\tt {#1}}}}\texttt{#1}%
 \texttt{#1}%
 }                                     % header file name
 
+\newcommand{\headfiled}[1]{%
+\index{file!include!{#1}@{{\tt {#1}}}}\texttt{#1}%
+}                                     % header file name
+
 \newcommand{\procfile}[1]{%
 \index{file!filesystem~\texttt{/proc}!{#1}@{{\tt {#1}}}}\texttt{#1}%
 %\index{#1@{{\tt {#1}} (direttiva)}}\texttt{#1}%
 }                                     % /proc file name
+\newcommand{\procfilem}[1]{%
+\texttt{#1}%
+%\index{file!filesystem~\texttt{/proc}!{#1}@{{\tt {#1}}}}\texttt{#1}%
+%\index{#1@{{\tt {#1}} (direttiva)}}\texttt{#1}%
+}                                     % /proc file name
 \newcommand{\sysfile}[1]{%
 \index{file!di~sistema!{#1}@{{\tt {#1}}}}\texttt{#1}%
 %\index{#1@{{\tt {#1}} (direttiva)}}\texttt{#1}%
 %\index{#1@{{\tt {#1}} (tipo)}}\texttt{#1}%
 }                                     % system type
 \newcommand{\struct}[1]{%
-\index{struttura dati!{#1}@{{\tt {#1}}}}\texttt{#1}%
+\texttt{#1}%
+%\index{struttura dati!{#1}@{{\tt {#1}}}}\texttt{#1}%
 %\index{#1@{{\tt {#1}} (struttura dati)}}\texttt{#1}%
 }                                     % struttura dati
 \newcommand{\structd}[1]{%
-\index{struttura dati!{#1}@{{\tt {#1}}}!definizione di}\texttt{#1}%
-%\index{#1@{{\tt {#1}} (struttura dati)}!definizione di}\texttt{#1}%
+\index{struttura dati!{#1}@{{\tt {#1}}}}\texttt{#1}%
+%\index{struttura dati!{#1}@{{\tt {#1}}}!definizione di}\texttt{#1}%
 }                                     % struttura dati
 \newcommand{\param}[1]{\texttt{#1}}   % function parameter
 \newcommand{\acr}[1]{\textsl{#1}}     % acrostic (for glibc, ext2, ecc.)
index 9e8d27c..a7d778b 100644 (file)
@@ -148,8 +148,8 @@ dispiegamenti di reti di varie dimensioni a seconda delle diverse esigenze.
 
 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 è
-riservata per usi sperimentali e non viene impiegata.
+destinata al \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
@@ -158,8 +158,8 @@ classe A occorre passare a una classe B, che ne prevede 65536,\footnote{in
   realtà i valori esatti sarebbero 254 e 65534, 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
-conseguente spreco di numeri.
+  uno per l'indirizzo di \textit{broadcast}.} con un conseguente spreco di
+numeri.
 
 Inoltre, in particolare per le reti di classe C, la presenza di tanti
 indirizzi di rete diversi comporta una crescita enorme delle tabelle di
@@ -447,8 +447,7 @@ grandi linee nei seguenti punti:
   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}
+  si aggiungono agli usuali \textit{unicast} e \textit{multicast}
 \item la semplificazione del formato dell'intestazione, eliminando o rendendo
   opzionali alcuni dei campi di IPv4, per eliminare la necessità di
   riprocessare la stessa da parte dei router e contenere l'aumento di
@@ -602,9 +601,8 @@ 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
-  applicazioni che lo usano dovono essere reimplementate usando il
-  \itindex{multicast} \textit{multicasting} (vedi
+\item il \textit{broadcasting} non è previsto in IPv6, le applicazioni che lo
+  usano dovono essere reimplementate usando il \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
@@ -707,8 +705,8 @@ può usare la vecchia notazione con i punti, per esempio
 \label{sec:IP_ipv6_addr_arch}
 
 Come per IPv4 gli indirizzi sono identificatori per una singola (indirizzi
-\textit{unicast}) o per un insieme (indirizzi \itindex{multicast}
-\textit{multicast} e \textit{anycast}) di interfacce di rete.
+\textit{unicast}) o per un insieme (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ò
@@ -716,21 +714,19 @@ essere identificato attraverso uno qualunque degli indirizzi unicast delle sue
 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
-\itindex{broadcast} \textit{broadcast}, la funzione di questi ultimi deve
-essere reimplementata con gli indirizzi \itindex{multicast}
-\textit{multicast}.
+\textit{unicast} e \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 \textit{broadcast}, la funzione di questi
+ultimi deve essere reimplementata con gli indirizzi \textit{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
 (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.
+\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
 di indirizzo; in tab.~\ref{tab:IP_ipv6addr} sono riportati i valori di detti
@@ -738,10 +734,9 @@ 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
-per usi futuri.
+per i provider, per uso locale e per il \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
 tab.~\ref{tab:IP_ipv6addr} in quanto allocati al di fuori dello spazio di
@@ -1132,9 +1127,9 @@ già riservati per il funzionamento della rete.
 \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
-esempio inviando un pacchetto all'indirizzo \texttt{FF02:0:0:0:0:0:0:1} si
-raggiungono tutti i nodi locali).
+a recuperare le funzionalità del \textit{broadcasting} (ad esempio inviando un
+pacchetto all'indirizzo \texttt{FF02:0:0:0:0:0:0:1} si raggiungono tutti i
+nodi locali).
 
 \itindend{multicast}
 
@@ -1523,13 +1518,13 @@ 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
-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
+iniziano si devono aggregare al gruppo di \textit{multicast}
+\textit{all-nodes} programmando la propria interfaccia per ricevere i messaggi
+dall'indirizzo \textit{multicast} \texttt{FF02::1} (vedi
 sez.~\ref{sec:IP_ipv6_multicast}); a questo punto devono inviare un messaggio
 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.
+\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
index 490112b..2e1d070 100644 (file)
@@ -516,9 +516,9 @@ seguenti:
   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
-  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.
+  reti di tipo \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
   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
index b25c658..4364288 100644 (file)
@@ -213,27 +213,28 @@ definizioni.
     & ANSI C& POSIX& \\
     \hline
     \hline
-    \headfile{assert.h}&$\bullet$&    --   & Verifica le asserzioni fatte in un
-                                             programma.\\ 
-    \headfile{ctype.h} &$\bullet$&    --   & Tipi standard.\\
-    \headfile{dirent.h}&   --    &$\bullet$& Manipolazione delle directory.\\
-    \headfile{errno.h} &   --    &$\bullet$& Errori di sistema.\\
-    \headfile{fcntl.h} &   --    &$\bullet$& Controllo sulle opzioni dei file.\\
-    \headfile{limits.h}&   --    &$\bullet$& Limiti e parametri del sistema.\\
-    \headfile{malloc.h}&$\bullet$&    --   & Allocazione della memoria.\\
-    \headfile{setjmp.h}&$\bullet$&    --   & Salti non locali.\\
-    \headfile{signal.h}&   --    &$\bullet$& Gestione dei segnali.\\
-    \headfile{stdarg.h}&$\bullet$&    --   & Gestione di funzioni a argomenti
+    \headfiled{assert.h}&$\bullet$&    --   & Verifica le asserzioni fatte in un
+                                              programma.\\ 
+    \headfiled{ctype.h} &$\bullet$&    --   & Tipi standard.\\
+    \headfiled{dirent.h}&   --    &$\bullet$& Manipolazione delle directory.\\
+    \headfiled{errno.h} &   --    &$\bullet$& Errori di sistema.\\
+    \headfiled{fcntl.h} &   --    &$\bullet$& Controllo sulle opzioni dei
+                                              file.\\ 
+    \headfiled{limits.h}&   --    &$\bullet$& Limiti e parametri del sistema.\\
+    \headfiled{malloc.h}&$\bullet$&    --   & Allocazione della memoria.\\
+    \headfiled{setjmp.h}&$\bullet$&    --   & Salti non locali.\\
+    \headfiled{signal.h}&   --    &$\bullet$& Gestione dei segnali.\\
+    \headfiled{stdarg.h}&$\bullet$&    --   & Gestione di funzioni a argomenti
                                              variabili.\\ 
-    \headfile{stdio.h} &$\bullet$&    --   & I/O bufferizzato in standard ANSI
-                                             C.\\ 
-    \headfile{stdlib.h}&$\bullet$&    --   & Definizioni della libreria
-                                             standard.\\ 
-    \headfile{string.h}&$\bullet$&    --   & Manipolazione delle stringhe.\\
-    \headfile{time.h}  &   --    &$\bullet$& Gestione dei tempi.\\
-    \headfile{times.h} &$\bullet$&    --   & Gestione dei tempi.\\
-    \headfile{unistd.h}&   --    &$\bullet$& Unix standard library.\\
-    \headfile{utmp.h}  &   --    &$\bullet$& Registro connessioni utenti.\\
+    \headfiled{stdio.h} &$\bullet$&    --   & I/O bufferizzato in standard ANSI
+                                              C.\\ 
+    \headfiled{stdlib.h}&$\bullet$&    --   & Definizioni della libreria
+                                              standard.\\ 
+    \headfiled{string.h}&$\bullet$&    --   & Manipolazione delle stringhe.\\
+    \headfiled{time.h}  &   --    &$\bullet$& Gestione dei tempi.\\
+    \headfiled{times.h} &$\bullet$&    --   & Gestione dei tempi.\\
+    \headfiled{unistd.h}&   --    &$\bullet$& Unix standard library.\\
+    \headfiled{utmp.h}  &   --    &$\bullet$& Registro connessioni utenti.\\
     \hline
   \end{tabular}
   \caption{Elenco dei principali \textit{header file} definiti dagli standard
@@ -273,7 +274,7 @@ esempio si avrà che:
   ``\texttt{TC}'' e con ``\texttt{B}'' seguito da un numero,
 \item in \headfile{grp.h} vengono riservati i nomi che iniziano con
   ``\texttt{gr\_}'',
-\item in \headfile{pwd.h}vengono riservati i nomi che iniziano con
+\item in \headfile{pwd.h} vengono riservati i nomi che iniziano con
   ``\texttt{pw\_}'',
 \end{itemize*}
 
@@ -352,7 +353,7 @@ dall'architettura,\footnote{in genere le vecchie \textit{system call} non
 ciascuna \textit{system call} viene in genere identificata da una costante
 nella forma \texttt{SYS\_*} dove al prefisso viene aggiunto il nome che spesso
 corrisponde anche alla omonima funzione di libreria. Queste costanti sono
-definite nel file \headfile{sys/syscall.h}, ma si possono anche usare
+definite nel file \headfiled{sys/syscall.h}, ma si possono anche usare
 direttamente valori numerici.
 
 
index b6bb0bb..df3eadc 100644 (file)
@@ -139,7 +139,7 @@ questa tabella, costituita da una struttura \kstruct{task\_struct}, che
 contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture
 usate a questo scopo sono dichiarate nell'\textit{header file}
 \file{linux/sched.h}, ed uno schema semplificato, che riporta la struttura
-delle principali informazioni contenute nella \struct{task\_struct} (che in
+delle principali informazioni contenute nella \texttt{task\_struct} (che in
 seguito incontreremo a più riprese), è mostrato in
 fig.~\ref{fig:proc_task_struct}.
 
@@ -2576,7 +2576,7 @@ La funzione permette, a seconda di quanto specificato
 nell'argomento \param{which}, di leggere il valore di \textit{nice} di un
 processo, di un gruppo di processi (vedi sez.~\ref{sec:sess_proc_group}) o di
 un utente indicato dall'argomento \param{who}. Nelle vecchie versioni può
-essere necessario includere anche \headfile{sys/time.h}, questo non è più
+essere necessario includere anche \headfiled{sys/time.h}, questo non è più
 necessario con versioni recenti delle librerie, ma è comunque utile per
 portabilità.
 
@@ -2962,7 +2962,7 @@ politica ordinaria essa ha senso soltanto per quelli \textit{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 \macrod{\_POSIX\_PRIORITY\_SCHEDULING} che è definita
-nell'\textit{header file} \headfile{sched.h}.
+nell'\textit{header file} \headfiled{sched.h}.
 
 Se invece si vuole sapere quale è politica di \textit{scheduling} di un
 processo si può usare la funzione di sistema \funcd{sched\_getscheduler}, il
@@ -4077,7 +4077,7 @@ visto in sez.~\ref{sec:proc_syscall}.\footnote{ed inoltre per questa
     \item[\errcode{EINVAL}] si è usata una combinazione non valida di flag o
       un valore nullo per \param{child\_stack}.
     \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare una nuova
-      \struct{task\_struct} o per copiare le parti del contesto del chiamante
+      \texttt{task\_struct} o per copiare le parti del contesto del chiamante
       necessarie al nuovo \textit{task}.
     \item[\errcode{EPERM}] non si hanno i privilegi di amministratore
       richiesti dai flag indicati.
index dbe5ae3..06ba55f 100644 (file)
@@ -275,7 +275,7 @@ 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 \headfile{resolv.h} ed
+usata da tutte queste funzioni. Essa viene definita in \headfiled{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:
@@ -453,8 +453,8 @@ tab.~\ref{tab:DNS_address_class}.\footnote{esisteva in realtà anche una classe
 
 Come accennato le tipologie di dati che sono mantenibili su un server DNS sono
 diverse, ed a ciascuna di essa corrisponde un diverso tipo di \textit{resource
-  record}. L'elenco delle costanti\footnote{ripreso dai file di dichiarazione
-  \headfile{arpa/nameser.h} e \headfile{arpa/nameser\_compat.h}.} che
+  record}. L'elenco delle costantiripreso dai file di dichiarazione
+  \headfiled{arpa/nameser.h} e \headfiled{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
 tab.~\ref{tab:DNS_record_type}; le costanti (tolto il \texttt{T\_} iniziale)
@@ -1280,15 +1280,16 @@ strutture di tipo \struct{addrinfo} contenenti tutte le informazioni ottenute.
   \label{fig:sock_addrinfo_struct}
 \end{figure}
 
-Come illustrato la struttura \struct{addrinfo}, la cui definizione\footnote{la
-  definizione è ripresa direttamente dal file \headfile{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
-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
+Come illustrato la struttura \struct{addrinfo}, la cui definizione è 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. La definizione è ripresa direttamente dal file \headfiled{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.
+
+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
@@ -2054,8 +2055,7 @@ tab.~\ref{tab:sock_opt_socklevel}.
     \const{SO\_DONTROUTE}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}& 
                           Non invia attraverso un gateway.\\
     \const{SO\_BROADCAST}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}& 
-                          Attiva o disattiva il \itindex{broadcast}
-                          \textit{broadcast}.\\ 
+                          Attiva o disattiva il \textit{broadcast}.\\ 
     \const{SO\_SNDBUF}   &$\bullet$&$\bullet$&         &\texttt{int}& 
                           Imposta dimensione del buffer di trasmissione.\\
     \const{SO\_RCVBUF}   &$\bullet$&$\bullet$&         &\texttt{int}& 
@@ -2247,12 +2247,12 @@ tab.~\ref{tab:sock_opt_socklevel} sul significato delle varie opzioni:
   di routing del kernel. Prende per \param{optval} un intero usato come valore
   logico.
 
-\item[\const{SO\_BROADCAST}] questa opzione abilita il \itindex{broadcast}
-  \textit{broadcast}; quanto abilitata i socket di tipo \const{SOCK\_DGRAM}
-  riceveranno i pacchetti inviati all'indirizzo di \textit{broadcast}, e
-  potranno scrivere pacchetti su tale indirizzo.  Prende per \param{optval} un
-  intero usato come valore logico. L'opzione non ha effetti su un socket di
-  tipo \const{SOCK\_STREAM}.
+\item[\const{SO\_BROADCAST}] questa opzione abilita il \textit{broadcast};
+  quanto abilitata i socket di tipo \const{SOCK\_DGRAM} riceveranno i
+  pacchetti inviati all'indirizzo di \textit{broadcast}, e potranno scrivere
+  pacchetti su tale indirizzo.  Prende per \param{optval} un intero usato come
+  valore logico. L'opzione non ha effetti su un socket di tipo
+  \const{SOCK\_STREAM}.
 
 \item[\const{SO\_SNDBUF}] questa opzione imposta la dimensione del buffer di
   trasmissione del socket. Prende per \param{optval} un intero indicante il
@@ -2742,7 +2742,7 @@ socket che usano il protocollo IPv4.\footnote{come per le precedenti opzioni
 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 \headfile{netinet/ip.h}, ed accessibili includendo detto
+sono definite in \headfiled{netinet/ip.h}, ed accessibili includendo detto
 file.
 
 \begin{table}[!htb]
@@ -3107,7 +3107,7 @@ 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
-\headfile{netinet/tcp.h}, ed accessibili includendo detto file.\footnote{in
+\headfiled{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{include/linux/tcp.h} dei sorgenti del kernel, dal quale si sono
@@ -3488,7 +3488,7 @@ 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
 \const{IPPROTO\_UDP}).  Le costanti che identificano dette opzioni sono
-definite in \headfile{netinet/udp.h}, ed accessibili includendo detto
+definite in \headfiled{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{include/linux/udp.h}, dal quale si sono estratte le costanti di
@@ -3685,7 +3685,7 @@ Le costanti che identificano le operazioni disponibili sono le seguenti:
     \hline
     \const{IFF\_UP}        & L'interfaccia è attiva.\\
     \const{IFF\_BROADCAST} & L'interfaccia ha impostato un indirizzo di
-                             \itindex{broadcast} \textit{broadcast} valido.\\
+                             \textit{broadcast} valido.\\
     \const{IFF\_DEBUG}     & È attivo il flag interno di debug.\\
     \const{IFF\_LOOPBACK}  & L'interfaccia è una interfaccia di
                              \textit{loopback}.\\ 
@@ -3762,8 +3762,8 @@ Le costanti che identificano le operazioni disponibili sono le seguenti:
   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.
+  hardware dell'interfaccia al valore specificato dal 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
index 30412e0..3c8dfa7 100644 (file)
@@ -251,7 +251,7 @@ valori numerici.\footnote{in Linux, come si può verificare andando a guardare
 seguendo la convenzione usata nelle pagine di manuale.
 
 I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
-indirizzi, sono definiti dall'\textit{header file} \headfile{socket.h}. Un
+indirizzi, sono definiti dall'\textit{header file} \headfiled{socket.h}. Un
 elenco delle famiglie di protocolli disponibili in Linux è riportato in
 tab.~\ref{tab:net_pf_names}. L'elenco indica tutti i protocolli definiti; fra
 questi però saranno utilizzabili solo quelli per i quali si è compilato il
@@ -482,7 +482,7 @@ sarebbe più immediato per l'utente (che non dovrebbe più eseguire il casting),
 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
-\headfile{netinet/in.h} ed ha la forma mostrata in
+\headfiled{netinet/in.h} ed ha la forma mostrata in
 fig.~\ref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
 
 \begin{figure}[!htb]
@@ -585,7 +585,7 @@ fig.~\ref{fig:sock_sa_local_struct}.
   \end{minipage} 
   \caption{La struttura \structd{sockaddr\_un} degli indirizzi dei socket
     locali (detti anche \textit{unix domain}) definita in
-    \headfile{sys/un.h}.}
+    \headfiled{sys/un.h}.}
   \label{fig:sock_sa_local_struct}
 \end{figure}
 
@@ -620,7 +620,7 @@ per \param{protocol} è \const{ATPROTO\_DDP}.
 Gli indirizzi AppleTalk devono essere specificati tramite una struttura
 \struct{sockaddr\_atalk}, la cui definizione è riportata in
 fig.~\ref{fig:sock_sa_atalk_struct}; la struttura viene dichiarata includendo
-il file \headfile{netatalk/at.h}.
+il file \headfiled{netatalk/at.h}.
 
 \begin{figure}[!htb]
   \footnotesize \centering
index ce09475..0318925 100644 (file)
@@ -113,7 +113,7 @@ da \headfile{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 \headfile{float.h}. 
+accessibili includendo \headfiled{float.h}. 
 
 \begin{table}[htb]
   \centering
@@ -754,7 +754,7 @@ utenti (che nelle versioni più recenti per la parte di credenziali di
 autenticazione vengono ottenute attraverso PAM) relative all'utente
 specificato attraverso il suo \ids{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 \headfile{pwd.h}) è riportata in
+la cui definizione (anch'essa eseguita in \headfiled{pwd.h}) è riportata in
 fig.~\ref{fig:sys_passwd_struct}, dove è pure brevemente illustrato il
 significato dei vari campi.
 
@@ -1002,7 +1002,7 @@ registro alternativo, sia \func{setutent} che \func{endutent} operano usando
 il default che è \sysfile{/var/run/utmp} il cui nome, 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
-\headfile{paths.h}, in particolare quelle che ci interessano sono:
+\headfiled{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
@@ -1180,7 +1180,7 @@ altri sistemi (ad esempio Solaris e NetBSD), per mantenere una coerenza con le
 altre funzioni definite nello standard che usano la struttura \struct{utmpx}
 la \acr{glibc} definisce anche una funzione \funcm{updwtmpx}, che come in
 precedenza è identica a \func{updwtmp} con la sola differenza di richiedere
-l'uso di \headfile{utmpx.h} e di una struttura \struct{utmpx} come secondo
+l'uso di \headfiled{utmpx.h} e di una struttura \struct{utmpx} come secondo
 argomento. 
 
 
@@ -1430,9 +1430,9 @@ vincoli e limiti di utilizzo.
 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
 di tipo \struct{rusage}, la cui definizione (che si trova in
-\headfile{sys/resource.h}) è riportata in fig.~\ref{fig:sys_rusage_struct}. Si
-ricordi che questa è una delle informazioni preservate attraverso una
-\func{exec}.
+\headfiled{sys/resource.h}) è riportata in
+fig.~\ref{fig:sys_rusage_struct}. Si ricordi che questa è una delle
+informazioni preservate attraverso una \func{exec}.
 
 \begin{figure}[!htb]
   \footnotesize
@@ -2527,7 +2527,7 @@ delle costanti elencate in tab.~\ref{tab:adjtimex_return}.
 \end{table}
 
 La funzione richiede come argomento il puntatore ad una struttura di tipo
-\struct{timex}, la cui definizione, effettuata in \headfile{sys/timex.h}, è
+\struct{timex}, la cui definizione, effettuata in \headfiled{sys/timex.h}, è
 riportata in fig.~\ref{fig:sys_timex_struct} per i campi che interessano la
 possibilità di essere modificati documentati anche nella pagina di manuale. In
 realtà la struttura è stata estesa con ulteriori campi, i cui valori sono
@@ -2806,7 +2806,7 @@ delle precedenti funzioni di conversione, ma lo si può fare esplicitamente
 chiamando direttamente la funzione \funcd{tzset}, il cui prototipo è:
 
 \begin{funcproto}{
-\fhead{sys/timex.h}
+\fhead{time.h}
 \fdecl{void tzset(void)} 
 \fdesc{Imposta le variabili globali della \textit{timezone}.} 
 }
index b07e6fd..e1390a1 100644 (file)
@@ -577,7 +577,7 @@ 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,
 indica il valore generico, e corrisponde al valore \const{INADDR\_ANY}
-definito in \headfile{arpa/inet.h} (vedi \ref{tab:TCP_ipv4_addr}).
+definito in \headfiled{arpa/inet.h} (vedi \ref{tab:TCP_ipv4_addr}).
 
 Inoltre si noti come la porta e l'indirizzo di ogni eventuale connessione
 esterna non sono specificati; in questo caso la \textit{socket pair} associata
@@ -743,8 +743,7 @@ sempre la funzione \func{htonl}.
     \hline
     \hline
     \const{INADDR\_ANY}      & Indirizzo generico (\texttt{0.0.0.0})\\
-    \const{INADDR\_BROADCAST}& Indirizzo di \itindex{broadcast}
-                               \textit{broadcast}.\\ 
+    \const{INADDR\_BROADCAST}& Indirizzo di \textit{broadcast}.\\ 
     \const{INADDR\_LOOPBACK} & Indirizzo di \textit{loopback}
                                (\texttt{127.0.0.1}).\\ 
     \const{INADDR\_NONE}     & Indirizzo errato.\\
@@ -805,9 +804,8 @@ connessione con un server TCP,\footnote{di nuovo la funzione è generica e
   \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
-    connessione ad un indirizzo \itindex{broadcast} \textit{broadcast} senza
-    che il socket fosse stato abilitato per il \itindex{broadcast}
-    \textit{broadcast}.
+    connessione ad un indirizzo \textit{broadcast} senza che il socket fosse
+    stato abilitato per il \textit{broadcast}.
   \end{errlist}
   altri errori possibili sono: \errval{EFAULT}, \errval{EBADF},
   \errval{ENOTSOCK}, \errval{EISCONN} e \errval{EADDRINUSE}.}