Prosegue la risistemazione degli indici. Trattata CLONE_FS.
authorSimone Piccardi <piccardi@gnulinux.it>
Sat, 10 Oct 2015 12:24:01 +0000 (12:24 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sat, 10 Oct 2015 12:24:01 +0000 (12:24 +0000)
15 files changed:
errors.tex
fileadv.tex
filedir.tex
fileio.tex
intro.tex
ipc.tex
othersock.tex
process.tex
prochand.tex
session.tex
signal.tex
sockctrl.tex
socket.tex
system.tex
tcpsock.tex

index 1f7a3caff805bdd40b4bb61b6d22557b4d335ba8..57bf5a2dcb8fc6930919ef295e8537c5b0dfe107 100644 (file)
 
 Si riportano in questa appendice tutti i codici di errore. Essi sono
 accessibili attraverso l'inclusione del file di header \headfile{errno.h}, che
-definisce anche la \index{variabili!globali} variabile globale
-\var{errno}. Per ogni errore definito riporteremo la stringa stampata da
-\func{perror} ed una breve spiegazione. Si tenga presente che spiegazioni più
-particolareggiate del significato dell'errore, qualora necessarie per casi
-specifici, possono essere trovate nella descrizione del prototipo della
-funzione per cui detto errore si è verificato.
+definisce anche la variabile globale \var{errno}. Per ogni errore definito
+riporteremo la stringa stampata da \func{perror} ed una breve spiegazione. Si
+tenga presente che spiegazioni più particolareggiate del significato
+dell'errore, qualora necessarie per casi specifici, possono essere trovate
+nella descrizione del prototipo della funzione per cui detto errore si è
+verificato.
 
 I codici di errore sono riportati come costanti di tipo \ctyp{int}, i valori
 delle costanti sono definiti da macro di preprocessore nel file citato, e
@@ -273,13 +273,12 @@ specificati nelle sezioni precedenti.
 \item[\errcode{ENOMEM} \textit{No memory available}.] Il kernel non è in grado
   di allocare ulteriore memoria per completare l'operazione richiesta.
 \item[\errcode{EDEADLK} \textit{Deadlock avoided}.] L'allocazione di una
-  risorsa avrebbe causato un \itindex{deadlock} \textit{deadlock}. Non sempre
-  il sistema è in grado di riconoscere queste situazioni, nel qual caso si
-  avrebbe il blocco.
+  risorsa avrebbe causato un \textit{deadlock}. Non sempre il sistema è in
+  grado di riconoscere queste situazioni, nel qual caso si avrebbe il blocco.
 \item[\errcode{EFAULT} \textit{Bad address}.] Una stringa passata come
   argomento è fuori dello spazio di indirizzi del processo, in genere questa
-  situazione provoca direttamente l'emissione di un segnale di
-  \itindex{segment~violation} \textit{segment violation} (\signal{SIGSEGV}).
+  situazione provoca direttamente l'emissione di un segnale di \textit{segment
+    violation} (\signal{SIGSEGV}).
 \item[\errcode{EINVAL} \textit{Invalid argument}.] Errore utilizzato per
   segnalare vari tipi di problemi dovuti all'aver passato un argomento
   sbagliato ad una funzione di libreria.
index 688fab8da124d145e7cfe801500da2848ac30366..600808fa322d34650b99b2023c498075c9767564 100644 (file)
@@ -762,10 +762,10 @@ Si tenga inoltre presente che deallocare la memoria indirizzata da
 operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
 campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
 richiesta. Questo comporta che non si devono usare per \param{aiocbp}
-\index{variabili!automatiche} variabili automatiche e che non si deve
-riutilizzare la stessa struttura per un'altra operazione fintanto che la
-precedente non sia stata ultimata. In generale per ogni operazione si deve
-utilizzare una diversa struttura \struct{aiocb}.
+variabili automatiche e che non si deve riutilizzare la stessa struttura per
+un'altra operazione fintanto che la precedente non sia stata ultimata. In
+generale per ogni operazione si deve utilizzare una diversa struttura
+\struct{aiocb}.
 
 Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
 \func{aio\_write} non implica che le operazioni siano state effettivamente
index 37ca3b647e17385c6c54a6e0324bfb3a89dd5f80..dea3f7fcfbcf5b9816129c2f9a206131fb0280df 100644 (file)
@@ -758,8 +758,8 @@ con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente:
   e \param{data} vengono ignorati.
 
   In sostanza quello che avviene è che in corrispondenza del \textit{pathname}
-  indicato da \param{target} viene montato \itindex{inode} l'\textit{inode}
-  di \param{source}, così che la porzione di albero dei file presente sotto
+  indicato da \param{target} viene montato l'\textit{inode} di \param{source},
+  così che la porzione di albero dei file presente sotto
   \param{source} diventi visibile allo stesso modo sotto
   \param{target}. Trattandosi esattamente dei dati dello stesso filesystem,
   ogni modifica fatta in uno qualunque dei due rami di albero sarà visibile
@@ -769,9 +769,9 @@ con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente:
   Dal punto di vista del VFS l'operazione è analoga al montaggio di un
   filesystem proprio nel fatto che anche in questo caso si inserisce in
   corrispondenza della \textit{dentry} di \texttt{target} un diverso
-  \itindex{inode} \textit{inode}, che stavolta, invece di essere quello della
-  radice del filesystem indicato da un file di dispositivo, è quello di una
-  directory già montata.
+  \textit{inode}, che stavolta, invece di essere quello della radice del
+  filesystem indicato da un file di dispositivo, è quello di una directory già
+  montata.
 
   Si tenga presente che proprio per questo sotto \param{target} comparirà il
   contenuto che è presente sotto \param{source} all'interno del filesystem in
@@ -856,9 +856,8 @@ con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente:
   di dispositivo eventualmente presenti su di esso. L'opzione viene usata come
   misura di precauzione per rendere inutile la presenza di eventuali file di
   dispositivo su filesystem che non dovrebbero contenerne.\footnote{si ricordi
-    che le convenzioni del \itindex{Filesystem~Hierarchy~Standard~(FHS)}
-    \textit{Linux Filesystem Hierarchy Standard} richiedono che questi siano
-    mantenuti esclusivamente sotto \texttt{/dev}.}
+    che le convenzioni del \textit{Linux Filesystem Hierarchy Standard}
+    richiedono che questi siano mantenuti esclusivamente sotto \texttt{/dev}.}
 
   Viene utilizzata, assieme a \const{MS\_NOEXEC} e \const{MS\_NOSUID}, per
   fornire un accesso più controllato a quei filesystem di cui gli utenti hanno
@@ -1284,6 +1283,7 @@ trattazione, di queste funzioni, rimandando al manuale della \acr{glibc}
 % TODO (bassa priorità) documentare ? swapon e swapoff (man 2 ...) 
 
 
+
 \section{La gestione di file e directory}
 \label{sec:file_dir}
 
@@ -1297,7 +1297,6 @@ directory di lavoro e le funzioni per la gestione di file speciali e
 temporanei.
 
 
-
 \subsection{La gestione dei nomi dei file}
 \label{sec:link_symlink_rename}
 
@@ -2014,10 +2013,9 @@ sez.~\ref{sec:files_std_interface}. La prima funzione di questa interfaccia è
 
 La funzione apre un \textit{directory stream} per la directory
 \param{dirname}, ritornando il puntatore ad un oggetto di tipo \type{DIR} (che
-è il \index{tipo!opaco} tipo opaco usato dalle librerie per gestire i
-\textit{directory stream}) da usare per tutte le operazioni successive, la
-funzione inoltre posiziona lo \textit{stream} sulla prima voce contenuta nella
-directory.
+è il tipo opaco usato dalle librerie per gestire i \textit{directory stream})
+da usare per tutte le operazioni successive, la funzione inoltre posiziona lo
+\textit{stream} sulla prima voce contenuta nella directory.
 
 Si tenga presente che comunque la funzione opera associando il
 \textit{directory stream} ad un opportuno file descriptor sottostante, sul
@@ -2059,8 +2057,7 @@ La funzione restituisce il file descriptor associato al \textit{directory
   stream} \param{dir}. Di solito si utilizza questa funzione in abbinamento a
 funzioni che operano sui file descriptor, ad esempio si potrà usare
 \func{fstat} per ottenere le proprietà della directory, o \func{fchdir} per
-spostare su di essa la directory di lavoro (vedi
-sez.~\ref{sec:file_work_dir}).
+spostare su di essa la directory di lavoro (vedi sez.~\ref{sec:file_work_dir}).
 
 Viceversa se si è aperto un file descriptor corrispondente ad una directory è
 possibile associarvi un \textit{directory stream} con la funzione
@@ -2151,12 +2148,12 @@ prototipo è:
   \func{readdir}.} 
 \end{funcproto}
 
-La funzione restituisce in \param{result} come \itindex{value~result~argument}
-\textit{value result argument} l'indirizzo della struttura \struct{dirent}
-dove sono stati salvati i dati, che deve essere allocata dal chiamante, ed il
-cui indirizzo deve essere indicato con l'argomento \param{entry}.  Se si è
-raggiunta la fine del \textit{directory stream} invece in \param{result} viene
-restituito il valore \val{NULL}.
+La funzione restituisce in \param{result} come \textit{value result argument}
+l'indirizzo della struttura \struct{dirent} dove sono stati salvati i dati,
+che deve essere allocata dal chiamante, ed il cui indirizzo deve essere
+indicato con l'argomento \param{entry}.  Se si è raggiunta la fine del
+\textit{directory stream} invece in \param{result} viene restituito il valore
+\val{NULL}.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -2380,10 +2377,10 @@ restituendo un valore positivo, nullo o negativo per indicarne l'ordinamento;
 alla fine l'indirizzo della lista ordinata dei puntatori alle strutture
 \struct{dirent} viene restituito nell'argomento
 \param{namelist}.\footnote{la funzione alloca automaticamente la lista, e
-  restituisce, come \itindex{value~result~argument} \textit{value result
-    argument}, l'indirizzo della stessa; questo significa che \param{namelist}
-  deve essere dichiarato come \code{struct dirent **namelist} ed alla funzione
-  si deve passare il suo indirizzo.}
+  restituisce, come \textit{value result argument}, l'indirizzo della stessa;
+  questo significa che \param{namelist} deve essere dichiarato come
+  \code{struct dirent **namelist} ed alla funzione si deve passare il suo
+  indirizzo.}
 
 \itindend{directory~stream}
 
@@ -2756,10 +2753,9 @@ serie 2.4 alla serie 2.6 è stata aumentata a 32 bit la dimensione del tipo
 \type{dev\_t}, con delle dimensioni passate a 12 bit per il
 \itindex{major~number} \textit{major number} e 20 bit per il
 \itindex{minor~number} \textit{minor number}. La transizione però ha
-comportato il fatto che \type{dev\_t} è diventato un \index{tipo!opaco} tipo
-opaco, e la necessità di specificare il numero tramite delle opportune macro,
-così da non avere problemi di compatibilità con eventuali ulteriori
-estensioni.
+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
@@ -4190,14 +4186,14 @@ memoria virtuale e l'accesso ai file erano molto meno sofisticati e per
 ottenere la massima velocità possibile per i programmi usati più comunemente
 si poteva impostare questo bit.
 
-L'effetto di questo bit era che il \index{segmento!testo} segmento di testo
-del programma (si veda sez.~\ref{sec:proc_mem_layout} per i dettagli) veniva
-scritto nella swap la prima volta che questo veniva lanciato, e vi permaneva
-fino al riavvio della macchina (da questo il nome di \textsl{sticky bit});
-essendo la swap un file continuo o una partizione indicizzata direttamente si
-poteva risparmiare in tempo di caricamento rispetto alla ricerca attraverso la
-struttura del filesystem. Lo \textsl{sticky bit} è indicato usando la lettera
-``\texttt{t}'' al posto della ``\texttt{x}'' nei permessi per gli altri.
+L'effetto di questo bit era che il segmento di testo del programma (si veda
+sez.~\ref{sec:proc_mem_layout} per i dettagli) veniva scritto nella swap la
+prima volta che questo veniva lanciato, e vi permaneva fino al riavvio della
+macchina (da questo il nome di \textsl{sticky bit}); essendo la swap un file
+continuo o una partizione indicizzata direttamente si poteva risparmiare in
+tempo di caricamento rispetto alla ricerca attraverso la struttura del
+filesystem. Lo \textsl{sticky bit} è indicato usando la lettera ``\texttt{t}''
+al posto della ``\texttt{x}'' nei permessi per gli altri.
 
 Ovviamente per evitare che gli utenti potessero intasare la swap solo
 l'amministratore era in grado di impostare questo bit, che venne chiamato
@@ -5363,16 +5359,16 @@ voci. La funzione ritorna un valore di tipo \type{acl\_t} da usare in tutte le
 altre funzioni che operano sulla ACL. La funzione si limita alla allocazione
 iniziale e non inserisce nessun valore nella ACL che resta vuota. 
 
-Si tenga presente che pur essendo \type{acl\_t} un \index{tipo!opaco} tipo
-opaco che identifica ``\textsl{l'oggetto}'' ACL, il valore restituito dalla
-funzione non è altro che un puntatore all'area di memoria allocata per i dati
-richiesti. Pertanto in caso di fallimento verrà restituito un puntatore nullo
-di tipo ``\code{(acl\_t) NULL}'' e si dovrà, in questa come in tutte le
-funzioni seguenti che restituiscono un oggetto di tipo \type{acl\_t},
-confrontare il valore di ritorno della funzione con \val{NULL}.\footnote{a
-  voler essere estremamente pignoli si dovrebbe usare ``\code{(acl\_t)
-    NULL}'', ma è sufficiente fare un confronto direttamente con \val{NULL}
-  essendo cura del compilatore fare le conversioni necessarie.}
+Si tenga presente che pur essendo \type{acl\_t} un tipo opaco che identifica
+``\textsl{l'oggetto}'' ACL, il valore restituito dalla funzione non è altro
+che un puntatore all'area di memoria allocata per i dati richiesti. Pertanto
+in caso di fallimento verrà restituito un puntatore nullo di tipo
+``\code{(acl\_t) NULL}'' e si dovrà, in questa come in tutte le funzioni
+seguenti che restituiscono un oggetto di tipo \type{acl\_t}, confrontare il
+valore di ritorno della funzione con \val{NULL}.\footnote{a voler essere
+  estremamente pignoli si dovrebbe usare ``\code{(acl\_t) NULL}'', ma è
+  sufficiente fare un confronto direttamente con \val{NULL} essendo cura del
+  compilatore fare le conversioni necessarie.}
 
 Una volta che si siano completate le operazioni sui dati di una ACL la memoria
 allocata per un oggetto \type{acl\_t} dovrà essere liberata esplicitamente
@@ -5622,9 +5618,9 @@ contenente la rappresentazione in forma estesa della ACL passata come
 argomento, ed alloca automaticamente la memoria necessaria. Questa dovrà poi
 essere liberata, quando non più necessaria, con \func{acl\_free}. Se
 nell'argomento \param{len\_p} si passa un valore puntatore ad una variabile
-intera in questa verrà restituita (come \itindex{value~result~argument}
-\textit{value result argument}) la dimensione della stringa con la
-rappresentazione testuale, non comprendente il carattere nullo finale.
+intera in questa verrà restituita (come \textit{value result argument}) la
+dimensione della stringa con la rappresentazione testuale, non comprendente il
+carattere nullo finale.
 
 La seconda funzione, che permette di controllare con una gran dovizia di
 particolari la generazione della stringa contenente la rappresentazione
@@ -6864,8 +6860,7 @@ opportuno dettagliare maggiormente.
 % Linux specific capabilities
 %
 \hline
-    \const{CAP\_IPC\_LOCK}  & Effettuare il \textit{memory
-                              locking} \itindex{memory~locking} con le
+    \const{CAP\_IPC\_LOCK}  & Effettuare il \textit{memory locking} con le
                               funzioni \func{mlock}, \func{mlockall},
                               \func{shmctl}, \func{mmap} (vedi
                               sez.~\ref{sec:proc_mem_lock} e 
@@ -6875,8 +6870,7 @@ opportuno dettagliare maggiormente.
                               per le operazioni sugli oggetti di
                               intercomunicazione fra processi (vedi
                               sez.~\ref{sec:ipc_sysv}).\\  
-    \const{CAP\_LEASE}      & Creare dei \textit{file lease}
-                              \itindex{file~lease} (vedi
+    \const{CAP\_LEASE}      & Creare dei \textit{file lease} (vedi
                               sez.~\ref{sec:file_asyncronous_lease})
                               pur non essendo proprietari del file (dal kernel
                               2.4).\\ 
@@ -7135,8 +7129,8 @@ della suddetta libreria attraverso l'opzione \texttt{-lcap}.
 \itindbeg{capability~state}
 
 Le funzioni dell'interfaccia alle \textit{capabilities} definite nelle bozze
-dello standard POSIX.1e prevedono l'uso di un \index{tipo!opaco} tipo di dato
-opaco, \type{cap\_t}, come puntatore ai dati mantenuti nel cosiddetto
+dello standard POSIX.1e prevedono l'uso di un tipo di dato opaco,
+\type{cap\_t}, come puntatore ai dati mantenuti nel cosiddetto
 \textit{capability state},\footnote{si tratta in sostanza di un puntatore ad
   una struttura interna utilizzata dalle librerie, i cui campi non devono mai
   essere acceduti direttamente.} in sono memorizzati tutti i dati delle
@@ -7383,9 +7377,8 @@ tab.~\ref{tab:cap_value_type}.
 
 La funzione \func{cap\_get\_flag} legge lo stato della capacità indicata
 dall'argomento \param{cap} all'interno dell'insieme indicato dall'argomento
-\param{flag} e lo restituisce come \itindex{value~result~argument}
-\textit{value result argument} nella variabile puntata
-dall'argomento \param{value\_p}. Questa deve essere di tipo
+\param{flag} e lo restituisce come \textit{value result argument} nella
+variabile puntata dall'argomento \param{value\_p}. Questa deve essere di tipo
 \type{cap\_flag\_value\_t} ed assumerà uno dei valori di
 tab.~\ref{tab:cap_value_type}. La funzione consente pertanto di leggere solo
 lo stato di una capacità alla volta.
@@ -7421,10 +7414,10 @@ testuale, è \funcd{cap\_to\_text}, il cui prototipo è:
 La funzione ritorna l'indirizzo di una stringa contente la descrizione
 testuale del contenuto del \textit{capability state} \param{caps} passato come
 argomento, e, qualora l'argomento \param{length\_p} sia diverso da \val{NULL},
-restituisce come \itindex{value~result~argument} \textit{value result
-  argument} nella variabile intera da questo puntata la lunghezza della
-stringa. La stringa restituita viene allocata automaticamente dalla funzione e
-pertanto dovrà essere liberata con \func{cap\_free}.
+restituisce come \textit{value result argument} nella variabile intera da
+questo puntata la lunghezza della stringa. La stringa restituita viene
+allocata automaticamente dalla funzione e pertanto dovrà essere liberata con
+\func{cap\_free}.
 
 La rappresentazione testuale, che viene usata anche dai programmi di gestione a
 riga di comando, prevede che lo stato venga rappresentato con una stringa di
@@ -7523,9 +7516,8 @@ Linux ed i rispettivi prototipi sono:
 La prima funzione restituisce la stringa (allocata automaticamente e che dovrà
 essere liberata con \func{cap\_free}) che corrisponde al valore della
 capacità \param{cap}, mentre la seconda restituisce nella variabile puntata
-da \param{cap\_p}, come \itindex{value~result~argument} \textit{value result
-  argument}, il valore della capacità rappresentata dalla
-stringa \param{name}.
+da \param{cap\_p}, come \textit{value result argument}, il valore della
+capacità rappresentata dalla stringa \param{name}.
 
 Fin quei abbiamo trattato solo le funzioni di servizio relative alla
 manipolazione dei \textit{capability state} come strutture di dati;
index 77769ece37748d09c809388d4df7af03f8be0e41..c5f805e9da412961fcf45878acc9347cd0cfd8b5 100644 (file)
@@ -3291,11 +3291,11 @@ adiacente al buffer.\footnote{questa tecnica è spiegata in dettaglio e con
 Questa è una delle vulnerabilità più sfruttate per guadagnare accessi non
 autorizzati al sistema (i cosiddetti \textit{exploit}), basta infatti inviare
 una stringa sufficientemente lunga ed opportunamente forgiata per
-sovrascrivere gli indirizzi di ritorno nello \itindex{stack} \textit{stack}
-(supposto che la \func{gets} sia stata chiamata da una subroutine), in modo da
-far ripartire l'esecuzione nel codice inviato nella stringa stessa, che in
-genere contiene uno \textit{shell code}, cioè una sezione di programma che
-lancia una shell da cui si potranno poi eseguire altri programmi.
+sovrascrivere gli indirizzi di ritorno nello \textit{stack} (supposto che la
+\func{gets} sia stata chiamata da una subroutine), in modo da far ripartire
+l'esecuzione nel codice inviato nella stringa stessa, che in genere contiene
+uno \textit{shell code}, cioè una sezione di programma che lancia una shell da
+cui si potranno poi eseguire altri programmi.
 
 La funzione \func{fgets} non ha i precedenti problemi di \func{gets} in quanto
 prende in ingresso la dimensione del buffer \param{size}, che non verrà mai
@@ -3415,10 +3415,9 @@ dimensioni del buffer suddetto.
 Se il buffer di destinazione è sufficientemente ampio la stringa viene scritta
 subito, altrimenti il buffer viene allargato usando \func{realloc} e la nuova
 dimensione ed il nuovo puntatore vengono restituiti indietro, si noti infatti
-come entrambi gli argomenti siano dei \itindex{value~result~argument}
-\textit{value result argument}, per i quali vengono passati dei puntatori
-anziché i valori delle variabili, secondo quanto abbiamo descritto in
-sez.~\ref{sec:proc_var_passing}).
+come entrambi gli argomenti siano dei \textit{value result argument}, per i
+quali vengono passati dei puntatori anziché i valori delle variabili, secondo
+quanto abbiamo descritto in sez.~\ref{sec:proc_var_passing}).
 
 Se si passa alla funzione l'indirizzo di un puntatore impostato a \val{NULL} e
 \var{*n} è zero, la funzione provvede da sola all'allocazione della memoria
@@ -3426,9 +3425,8 @@ necessaria a contenere la linea. In tutti i casi si ottiene dalla funzione un
 puntatore all'inizio del testo della linea letta. Un esempio di codice può
 essere il seguente: 
 \includecodesnip{listati/getline.c} 
-e per evitare \itindex{memory~leak} \textit{memory leak} occorre ricordarsi di
-liberare la memoria allocata dalla funzione eseguendo una \func{free} su
-\var{ptr}.
+e per evitare \textit{memory leak} occorre ricordarsi di liberare la memoria
+allocata dalla funzione eseguendo una \func{free} su \var{ptr}.
 
 Il valore di ritorno di \func{getline} indica il numero di caratteri letti
 dallo \textit{stream}, quindi compreso il \textit{newline}, ma non lo zero di
@@ -3490,8 +3488,8 @@ L'output formattato viene eseguito con una delle 13 funzioni della famiglia
 
 
 Le funzioni usano la stringa \param{format} come indicatore del formato con
-cui dovrà essere scritto il contenuto degli argomenti, il cui numero
-\index{funzioni!variadic} è variabile e dipende dal formato stesso.
+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
@@ -3563,12 +3561,12 @@ non possa essere sovrascritto.
 La parte più complessa delle funzioni di scrittura formattata è il formato
 della stringa \param{format} che indica le conversioni da fare, e da cui
 deriva anche il numero degli argomenti che dovranno essere passati a seguire:
-si noti come tutte queste funzioni siano \index{funzioni!variadic}
-\textit{variadic}, prendendo un numero di argomenti variabile che dipende
-appunto da quello che si è specificato in \param{format}.
+si noti come tutte queste funzioni siano ``\textit{variadic}'', prendendo un
+numero di argomenti variabile che dipende appunto da quello che si è
+specificato in \param{format}.
 
 La stringa di formato è costituita da caratteri normali (tutti eccetto
-``\texttt{\%}''), che vengono passati invariati all'output, e da direttive di
+``\texttt{\%}''), che vengono passati invariati in uscita, e da direttive di
 conversione, in cui devono essere sempre presenti il carattere
 ``\texttt{\%}'', che introduce la direttiva, ed uno degli specificatori di
 conversione (riportati in tab.~\ref{tab:file_format_spec}) che la conclude.
@@ -3644,11 +3642,11 @@ dettagliate dei vari formati possono essere trovati nella pagina di manuale di
     \cmd{L}  & Una conversione in virgola mobile corrisponde a un
                \ctyp{double}.\\
     \cmd{q}  & Sinonimo di \cmd{ll}.\\
-    \cmd{j}  & Una conversione intera corrisponde a un \type{intmax\_t} o 
-               \type{uintmax\_t}.\\
-    \cmd{z}  & Una conversione intera corrisponde a un \type{size\_t} o 
-               \type{ssize\_t}.\\
-    \cmd{t}  & Una conversione intera corrisponde a un \type{ptrdiff\_t}.\\
+    \cmd{j}  & Una conversione intera corrisponde a un \ctyp{intmax\_t} o 
+               \ctyp{uintmax\_t}.\\
+    \cmd{z}  & Una conversione intera corrisponde a un \ctyp{size\_t} o 
+               \ctyp{ssize\_t}.\\
+    \cmd{t}  & Una conversione intera corrisponde a un \ctyp{ptrdiff\_t}.\\
     \hline
   \end{tabular}
   \caption{Il modificatore di tipo di dato per il formato di \func{printf}}
@@ -3678,11 +3676,10 @@ sez.~\ref{sec:proc_variadic}), sono \funcd{vprintf}, \funcd{vfprintf} e
 Con queste funzioni diventa possibile selezionare gli argomenti che si
 vogliono passare ad una funzione di stampa, passando direttamente la lista
 tramite l'argomento \param{ap}. Per poter far questo ovviamente la lista
-variabile\index{funzioni!variadic} degli argomenti dovrà essere opportunamente
-trattata (l'argomento è esaminato in sez.~\ref{sec:proc_variadic}), e dopo
-l'esecuzione della funzione l'argomento
-\param{ap} non sarà più utilizzabile (in generale dovrebbe essere eseguito un
-\code{va\_end(ap)} ma in Linux questo non è necessario). 
+variabile degli argomenti dovrà essere opportunamente trattata (l'argomento è
+esaminato in sez.~\ref{sec:proc_variadic}), e dopo l'esecuzione della funzione
+l'argomento \param{ap} non sarà più utilizzabile (in generale dovrebbe essere
+eseguito un \code{va\_end(ap)} ma in Linux questo non è necessario).
 
 Come per \func{sprintf} anche per \func{vsprintf} esiste una analoga
 \funcd{vsnprintf} che pone un limite sul numero di caratteri che vengono
@@ -3722,11 +3719,10 @@ sono:
 Entrambe le funzioni prendono come argomento \param{strptr} che deve essere
 l'indirizzo di un puntatore ad una stringa di caratteri, in cui verrà
 restituito (si ricordi quanto detto in sez.~\ref{sec:proc_var_passing} a
-proposito dei \itindex{value~result~argument} \textit{value result argument})
-l'indirizzo della stringa allocata automaticamente dalle funzioni. Occorre
-inoltre ricordarsi di invocare \func{free} per liberare detto puntatore quando
-la stringa non serve più, onde evitare \itindex{memory~leak} \textit{memory
-  leak}.
+proposito dei \textit{value result argument}) l'indirizzo della stringa
+allocata automaticamente dalle funzioni. Occorre inoltre ricordarsi di
+invocare \func{free} per liberare detto puntatore quando la stringa non serve
+più, onde evitare \textit{memory leak}.
 
 % TODO verificare se mettere prototipi di \func{dprintf} e \func{vdprintf}
 
@@ -3955,12 +3951,12 @@ Ovviamente se si usa un buffer specificato dall'utente questo deve essere
 stato allocato e rimanere disponibile per tutto il tempo in cui si opera sullo
 \textit{stream}. In genere conviene allocarlo con \func{malloc} e disallocarlo
 dopo la chiusura del file; ma fintanto che il file è usato all'interno di una
-funzione, può anche essere usata una \index{variabili!automatiche} variabile
-automatica. In \headfile{stdio.h} è definita la macro \const{BUFSIZ}, che
-indica le dimensioni generiche del buffer di uno \textit{stream}, queste
-vengono usate dalla funzione \func{setbuf}.  Non è detto però che tale
-dimensione corrisponda sempre al valore ottimale (che può variare a seconda
-del dispositivo).
+funzione, può anche essere usata una variabile automatica. In
+\headfile{stdio.h} è definita la macro \const{BUFSIZ}, che indica le
+dimensioni generiche del buffer di uno \textit{stream}, queste vengono usate
+dalla funzione \func{setbuf}.  Non è detto però che tale dimensione
+corrisponda sempre al valore ottimale (che può variare a seconda del
+dispositivo).
 
 Dato che la procedura di allocazione manuale è macchinosa, comporta dei
 rischi, come delle scritture accidentali sul buffer, e non assicura la scelta
index dd52cd084f27b608f5b455cda8d6abd4c4e3da3e..cebf4811e237b1be07cadf2cd8628539227c898b 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -1394,7 +1394,7 @@ una opportuna macro; queste estensioni sono illustrate nel seguente elenco:
   presente negli standard con i file di grandi dimensioni, ed in particolare
   definire le due funzioni \func{fseeko} e \func{ftello} che al contrario
   delle corrispettive \func{fseek} e \func{ftell} usano il tipo di dato
-  specifico \type{off\_t} (vedi sez.~\ref{sec:file_io}).
+  specifico \ctyp{off\_t} (vedi sez.~\ref{sec:file_io}).
 
 \item[\macro{\_LARGEFILE64\_SOURCE}] definendo questa macro si rendono
   disponibili le funzioni di una interfaccia alternativa al supporto di valori
diff --git a/ipc.tex b/ipc.tex
index 35095a445dd71e487e2f049d3fa23b9fa40f9f0c..f742380f1de5a128c6759d1051e09fc497e9c83c 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -1844,14 +1844,13 @@ successivo potrebbe ricevere un messaggio non indirizzato a lui.
 I semafori non sono propriamente meccanismi di intercomunicazione come
 \textit{pipe}, \textit{fifo} e code di messaggi, poiché non consentono di
 scambiare dati fra processi, ma servono piuttosto come meccanismi di
-sincronizzazione o di protezione per le \index{sezione~critica}
-\textsl{sezioni critiche} del codice (si ricordi quanto detto in
-sez.~\ref{sec:proc_race_cond}).  Un semaforo infatti non è altro che un
-contatore mantenuto nel kernel che determina se consentire o meno la
-prosecuzione dell'esecuzione di un programma. In questo modo si può
-controllare l'accesso ad una risorsa condivisa da più processi, associandovi
-un semaforo che assicuri che non possa essere usata da più di un processo alla
-volta.
+sincronizzazione o di protezione per le \textsl{sezioni critiche} del codice
+(si ricordi quanto detto in sez.~\ref{sec:proc_race_cond}).  Un semaforo
+infatti non è altro che un contatore mantenuto nel kernel che determina se
+consentire o meno la prosecuzione dell'esecuzione di un programma. In questo
+modo si può controllare l'accesso ad una risorsa condivisa da più processi,
+associandovi un semaforo che assicuri che non possa essere usata da più di un
+processo alla volta.
 
 Il concetto di semaforo è uno dei concetti base nella programmazione ed è
 assolutamente generico, così come del tutto generali sono modalità con cui lo
@@ -2585,12 +2584,12 @@ di gestione del segmento di memoria condivisa in relazione al sistema della
 memoria virtuale.
 
 Il primo dei due flag è \const{SHM\_HUGETLB} che consente di richiedere la
-creazione del segmento usando una \itindex{huge~page} \textit{huge page}, le
-pagine di memoria di grandi dimensioni introdotte con il kernel 2.6 per
-ottimizzare le prestazioni nei sistemi più recenti che hanno grandi quantità
-di memoria. L'operazione è privilegiata e richiede che il processo abbia la
-\textit{capability} \const{CAP\_IPC\_LOCK}. Questa funzionalità è specifica di
-Linux e non è portabile.
+creazione del segmento usando una \textit{huge page}, le pagine di memoria di
+grandi dimensioni introdotte con il kernel 2.6 per ottimizzare le prestazioni
+nei sistemi più recenti che hanno grandi quantità di memoria. L'operazione è
+privilegiata e richiede che il processo abbia la \textit{capability}
+\const{CAP\_IPC\_LOCK}. Questa funzionalità è specifica di Linux e non è
+portabile.
 
 Il secondo flag aggiuntivo, introdotto a partire dal kernel 2.6.15, è
 \const{SHM\_NORESERVE}, ed ha lo stesso scopo del flag \const{MAP\_NORESERVE}
@@ -2772,19 +2771,18 @@ consentono di estendere le funzionalità, ovviamente non devono essere usati se
 si ha a cuore la portabilità. Questi comandi aggiuntivi sono:
 
 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\const{SHM\_LOCK}] Abilita il \itindex{memory~locking} \textit{memory
-    locking} sul segmento di memoria condivisa, impedendo che la memoria usata
-  per il segmento venga salvata su disco dal meccanismo della memoria
-  virtuale. Come illustrato in sez.~\ref{sec:proc_mem_lock} fino al kernel
-  2.6.9 solo l'amministratore poteva utilizzare questa capacità,\footnote{che
-    richiedeva la \textit{capability} \const{CAP\_IPC\_LOCK}.} a partire dal
-  dal kernel 2.6.10 anche gli utenti normali possono farlo fino al limite
-  massimo determinato da \const{RLIMIT\_MEMLOCK} (vedi
+\item[\const{SHM\_LOCK}] Abilita il \textit{memory locking} sul segmento di
+  memoria condivisa, impedendo che la memoria usata per il segmento venga
+  salvata su disco dal meccanismo della memoria virtuale. Come illustrato in
+  sez.~\ref{sec:proc_mem_lock} fino al kernel 2.6.9 solo l'amministratore
+  poteva utilizzare questa capacità,\footnote{che richiedeva la
+    \textit{capability} \const{CAP\_IPC\_LOCK}.} a partire dal dal kernel
+  2.6.10 anche gli utenti normali possono farlo fino al limite massimo
+  determinato da \const{RLIMIT\_MEMLOCK} (vedi
   sez.~\ref{sec:sys_resource_limit}).
-\item[\const{SHM\_UNLOCK}] Disabilita il \itindex{memory~locking}
-  \textit{memory locking} sul segmento di memoria condivisa.  Fino al kernel
-  2.6.9 solo l'amministratore poteva utilizzare questo comando in
-  corrispondenza di un segmento da lui bloccato. 
+\item[\const{SHM\_UNLOCK}] Disabilita il \textit{memory locking} sul segmento
+  di memoria condivisa.  Fino al kernel 2.6.9 solo l'amministratore poteva
+  utilizzare questo comando in corrispondenza di un segmento da lui bloccato.
 \end{basedescript}
 
 A questi due, come per \func{msgctl} e \func{semctl}, si aggiungono tre
@@ -2815,7 +2813,7 @@ il suo prototipo è:
 }
 
 {La funzione ritorna l'indirizzo del segmento in caso di successo e $-1$ (in
-  un cast a \type{void *}) per un errore, nel qual caso \var{errno} assumerà
+  un cast a \ctyp{void *}) per un errore, nel qual caso \var{errno} assumerà
   uno dei valori:
   \begin{errlist}
     \item[\errcode{EACCES}] il processo non ha i privilegi per accedere al
@@ -2880,12 +2878,12 @@ indirizzo come arrotondamento.
 
 L'uso di \const{SHM\_RDONLY} permette di agganciare il segmento in sola
 lettura (si ricordi che anche le pagine di memoria hanno dei permessi), in tal
-caso un tentativo di scrivere sul segmento comporterà una
-\itindex{segment~violation} violazione di accesso con l'emissione di un
-segnale di \signal{SIGSEGV}. Il comportamento usuale di \func{shmat} è quello
-di agganciare il segmento con l'accesso in lettura e scrittura (ed il processo
-deve aver questi permessi in \var{shm\_perm}), non è prevista la possibilità
-di agganciare un segmento in sola scrittura.
+caso un tentativo di scrivere sul segmento comporterà una violazione di
+accesso con l'emissione di un segnale di \signal{SIGSEGV}. Il comportamento
+usuale di \func{shmat} è quello di agganciare il segmento con l'accesso in
+lettura e scrittura (ed il processo deve aver questi permessi in
+\var{shm\_perm}), non è prevista la possibilità di agganciare un segmento in
+sola scrittura.
 
 Infine \const{SHM\_REMAP} è una estensione specifica di Linux (quindi non
 portabile) che indica che la mappatura del segmento deve rimpiazzare ogni
@@ -3034,10 +3032,10 @@ ricavare la parte di informazione che interessa.
 
 In fig.~\ref{fig:ipc_dirmonitor_main} si è riportata la sezione principale del
 corpo del programma server, insieme alle definizioni delle altre funzioni
-usate nel programma e delle \index{variabili!globali} variabili globali,
-omettendo tutto quello che riguarda la gestione delle opzioni e la stampa
-delle istruzioni di uso a video; al solito il codice completo si trova con i
-sorgenti allegati nel file \file{DirMonitor.c}.
+usate nel programma e delle variabili globali, omettendo tutto quello che
+riguarda la gestione delle opzioni e la stampa delle istruzioni di uso a
+video; al solito il codice completo si trova con i sorgenti allegati nel file
+\file{DirMonitor.c}.
 
 \begin{figure}[!htbp]
   \footnotesize \centering
@@ -3049,11 +3047,11 @@ sorgenti allegati nel file \file{DirMonitor.c}.
   \label{fig:ipc_dirmonitor_main}
 \end{figure}
 
-Il programma usa delle \index{variabili!globali} variabili globali
-(\texttt{\small 2-14}) per mantenere i valori relativi agli oggetti usati per
-la comunicazione inter-processo; si è definita inoltre una apposita struttura
-\struct{DirProp} che contiene i dati relativi alle proprietà che si vogliono
-mantenere nella memoria condivisa, per l'accesso da parte dei client.
+Il programma usa delle variabili globali (\texttt{\small 2-14}) per mantenere
+i valori relativi agli oggetti usati per la comunicazione inter-processo; si è
+definita inoltre una apposita struttura \struct{DirProp} che contiene i dati
+relativi alle proprietà che si vogliono mantenere nella memoria condivisa, per
+l'accesso da parte dei client.
 
 Il programma, dopo la sezione, omessa, relativa alla gestione delle opzioni da
 riga di comando (che si limitano alla eventuale stampa di un messaggio di
@@ -3131,11 +3129,11 @@ esse la funzione \func{ComputeValues}, che esegue tutti i calcoli necessari.
 
 
 Il codice di quest'ultima è riportato in fig.~\ref{fig:ipc_dirmonitor_sub}.
-Come si vede la funzione (\texttt{\small 2-16}) è molto semplice e si limita
-chiamare (\texttt{\small 5}) la funzione \func{stat} sul file indicato da
+Come si vede la funzione (\texttt{\small 2-16}) è molto semplice e si limita a
+chiamare (\texttt{\small 5}) la funzione \func{stat} sul file indicato da
 ciascuna voce, per ottenerne i dati, che poi utilizza per incrementare i vari
-contatori nella memoria condivisa, cui accede grazie alla
-\index{variabili!globali} variabile globale \var{shmptr}.
+contatori nella memoria condivisa, cui accede grazie alla variabile globale
+\var{shmptr}.
 
 Dato che la funzione è chiamata da \myfunc{dir\_scan}, si è all'interno del
 ciclo principale del programma, con un mutex acquisito, perciò non è
@@ -4761,12 +4759,11 @@ il semaforo deve essere utilizzato dai \itindex{thread} \textit{thread} di uno
 stesso processo (con un valore nullo) o condiviso fra processi diversi (con un
 valore non nullo).
 
-Qualora il semaforo debba essere condiviso dai \itindex{thread}
-\textit{thread} di uno stesso processo (nel qual caso si parla di
-\textit{thread-shared semaphore}), occorrerà che \param{sem} sia l'indirizzo
-di una variabile visibile da tutti i \itindex{thread} \textit{thread}, si
-dovrà usare cioè una \index{variabili!globali} variabile globale o una
-variabile allocata dinamicamente nello \itindex{heap} \textit{heap}.
+Qualora il semaforo debba essere condiviso dai \textit{thread} di uno stesso
+processo (nel qual caso si parla di \textit{thread-shared semaphore}),
+occorrerà che \param{sem} sia l'indirizzo di una variabile visibile da tutti i
+\textit{thread}, si dovrà usare cioè una variabile globale o una variabile
+allocata dinamicamente nello \textit{heap}.
 
 Qualora il semaforo debba essere condiviso fra più processi (nel qual caso si
 parla di \textit{process-shared semaphore}) la sola scelta possibile per
@@ -4847,9 +4844,9 @@ dall'altro programma prima di averla finita di stampare.
 
 La parte iniziale del programma contiene le definizioni (\texttt{\small 1-8})
 del gestore del segnale usato per liberare le risorse utilizzate, delle
-\index{variabili!globali} variabili globali contenenti i nomi di default del
-segmento di memoria condivisa e del semaforo (il default scelto è
-\texttt{messages}), e delle altre variabili utilizzate dal programma.
+variabili globali contenenti i nomi di default del segmento di memoria
+condivisa e del semaforo (il default scelto è \texttt{messages}), e delle
+altre variabili utilizzate dal programma.
 
 Come prima istruzione (\texttt{\small 10}) si è provveduto ad installare un
 gestore di segnale che consentirà di effettuare le operazioni di pulizia
index 29086d1586a4bb37441260726af063977b7539cd..2474abeda4ce0d219bf06d5988949703363eb06f 100644 (file)
@@ -277,9 +277,9 @@ dell'indirizzo.\footnote{si ricordi che \ctyp{sockaddr} è un tipo generico che
   \param{from} e se è insufficiente l'indirizzo risulterà corrotto.}  Al
 ritorno della funzione si otterranno i dati dell'indirizzo e la sua effettiva
 lunghezza, (si noti che \param{fromlen} è un valore intero ottenuto come
-\itindex{value~result~argument} \textit{value result argument}).  Se non si è
-interessati a questa informazione, entrambi gli argomenti devono essere
-inizializzati al valore \val{NULL}.
+\textit{value result argument}).  Se non si è interessati a questa
+informazione, entrambi gli argomenti devono essere inizializzati al valore
+\val{NULL}.
 
 Una differenza fondamentale del comportamento di queste funzioni rispetto alle
 usuali \func{read} e \func{write} che abbiamo usato con i socket TCP è che in
index 6a37bb0968d2f534ac0571099399027f159732ff..be725cdfa077dceb0143a4e0b48c180415233a1d 100644 (file)
@@ -35,15 +35,15 @@ ciascun processo vedrà la sua copia del codice (in realtà il kernel fa sì che
 tutte le parti uguali siano condivise), avrà un suo spazio di indirizzi,
 variabili proprie e sarà eseguito in maniera completamente indipendente da
 tutti gli altri. Questo non è del tutto vero nel caso di un programma
-\textit{multi-thread}, ma la gestione dei \itindex{thread} \textit{thread} in
-Linux sarà trattata a parte in cap.~\ref{cha:threads}.
+\textit{multi-thread}, ma la gestione dei \textit{thread} in Linux sarà
+trattata a parte in cap.~\ref{cha:threads}.
 
 
 \subsection{L'avvio e l'esecuzione di un programma}
 \label{sec:proc_main}
 
 \itindbeg{link-loader}
-
+\itindbeg{shared~objects}
 Quando un programma viene messo in esecuzione cosa che può essere fatta solo
 con una funzione della famiglia \func{exec} (vedi sez.~\ref{sec:proc_exec}) il
 kernel esegue un opportuno codice di avvio, il cosiddetto
@@ -57,9 +57,9 @@ Infatti, a meno di non aver specificato il flag \texttt{-static} durante la
 compilazione, tutti i programmi in Linux sono compilati facendo riferimento a
 librerie condivise, in modo da evitare di duplicare lo stesso codice nei
 relativi eseguibili e consentire un uso più efficiente della memoria, dato che
-il codice di uno \itindex{shared~objects} \textit{shared objects} viene
-caricato in memoria dal kernel una sola volta per tutti i programmi che lo
-usano.
+il codice di uno \textit{shared objects} viene caricato in memoria dal kernel
+una sola volta per tutti i programmi che lo usano.
+\itindend{shared~objects}
 
 Questo significa però che normalmente il codice di un programma è incompleto,
 contenendo solo i riferimenti alle funzioni di libreria che vuole utilizzare e
@@ -245,11 +245,11 @@ Un esempio di inclusione di questi file, preso da uno dei programmi di
 esempio, è il seguente, e si noti come gli \textit{header file} possano essere
 referenziati con il nome fra parentesi angolari, nel qual caso si indica l'uso
 di quelli installati con il sistema,\footnote{in un sistema GNU/Linux che
-  segue le specifiche del \itindex{Filesystem~Hierarchy~Standard~(FHS)}
-  \textit{Filesystem Hierarchy Standard} (per maggiori informazioni si
-  consulti sez.~1.2.3 di \cite{AGL}) si trovano sotto \texttt{/usr/include}.}
-o fra virgolette, nel qual caso si fa riferimento ad una versione locale, da
-indicare con un \itindsub{pathname}{relativo} \textit{pathname} relativo:
+  segue le specifiche del \textit{Filesystem Hierarchy Standard} (per maggiori
+  informazioni si consulti sez.~1.2.3 di \cite{AGL}) si trovano sotto
+  \texttt{/usr/include}.}  o fra virgolette, nel qual caso si fa riferimento
+ad una versione locale, da indicare con un \itindsub{pathname}{relativo}
+\textit{pathname} relativo:
 \includecodesnip{listati/main_include.c}
 
 Si tenga presente che oltre ai nomi riservati a livello generale di cui si è
@@ -655,26 +655,32 @@ generale detto spazio non è neppure continuo, cioè non tutti gli indirizzi
 possibili sono utilizzabili, e quelli usabili non sono necessariamente
 adiacenti.
 
+\itindbeg{huge~page}
+
 Per la gestione da parte del kernel la memoria viene divisa in pagine di
 dimensione fissa. Inizialmente queste pagine erano di 4kb sulle macchine a 32
 bit e di 8kb sulle alpha. Con le versioni più recenti del kernel è possibile
-anche utilizzare pagine di dimensioni maggiori (di 4Mb, dette
-\itindex{huge~page} \textit{huge page}), per sistemi con grandi quantitativi
-di memoria in cui l'uso di pagine troppo piccole comporta una perdita di
-prestazioni. In alcuni sistemi la costante \const{PAGE\_SIZE}, definita in
-\headfile{limits.h}, indica la dimensione di una pagina in byte, con Linux
-questo non avviene e per ottenere questa dimensione si deve ricorrere alla
-funzione \func{getpagesize} (vedi sez.~\ref{sec:sys_memory_res}).
+anche utilizzare pagine di dimensioni maggiori (di 4Mb, dette \textit{huge
+  page}), per sistemi con grandi quantitativi di memoria in cui l'uso di
+pagine troppo piccole comporta una perdita di prestazioni. In alcuni sistemi
+la costante \const{PAGE\_SIZE}, definita in \headfile{limits.h}, indica la
+dimensione di una pagina in byte, con Linux questo non avviene e per ottenere
+questa dimensione si deve ricorrere alla funzione \func{getpagesize} (vedi
+sez.~\ref{sec:sys_memory_res}).
+
+\itindend{huge~page}
+\itindbeg{page~table}
 
 Ciascuna pagina di memoria nello spazio di indirizzi virtuale è associata ad
 un supporto che può essere una pagina di memoria reale o ad un dispositivo di
 stoccaggio secondario (come lo spazio disco riservato alla \textit{swap}, o i
 file che contengono il codice). Per ciascun processo il kernel si cura di
-mantenere un mappa di queste corrispondenze nella cosiddetta
-\itindex{page~table} \textit{page table}.\footnote{questa è una
-  semplificazione brutale, il meccanismo è molto più complesso; una buona
-  trattazione di come Linux gestisce la memoria virtuale si trova su
-  \cite{LinVM}.}
+mantenere un mappa di queste corrispondenze nella cosiddetta \textit{page
+  table}.\footnote{questa è una semplificazione brutale, il meccanismo è molto
+  più complesso; una buona trattazione di come Linux gestisce la memoria
+  virtuale si trova su \cite{LinVM}.}
+
+\itindend{page~table}
 
 Una stessa pagina di memoria reale può fare da supporto a diverse pagine di
 memoria virtuale appartenenti a processi diversi, come accade in genere per le
@@ -725,51 +731,58 @@ pagine in memoria (vedi sez.~\ref{sec:proc_mem_lock}).
 \index{paginazione|)}
 \index{memoria~virtuale|)}
 
+
 \subsection{La struttura della memoria di un processo}
 \label{sec:proc_mem_layout}
 
+\itindbeg{segment~violation}
+
 Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
 una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
 tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
 commette quando si è manipolato male un puntatore e genera quella che viene
-chiamata una \itindex{segment~violation} \textit{segment violation}. Se si
-tenta cioè di leggere o scrivere con un indirizzo per il quale non esiste
-un'associazione nella memoria virtuale, il kernel risponde al relativo
-\textit{page fault} mandando un segnale \signal{SIGSEGV} al processo, che
-normalmente ne causa la terminazione immediata.
+chiamata una \textit{segment violation}. Se si tenta cioè di leggere o
+scrivere con un indirizzo per il quale non esiste un'associazione nella
+memoria virtuale, il kernel risponde al relativo \textit{page fault} mandando
+un segnale \signal{SIGSEGV} al processo, che normalmente ne causa la
+terminazione immediata.
+
+\itindend{segment~violation}
 
 È pertanto importante capire come viene strutturata la memoria virtuale di un
 processo. Essa viene divisa in \textsl{segmenti}, cioè un insieme contiguo di
 indirizzi virtuali ai quali il processo può accedere.  Solitamente un
 programma C viene suddiviso nei seguenti segmenti:
+\index{segmento!testo|(}
+\index{segmento!dati(}
+\itindbeg{heap} 
+\itindbeg{stack}
 \begin{enumerate*}
-\item Il \index{segmento!testo} segmento di testo o \textit{text segment}.
-  Contiene il codice del programma, delle funzioni di librerie da esso
-  utilizzate, e le costanti.  Normalmente viene condiviso fra tutti i processi
-  che eseguono lo stesso programma e nel caso delle librerie anche da processi
-  che eseguono altri programmi.
+\item Il \textsl{segmento di testo} o \textit{text segment}.  Contiene il
+  codice del programma, delle funzioni di librerie da esso utilizzate, e le
+  costanti.  Normalmente viene condiviso fra tutti i processi che eseguono lo
+  stesso programma e nel caso delle librerie anche da processi che eseguono
+  altri programmi.
 
   Quando l'architettura hardware lo supporta viene marcato in sola lettura per
   evitare sovrascritture accidentali (o maliziose) che ne modifichino le
   istruzioni.  Viene allocato da \func{execve} all'avvio del programma e resta
   invariato per tutto il tempo dell'esecuzione.
-
-\item Il \index{segmento!dati} segmento dei dati o \textit{data
-    segment}. Contiene tutti i dati del programma, come le
-  \index{variabili!globali} variabili globali, cioè quelle definite al di
-  fuori di tutte le funzioni che compongono il programma, e le
-  \index{variabili!statiche} variabili statiche, cioè quelle dichiarate con
-  l'attributo \direct{static},\footnote{la direttiva \direct{static} indica al
-    compilatore C che una variabile così dichiarata all'interno di una
-    funzione deve essere mantenuta staticamente in memoria (nel
-    \index{segmento!dati} segmento dati appunto); questo significa che la
-    variabile verrà inizializzata una sola volta alla prima invocazione della
-    funzione e che il suo valore sarà mantenuto fra diverse esecuzioni della
-    funzione stessa, la differenza con una \index{variabili!globali} variabile
+\index{variabili!globali|(}
+\index{variabili!statiche|(}
+\item Il \textsl{segmento dei dati} o \textit{data segment}. Contiene tutti i
+  dati del programma, come le \textsl{variabili globali}, cioè quelle definite
+  al di fuori di tutte le funzioni che compongono il programma, e le
+  \textsl{variabili statiche}, cioè quelle dichiarate con l'attributo
+  \direct{static},\footnote{la direttiva \direct{static} indica al compilatore
+    C che una variabile così dichiarata all'interno di una funzione deve
+    essere mantenuta staticamente in memoria (nel segmento dati appunto);
+    questo significa che la variabile verrà inizializzata una sola volta alla
+    prima invocazione della funzione e che il suo valore sarà mantenuto fra
+    diverse esecuzioni della funzione stessa, la differenza con una variabile
     globale è che essa può essere vista solo all'interno della funzione in cui
     è dichiarata.} e la memoria allocata dinamicamente. Di norma è diviso in
   tre parti:
-  
   \begin{itemize*}
   \item Il segmento dei dati inizializzati, che contiene le variabili il cui
     valore è stato assegnato esplicitamente. Ad esempio se si definisce:
@@ -784,45 +797,43 @@ programma C viene suddiviso nei seguenti segmenti:
     questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
     allocato all'avvio, e tutte le variabili vengono inizializzate a zero (ed
     i puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
-      variabili che vanno nel \index{segmento!dati} segmento dati, e non è
-      affatto vero in generale.}  Storicamente questa seconda parte del
-    \index{segmento!dati} segmento dati viene chiamata BSS (da \textit{Block
+      variabili che vanno nel segmento dati, e non è affatto vero in
+      generale.}  Storicamente questa seconda parte del segmento dati viene
+    chiamata \itindex{Block~Started~by~Symbol~(BSS)} BSS (da \textit{Block
       Started by Symbol}). La sua dimensione è fissa.
-  \item Lo \itindex{heap} \textit{heap}, detto anche \textit{free
-      store}. Tecnicamente lo si può considerare l'estensione del segmento dei
-    dati non inizializzati, a cui di solito è posto giusto di seguito. Questo
-    è il segmento che viene utilizzato per l'allocazione dinamica della
-    memoria.  Lo \textit{heap} può essere ridimensionato allargandolo e
-    restringendolo per allocare e disallocare la memoria dinamica con le
-    apposite funzioni (vedi sez.~\ref{sec:proc_mem_alloc}), ma il suo limite
-    inferiore, quello adiacente al segmento dei dati non inizializzati, ha una
-    posizione fissa.
+    \index{variabili!globali|)} \index{variabili!statiche|)}
+  \item Lo \textit{heap}, detto anche \textit{free store}. Tecnicamente lo si
+    può considerare l'estensione del segmento dei dati non inizializzati, a
+    cui di solito è posto giusto di seguito. Questo è il segmento che viene
+    utilizzato per l'allocazione dinamica della memoria.  Lo \textit{heap} può
+    essere ridimensionato allargandolo e restringendolo per allocare e
+    disallocare la memoria dinamica con le apposite funzioni (vedi
+    sez.~\ref{sec:proc_mem_alloc}), ma il suo limite inferiore, quello
+    adiacente al segmento dei dati non inizializzati, ha una posizione fissa.
   \end{itemize*}
-
-\item Il segmento di \itindex{stack} \textit{stack}, che contiene quello che
-  viene chiamato \textit{stack} del programma.  Tutte le volte che si effettua
-  una chiamata ad una funzione è qui che viene salvato l'indirizzo di ritorno
-  e le informazioni dello stato del chiamante (come il contenuto di alcuni
-  registri della CPU), poi la funzione chiamata alloca qui lo spazio per le
-  sue variabili locali. Tutti questi dati vengono \textit{impilati} (da questo
-  viene il nome \itindex{stack} \textit{stack}) in sequenza uno sull'altro; in
-  questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
-  della funzione lo spazio è automaticamente rilasciato e
-  ``\textsl{ripulito}''.\footnote{il compilatore si incarica di generare
-    automaticamente il codice necessario, seguendo quella che viene chiamata
-    una \textit{calling convention}; quella standard usata con il C ed il C++
-    è detta \textit{cdecl} e prevede che gli argomenti siano caricati nello
-    \textit{stack} dal chiamante da destra a sinistra, e che sia il chiamante
-    stesso ad eseguire la ripulitura dello \textit{stack} al ritorno della
-    funzione, se ne possono però utilizzare di alternative (ad esempio nel
-    Pascal gli argomenti sono inseriti da sinistra a destra ed è compito del
-    chiamato ripulire lo \textit{stack}), in genere non ci si deve preoccupare
-    di questo fintanto che non si mescolano funzioni scritte con linguaggi
-    diversi.}
+\item Il segmento di \textit{stack}, che contiene quello che viene chiamato lo
+  ``\textit{stack}'' del programma.  Tutte le volte che si effettua una
+  chiamata ad una funzione è qui che viene salvato l'indirizzo di ritorno e le
+  informazioni dello stato del chiamante (come il contenuto di alcuni registri
+  della CPU), poi la funzione chiamata alloca qui lo spazio per le sue
+  variabili locali. Tutti questi dati vengono \textit{impilati} (da questo
+  viene il nome \textit{stack}) in sequenza uno sull'altro; in questo modo le
+  funzioni possono essere chiamate ricorsivamente. Al ritorno della funzione
+  lo spazio è automaticamente rilasciato e ``\textsl{ripulito}''.\footnote{il
+    compilatore si incarica di generare automaticamente il codice necessario,
+    seguendo quella che viene chiamata una \textit{calling convention}; quella
+    standard usata con il C ed il C++ è detta \textit{cdecl} e prevede che gli
+    argomenti siano caricati nello \textit{stack} dal chiamante da destra a
+    sinistra, e che sia il chiamante stesso ad eseguire la ripulitura dello
+    \textit{stack} al ritorno della funzione, se ne possono però utilizzare di
+    alternative (ad esempio nel Pascal gli argomenti sono inseriti da sinistra
+    a destra ed è compito del chiamato ripulire lo \textit{stack}), in genere
+    non ci si deve preoccupare di questo fintanto che non si mescolano
+    funzioni scritte con linguaggi diversi.}
 
   La dimensione di questo segmento aumenta seguendo la crescita dello
-  \itindex{stack} \textit{stack} del programma, ma non viene ridotta quando
-  quest'ultimo si restringe.
+  \textit{stack} del programma, ma non viene ridotta quando quest'ultimo si
+  restringe.
 \end{enumerate*}
 
 \begin{figure}[htb]
@@ -853,19 +864,23 @@ programma C viene suddiviso nei seguenti segmenti:
 \end{figure}
 
 Una disposizione tipica dei vari segmenti (testo, dati inizializzati e non
-inizializzati, \itindex{heap} \textit{heap}, \itindex{stack} \textit{stack},
-ecc.) è riportata in fig.~\ref{fig:proc_mem_layout}. Si noti come in figura
-sia indicata una ulteriore regione, marcata \textit{environment}, che è quella
-che contiene i dati relativi alle variabili di ambiente passate al programma
-al suo avvio (torneremo su questo argomento in sez.~\ref{sec:proc_environ}).
+inizializzati, \textit{heap}, \textit{stack}, ecc.) è riportata in
+fig.~\ref{fig:proc_mem_layout}. Si noti come in figura sia indicata una
+ulteriore regione, marcata \textit{environment}, che è quella che contiene i
+dati relativi alle variabili di ambiente passate al programma al suo avvio
+(torneremo su questo argomento in sez.~\ref{sec:proc_environ}).
 
 Usando il comando \cmd{size} su un programma se ne può stampare le dimensioni
-dei \index{segmento!testo} segmenti di testo e \index{segmento!dati} di dati
-(solo però per i dati inizializzati ed il BSS, dato che lo \itindex{heap}
-\textit{heap} ha una dimensione dinamica). Si tenga presente comunque che il
-BSS, contrariamente al segmento dei dati inizializzati, non è mai salvato sul
-file che contiene l'eseguibile, dato che viene sempre inizializzato a zero al
-caricamento del programma.
+dei segmenti di testo e di dati (solo però per i dati inizializzati ed il BSS,
+dato che lo \textit{heap} ha una dimensione dinamica). Si tenga presente
+comunque che il BSS, contrariamente al segmento dei dati inizializzati, non è
+mai salvato sul file che contiene l'eseguibile, dato che viene sempre
+inizializzato a zero al caricamento del programma.
+
+\index{segmento!testo|)}
+\index{segmento!dati)}
+\itindend{heap} 
+\itindend{stack}
 
 
 \subsection{Allocazione della memoria per i programmi C}
@@ -875,21 +890,24 @@ Il C supporta direttamente, come linguaggio di programmazione, soltanto due
 modalità di allocazione della memoria: l'\textsl{allocazione statica} e
 l'\textsl{allocazione automatica}.
 
-L'\textsl{allocazione statica} è quella con cui sono memorizzate le
-\index{variabili!globali} variabili globali e le \index{variabili!statiche}
-variabili statiche, cioè le variabili il cui valore deve essere mantenuto per
-tutta la durata del programma. Come accennato queste variabili vengono
-allocate nel \index{segmento!dati} segmento dei dati all'avvio del programma
-come parte delle operazioni svolte da \func{exec}, e lo spazio da loro
-occupato non viene liberato fino alla sua conclusione.
+L'\textsl{allocazione statica} è quella con cui sono memorizzate le variabili
+globali e le variabili statiche, cioè le variabili il cui valore deve essere
+mantenuto per tutta la durata del programma. Come accennato queste variabili
+vengono allocate nel segmento dei dati all'avvio del programma come parte
+delle operazioni svolte da \func{exec}, e lo spazio da loro occupato non viene
+liberato fino alla sua conclusione.
+
+\index{variabili!automatiche|(}
 
 L'\textsl{allocazione automatica} è quella che avviene per gli argomenti di
 una funzione e per le sue variabili locali, quelle che vengono definite
-all'interno della funzione che esistono solo per la durata della sua esecuzione
-e che per questo vengono anche dette \index{variabili!automatiche}
-\textsl{variabili automatiche}.  Lo spazio per queste variabili viene allocato
-nello \itindex{stack} \textit{stack} quando viene eseguita la funzione e
-liberato quando si esce dalla medesima.
+all'interno della funzione che esistono solo per la durata della sua
+esecuzione e che per questo vengono anche dette \textsl{variabili
+  automatiche}.  Lo spazio per queste variabili viene allocato nello
+\textit{stack} quando viene eseguita la funzione e liberato quando si esce
+dalla medesima.
+
+\index{variabili!automatiche|)}
 
 Esiste però un terzo tipo di allocazione, l'\textsl{allocazione dinamica}
 della memoria, che non è prevista direttamente all'interno del linguaggio C,
@@ -900,13 +918,12 @@ definire in fase di programmazione una variabile le cui dimensioni possano
 essere modificate durante l'esecuzione del programma. Per questo la libreria
 standard del C fornisce una opportuna serie di funzioni per eseguire
 l'allocazione dinamica di memoria, che come accennato avviene nello
-\itindex{heap} \textit{heap}.
+\textit{heap}.
 
 Le variabili il cui contenuto è allocato in questo modo non potranno essere
-usate direttamente come le altre (quelle nello \itindex{stack}
-\textit{stack}), ma l'accesso sarà possibile solo in maniera indiretta,
-attraverso i puntatori alla memoria loro riservata che si sono ottenuti dalle
-funzioni di allocazione.
+usate direttamente come le altre (quelle nello \textit{stack}), ma l'accesso
+sarà possibile solo in maniera indiretta, attraverso i puntatori alla memoria
+loro riservata che si sono ottenuti dalle funzioni di allocazione.
 
 Le funzioni previste dallo standard ANSI C per la gestione della memoria sono
 quattro: \func{malloc}, \func{calloc}, \func{realloc} e \func{free}. Le prime
@@ -967,14 +984,17 @@ dei dati di gestione dell'allocazione, che può dar luogo a problemi gravi, ad
 esempio un \textit{segmentation fault} in una successiva chiamata di una di
 queste funzioni.
 
-Dato che questo errore, chiamato in gergo \itindex{double~free} \textit{double
-  free}, è abbastanza frequente, specie quando si manipolano vettori di
-puntatori, e dato che le conseguenze possono essere pesanti ed inaspettate, si
-suggerisce come soluzione precauzionale di assegnare sempre a \val{NULL} ogni
-puntatore su cui sia stata eseguita \func{free} immediatamente dopo
-l'esecuzione della funzione. In questo modo, dato che con un puntatore nullo
-\func{free} non esegue nessuna operazione, si evitano i problemi del
-\itindex{double~free} \textit{double free}.
+\itindbeg{double~free}
+
+Dato che questo errore, chiamato in gergo \textit{double free}, è abbastanza
+frequente, specie quando si manipolano vettori di puntatori, e dato che le
+conseguenze possono essere pesanti ed inaspettate, si suggerisce come
+soluzione precauzionale di assegnare sempre a \val{NULL} ogni puntatore su cui
+sia stata eseguita \func{free} immediatamente dopo l'esecuzione della
+funzione. In questo modo, dato che con un puntatore nullo \func{free} non
+esegue nessuna operazione, si evitano i problemi del \textit{double free}.
+
+\itindend{double~free}
 
 Infine la funzione \funcd{realloc} consente di modificare, in genere di
 aumentare, la dimensione di un'area di memoria precedentemente allocata; il
@@ -1020,11 +1040,10 @@ sez.~\ref{sec:proc_environ}), in particolare diventa possibile tracciare
 questo tipo di errori usando la variabile di ambiente \envvar{MALLOC\_CHECK\_}
 che quando viene definita mette in uso una versione meno efficiente delle
 funzioni suddette, che però è più tollerante nei confronti di piccoli errori
-come quello dei \itindex{double~free} \textit{double~free} o i \textit{buffer
-  overrun} di un byte.\footnote{uno degli errori più comuni, causato ad
-  esempio dalla scrittura di una stringa di dimensione pari a quella del
-  buffer, in cui ci si dimentica dello zero di terminazione finale.}  In
-particolare:
+come quello dei \textit{double free} o i \textit{buffer overrun} di un
+byte.\footnote{uno degli errori più comuni, causato ad esempio dalla scrittura
+  di una stringa di dimensione pari a quella del buffer, in cui ci si
+  dimentica dello zero di terminazione finale.}  In particolare:
 \begin{itemize*}
 \item se la variabile è posta a $0$ gli errori vengono ignorati;
 \item se la variabile è posta a $1$ viene stampato un avviso sullo
@@ -1036,11 +1055,12 @@ particolare:
   \func{abort}. 
 \end{itemize*}
 
+\itindbeg{memory~leak}
+
 L'errore di programmazione più comune e più difficile da risolvere che si
 incontra con le funzioni di allocazione è quando non viene opportunamente
 liberata la memoria non più utilizzata, quello che in inglese viene chiamato
-\itindex{memory~leak} \textit{memory leak}, cioè una \textsl{perdita di
-  memoria}.
+\textit{memory leak}, cioè una \textsl{perdita di memoria}.
 
 Un caso tipico che illustra il problema è quello in cui in una propria
 funzione si alloca della memoria per uso locale senza liberarla prima di
@@ -1054,13 +1074,13 @@ Il problema è che l'esaurimento della memoria può avvenire in qualunque
 momento, in corrispondenza ad una qualunque chiamata di \func{malloc} che può
 essere in una sezione del codice che non ha alcuna relazione con la funzione
 che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
-\itindex{memory~leak} \textit{memory leak}.
+\textit{memory leak}.
 
 In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
-programmazione ad oggetti, il problema dei \itindex{memory~leak}
-\textit{memory leak} si può notevolmente ridimensionare attraverso l'uso
-accurato di appositi oggetti come gli \textit{smartpointers}.  Questo però in
-genere va a scapito delle prestazioni dell'applicazione in esecuzione.
+programmazione ad oggetti, il problema dei \textit{memory leak} si può
+notevolmente ridimensionare attraverso l'uso accurato di appositi oggetti come
+gli \textit{smartpointers}.  Questo però in genere va a scapito delle
+prestazioni dell'applicazione in esecuzione.
 
 % TODO decidere cosa fare di questo che segue
 % In altri linguaggi come il java e recentemente il C\# il problema non si pone
@@ -1097,11 +1117,12 @@ ricompilare il programma,\footnote{esempi sono \textit{Dmalloc}
 l'allocazione della memoria. Vedremo alcune delle funzionalità di ausilio
 presenti nella \acr{glibc} in sez.~\ref{sec:proc_memory_adv_management}.
 
+\itindend{memory~leak}
+
 Una possibile alternativa all'uso di \func{malloc}, per evitare di soffrire
-dei problemi di \itindex{memory~leak} \textit{memory leak} descritti in
-precedenza, è di allocare la memoria nel segmento di \itindex{stack}
-\textit{stack} della funzione corrente invece che nello \itindex{heap}
-\textit{heap}. Per farlo si può usare la funzione \funcd{alloca}, la cui
+dei problemi di \textit{memory leak} descritti in precedenza, è di allocare la
+memoria nel segmento di \textit{stack} della funzione corrente invece che
+nello \textit{heap}. Per farlo si può usare la funzione \funcd{alloca}, la cui
 sintassi è identica a quella di \func{malloc}; il suo prototipo è:
 
 \begin{funcproto}{ 
@@ -1114,22 +1135,21 @@ sintassi è identica a quella di \func{malloc}; il suo prototipo è:
 \end{funcproto}
 
 La funzione alloca la quantità di memoria (non inizializzata) richiesta
-dall'argomento \param{size} nel segmento di \itindex{stack} \textit{stack}
-della funzione chiamante.  Con questa funzione non è più necessario liberare
-la memoria allocata, e quindi non esiste un analogo della \func{free}, in
-quanto essa viene rilasciata automaticamente al ritorno della funzione.
+dall'argomento \param{size} nel segmento di \textit{stack} della funzione
+chiamante. Con questa funzione non è più necessario liberare la memoria
+allocata, e quindi non esiste un analogo della \func{free}, in quanto essa
+viene rilasciata automaticamente al ritorno della funzione.
 
 Come è evidente questa funzione ha alcuni vantaggi interessanti, anzitutto
-permette di evitare alla radice i problemi di \itindex{memory~leak}
-\textit{memory leak}, dato che non serve più la deallocazione esplicita;
-inoltre la deallocazione automatica funziona anche quando si usa
-\func{longjmp} per uscire da una subroutine con un salto non locale da una
-funzione (vedi sez.~\ref{sec:proc_longjmp}).  Un altro vantaggio è che in
-Linux la funzione è molto più veloce di \func{malloc} e non viene sprecato
-spazio, infatti non è necessario gestire un pool di memoria da riservare e si
-evitano così anche i problemi di frammentazione di quest'ultimo, che
-comportano inefficienze sia nell'allocazione della memoria che nell'esecuzione
-dell'allocazione.
+permette di evitare alla radice i problemi di \textit{memory leak}, dato che
+non serve più la deallocazione esplicita; inoltre la deallocazione automatica
+funziona anche quando si usa \func{longjmp} per uscire da una subroutine con
+un salto non locale da una funzione (vedi sez.~\ref{sec:proc_longjmp}).  Un
+altro vantaggio è che in Linux la funzione è molto più veloce di \func{malloc}
+e non viene sprecato spazio, infatti non è necessario gestire un pool di
+memoria da riservare e si evitano così anche i problemi di frammentazione di
+quest'ultimo, che comportano inefficienze sia nell'allocazione della memoria
+che nell'esecuzione dell'allocazione.
 
 Gli svantaggi sono che questa funzione non è disponibile su tutti gli Unix, e
 non è inserita né nello standard POSIX né in SUSv3 (ma è presente in BSD), il
@@ -1140,34 +1160,33 @@ possibile usare \func{alloca} per allocare memoria che deve poi essere usata
 anche al di fuori della funzione in cui essa viene chiamata, dato che
 all'uscita dalla funzione lo spazio allocato diventerebbe libero, e potrebbe
 essere sovrascritto all'invocazione di nuove funzioni.  Questo è lo stesso
-problema che si può avere con le \index{variabili!automatiche} variabili
-automatiche, su cui torneremo in sez.~\ref{sec:proc_var_passing}.
+problema che si può avere con le variabili automatiche, su cui torneremo in
+sez.~\ref{sec:proc_var_passing}.
 
 Infine non esiste un modo di sapere se l'allocazione ha avuto successo, la
 funzione infatti viene realizzata inserendo del codice \textit{inline} nel
 programma\footnote{questo comporta anche il fatto che non è possibile
   sostituirla con una propria versione o modificarne il comportamento
   collegando il proprio programma con un'altra libreria.} che si limita a
-modificare il puntatore nello \itindex{stack} \textit{stack} e non c'è modo di
-sapere se se ne sono superate le dimensioni, per cui in caso di fallimento
-nell'allocazione il comportamento del programma può risultare indefinito,
-dando luogo ad una \itindex{segment~violation} \textit{segment violation} la
-prima volta che cercherà di accedere alla memoria non effettivamente
-disponibile. 
+modificare il puntatore nello \textit{stack} e non c'è modo di sapere se se ne
+sono superate le dimensioni, per cui in caso di fallimento nell'allocazione il
+comportamento del programma può risultare indefinito, dando luogo ad una
+\textit{segment violation} la prima volta che cercherà di accedere alla
+memoria non effettivamente disponibile.
 
 
 \index{segmento!dati|(}
-
-Le due funzioni seguenti\footnote{le due funzioni sono state definite con BSD
-  4.3, sono marcate obsolete in SUSv2 e non fanno parte delle librerie
-  standard del C e mentre sono state esplicitamente rimosse dallo standard
-  POSIX.1-2001.} vengono utilizzate soltanto quando è necessario effettuare
-direttamente la gestione della memoria associata allo spazio dati di un
-processo, per poterle utilizzare è necessario definire una della macro di
-funzionalità (vedi sez.~\ref{sec:intro_gcc_glibc_std}) fra
-\macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE} (ad un
-valore maggiore o uguale di 500). La prima funzione è \funcd{brk}, ed il suo
-prototipo è:
+\itindbeg{heap} 
+
+Le due funzioni seguenti vengono utilizzate soltanto quando è necessario
+effettuare direttamente la gestione della memoria associata allo spazio dati
+di un processo,\footnote{le due funzioni sono state definite con BSD 4.3, sono
+  marcate obsolete in SUSv2 e non fanno parte delle librerie standard del C e
+  mentre sono state esplicitamente rimosse dallo standard POSIX.1-2001.} per
+poterle utilizzare è necessario definire una della macro di funzionalità (vedi
+sez.~\ref{sec:intro_gcc_glibc_std}) fra \macro{\_BSD\_SOURCE},
+\macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE} (ad un valore maggiore o
+uguale di 500). La prima funzione è \funcd{brk}, ed il suo prototipo è:
 
 \begin{funcproto}{ 
 \fhead{unistd.h} 
@@ -1180,11 +1199,10 @@ prototipo è:
 
 La funzione è un'interfaccia all'omonima \textit{system call} ed imposta
 l'indirizzo finale del segmento dati di un processo (più precisamente dello
-\itindex{heap} \textit{heap}) all'indirizzo specificato
-da \param{addr}. Quest'ultimo deve essere un valore ragionevole, e la
-dimensione totale non deve comunque eccedere un eventuale limite (vedi
-sez.~\ref{sec:sys_resource_limit}) imposto sulle dimensioni massime del
-segmento dati del processo.
+\textit{heap}) all'indirizzo specificato da \param{addr}. Quest'ultimo deve
+essere un valore ragionevole, e la dimensione totale non deve comunque
+eccedere un eventuale limite (vedi sez.~\ref{sec:sys_resource_limit}) imposto
+sulle dimensioni massime del segmento dati del processo.
 
 Il valore di ritorno della funzione fa riferimento alla versione fornita dalla
 \acr{glibc}, in realtà in Linux la \textit{system call} corrispondente
@@ -1209,12 +1227,12 @@ segmento dati\footnote{in questo caso si tratta soltanto di una funzione di
   caso \var{errno} assumerà il valore \errcode{ENOMEM}.}
 \end{funcproto}
 
-La funzione incrementa la dimensione dello \itindex{heap} \textit{heap} di un
+La funzione incrementa la dimensione dello \textit{heap} di un
 programma del valore indicato dall'argomento \param{increment}, restituendo il
 nuovo indirizzo finale dello stesso.  L'argomento è definito come di tipo
 \type{intptr\_t}, ma a seconda della versione delle librerie e del sistema può
-essere indicato con una serie di tipi equivalenti come \type{ptrdiff\_t},
-\type{ssize\_t}, \ctyp{int}. Se invocata con un valore nullo la funzione
+essere indicato con una serie di tipi equivalenti come \ctyp{ptrdiff\_t},
+\ctyp{ssize\_t}, \ctyp{int}. Se invocata con un valore nullo la funzione
 permette di ottenere l'attuale posizione della fine del segmento dati.
 
 Queste due funzioni sono state deliberatamente escluse dallo standard POSIX.1
@@ -1222,7 +1240,7 @@ dato che per i normali programmi è sempre opportuno usare le funzioni di
 allocazione standard descritte in precedenza, a meno di non voler realizzare
 per proprio conto un diverso meccanismo di gestione della memoria del segmento
 dati.
-
+\itindend{heap} 
 \index{segmento!dati|)}
 
 
@@ -1326,7 +1344,7 @@ pagine potrebbe essere già cambiato al ritorno stesso della funzione, a meno
 che, come vedremo ora, non si sia attivato il meccanismo che forza il
 mantenimento di una pagina sulla memoria.  
 
-\itindbeg{memory~locking} 
+\itindbeg{memory~locking}
 
 Il meccanismo che previene la paginazione di parte della memoria virtuale di
 un processo è chiamato \textit{memory locking} (o \textsl{blocco della
@@ -1341,13 +1359,13 @@ Il \textit{memory lock} persiste fintanto che il processo che detiene la
 memoria bloccata non la sblocca. Chiaramente la terminazione del processo
 comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
 tutti i suoi \textit{memory lock}.  Inoltre i \textit{memory lock} non sono
-ereditati dai processi figli, ma siccome Linux usa il \itindex{copy~on~write}
-\textit{copy on write} (vedi sez.~\ref{sec:proc_fork}) gli indirizzi virtuali
-del figlio sono mantenuti sullo stesso segmento di RAM del padre, e quindi
-fintanto che un figlio non scrive su un segmento bloccato, può usufruire del
-\textit{memory lock} del padre. Infine i \textit{memory lock} vengono
-automaticamente rimossi se si pone in esecuzione un altro programma con
-\func{exec} (vedi sez.~\ref{sec:proc_exec}).
+ereditati dai processi figli, ma siccome Linux usa il \textit{copy on write}
+(vedi sez.~\ref{sec:proc_fork}) gli indirizzi virtuali del figlio sono
+mantenuti sullo stesso segmento di RAM del padre, e quindi fintanto che un
+figlio non scrive su un segmento bloccato, può usufruire del \textit{memory
+  lock} del padre. Infine i \textit{memory lock} vengono automaticamente
+rimossi se si pone in esecuzione un altro programma con \func{exec} (vedi
+sez.~\ref{sec:proc_exec}).
 
 Il sistema pone dei limiti all'ammontare di memoria di un processo che può
 essere bloccata e al totale di memoria fisica che si può dedicare a questo, lo
@@ -1400,18 +1418,17 @@ loro prototipi sono:
 \end{funcproto}
 
 Le due funzioni permettono rispettivamente di bloccare e sbloccare la
-\index{paginazione} paginazione per l'intervallo di memoria iniziante
-all'indirizzo \param{addr} e lungo \param{len} byte.  Tutte le pagine che
-contengono una parte dell'intervallo bloccato sono mantenute in RAM per tutta
-la durata del blocco. Con kernel diversi da Linux si può ottenere un errore di
+paginazione per l'intervallo di memoria iniziante all'indirizzo \param{addr} e
+lungo \param{len} byte.  Tutte le pagine che contengono una parte
+dell'intervallo bloccato sono mantenute in RAM per tutta la durata del
+blocco. Con kernel diversi da Linux si può ottenere un errore di
 \errcode{EINVAL} se \param{addr} non è un multiplo della dimensione delle
 pagine di memoria, pertanto se si ha a cuore la portabilità si deve avere cura
 di allinearne correttamente il valore.
 
 Altre due funzioni di sistema, \funcd{mlockall} e \funcd{munlockall},
-consentono di bloccare genericamente la \index{paginazione} paginazione per
-l'intero spazio di indirizzi di un processo.  I prototipi di queste funzioni
-sono:
+consentono di bloccare genericamente la paginazione per l'intero spazio di
+indirizzi di un processo.  I prototipi di queste funzioni sono:
 
 \begin{funcproto}{ 
 \fhead{sys/mman.h} 
@@ -1449,33 +1466,30 @@ espressi dalle costanti riportate in tab.~\ref{tab:mlockall_flags}.
 \end{table}
 
 Con \func{mlockall} si possono bloccare tutte le pagine mappate nello spazio
-di indirizzi del processo, sia che comprendano il \index{segmento!dati}
-\index{segmento!testo} segmento di testo, di dati, lo \itindex{stack}
-\textit{stack}, lo \itindex{heap} \textit{heap} e pure le funzioni di libreria
-chiamate, i file mappati in memoria, i dati del kernel mappati in user space,
-la memoria condivisa.  L'uso dell'argomento \param{flags} permette di
-selezionare con maggior finezza le pagine da bloccare, ad esempio usando
-\const{MCL\_FUTURE} ci si può limitare a tutte le pagine allocate a partire
-dalla chiamata della funzione.
-
-In ogni caso un processo \textit{real-time} che deve entrare in una
-\index{sezione~critica} sezione critica deve provvedere a riservare memoria
-sufficiente prima dell'ingresso, per scongiurare l'occorrenza di un eventuale
-\textit{page fault} causato dal meccanismo di \itindex{copy~on~write}
-\textit{copy on write}.  Infatti se nella \index{sezione~critica} sezione
-critica si va ad utilizzare memoria che non è ancora stata riportata in RAM si
-potrebbe avere un \textit{page fault} durante l'esecuzione della stessa, con
-conseguente rallentamento (probabilmente inaccettabile) dei tempi di
-esecuzione.
+di indirizzi del processo, sia che comprendano il segmento di testo, di dati,
+lo \textit{stack}, lo \textit{heap} e pure le funzioni di libreria chiamate, i
+file mappati in memoria, i dati del kernel mappati in user space, la memoria
+condivisa.  L'uso dell'argomento \param{flags} permette di selezionare con
+maggior finezza le pagine da bloccare, ad esempio usando \const{MCL\_FUTURE}
+ci si può limitare a tutte le pagine allocate a partire dalla chiamata della
+funzione.
+
+In ogni caso un processo \textit{real-time} che deve entrare in una sezione
+critica (vedi sez.~\ref{sec:proc_race_cond}) deve provvedere a riservare
+memoria sufficiente prima dell'ingresso, per scongiurare l'occorrenza di un
+eventuale \textit{page fault} causato dal meccanismo di \textit{copy on
+  write}.  Infatti se nella sezione critica si va ad utilizzare memoria che
+non è ancora stata riportata in RAM si potrebbe avere un \textit{page fault}
+durante l'esecuzione della stessa, con conseguente rallentamento
+(probabilmente inaccettabile) dei tempi di esecuzione.
 
 In genere si ovvia a questa problematica chiamando una funzione che ha
-allocato una quantità sufficientemente ampia di \index{variabili!automatiche}
-variabili automatiche, in modo che esse vengano mappate in RAM dallo
-\itindex{stack} \textit{stack}, dopo di che, per essere sicuri che esse siano
-state effettivamente portate in memoria, ci si scrive sopra.
+allocato una quantità sufficientemente ampia di variabili automatiche, in modo
+che esse vengano mappate in RAM dallo \textit{stack}, dopo di che, per essere
+sicuri che esse siano state effettivamente portate in memoria, ci si scrive
+sopra.
 
 \itindend{memory~locking}
-
 \index{memoria~virtuale|)} 
 
 
@@ -1568,13 +1582,13 @@ di \func{malloc}.
 
 Un secondo caso in cui risulta estremamente utile poter avere un maggior
 controllo delle modalità di allocazione della memoria è quello in cui cercano
-errori di programmazione. Esempi di questi errori sono i \itindex{double~free}
-\textit{double free}, o i cosiddetti \itindex{buffer~overrun} \textit{buffer
-  overrun}, cioè le scritture su un buffer oltre le dimensioni della sua
+errori di programmazione. Esempi di questi errori sono i \textit{double free},
+o i cosiddetti \itindex{buffer~overrun} \textit{buffer overrun}, cioè le
+scritture su un buffer oltre le dimensioni della sua
 allocazione,\footnote{entrambe queste operazioni causano in genere la
   corruzione dei dati di controllo delle funzioni di allocazione, che vengono
-  anch'essi mantenuti nello \itindex{heap} \textit{heap} per tenere traccia
-  delle zone di memoria allocata.} o i classici \textit{memory leak}.
+  anch'essi mantenuti nello \textit{heap} per tenere traccia delle zone di
+  memoria allocata.} o i classici \textit{memory leak}.
 
 Abbiamo visto in sez.~\ref{sec:proc_mem_lock} come una prima funzionalità di
 ausilio nella ricerca di questi errori sia l'uso della variabile di ambiente
@@ -1814,7 +1828,7 @@ altri elementi di \param{argv} che cominciano con il carattere ``\texttt{-}''.
 Quando \func{getopt} trova un'opzione fra quelle indicate in \param{optstring}
 essa ritorna il valore numerico del carattere, in questo modo si possono
 eseguire azioni specifiche usando uno \instruction{switch}; la funzione
-inoltre inizializza alcune \index{variabili!globali} variabili globali:
+inoltre inizializza alcune variabili globali:
 \begin{itemize*}
 \item \var{char *optarg} contiene il puntatore alla stringa parametro
   dell'opzione.
@@ -1881,9 +1895,9 @@ lunghezza del vettore data da un equivalente di \param{argc}, ma la lista è
 terminata da un puntatore nullo.
 
 L'indirizzo della lista delle variabili di ambiente è passato attraverso la
-\index{variabili!globali} variabile globale \var{environ}, che viene definita
-automaticamente per ciascun processo, e a cui si può accedere attraverso una
-semplice dichiarazione del tipo:
+variabile globale \var{environ}, che viene definita automaticamente per
+ciascun processo, e a cui si può accedere attraverso una semplice
+dichiarazione del tipo:
 \includecodesnip{listati/env_ptr.c}
 un esempio della struttura di questa lista, contenente alcune delle variabili
 più comuni che normalmente sono definite dal sistema, è riportato in
@@ -2085,10 +2099,10 @@ sostituendo il relativo puntatore;\footnote{il comportamento è lo stesso delle
   eliminando anche, sempre in conformità a SUSv2, l'attributo \direct{const}
   dal prototipo.}  pertanto ogni cambiamento alla stringa in questione si
 riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
-questa funzione una \index{variabili!automatiche} variabile automatica (per
-evitare i problemi esposti in sez.~\ref{sec:proc_var_passing}). Benché non sia
-richiesto dallo standard nelle versioni della \acr{glibc} a partire dalla 2.1
-la funzione è rientrante (vedi sez.~\ref{sec:proc_reentrant}).
+questa funzione una variabile automatica (per evitare i problemi esposti in
+sez.~\ref{sec:proc_var_passing}). Benché non sia richiesto dallo standard
+nelle versioni della \acr{glibc} a partire dalla 2.1 la funzione è rientrante
+(vedi sez.~\ref{sec:proc_reentrant}).
 
 Infine quando una chiamata a \func{putenv} comporta la necessità di creare una
 nuova versione del vettore \var{environ} questo sarà allocato automaticamente,
@@ -2096,10 +2110,9 @@ ma la versione corrente sarà deallocata solo se anch'essa è risultante da
 un'allocazione fatta in precedenza da un'altra \func{putenv}. Questo avviene
 perché il vettore delle variabili di ambiente iniziale, creato dalla chiamata
 ad \func{exec} (vedi sez.~\ref{sec:proc_exec}) è piazzato nella memoria al di
-sopra dello \itindex{stack} \textit{stack}, (vedi
-fig.~\ref{fig:proc_mem_layout}) e non nello \itindex{heap} \textit{heap} e
-quindi non può essere deallocato.  Inoltre la memoria associata alle variabili
-di ambiente eliminate non viene liberata.
+sopra dello \textit{stack}, (vedi fig.~\ref{fig:proc_mem_layout}) e non nello
+\textit{heap} e quindi non può essere deallocato.  Inoltre la memoria
+associata alle variabili di ambiente eliminate non viene liberata.
 
 Come alternativa a \func{putenv} si può usare la funzione \funcd{setenv} che
 però consente solo di aggiungere o modificare una variabile di ambiente; il
@@ -2259,15 +2272,17 @@ argomenti; in genere le informazioni a riguardo dei risultati vengono passate
 alla funzione chiamante attraverso il valore di ritorno.  È buona norma
 seguire questa pratica anche nella programmazione normale.
 
+\itindbeg{value~result~argument}
+
 Talvolta però è necessario che la funzione possa restituire indietro alla
 funzione chiamante un valore relativo ad uno dei suoi argomenti usato anche in
-ingresso.  Per far questo si usa il cosiddetto \itindex{value~result~argument}
-\textit{value result argument}, si passa cioè, invece di una normale
-variabile, un puntatore alla stessa. Gli esempi di questa modalità di
-passaggio sono moltissimi, ad esempio essa viene usata nelle funzioni che
-gestiscono i socket (in sez.~\ref{sec:TCP_functions}), in cui, per permettere
-al kernel di restituire informazioni sulle dimensioni delle strutture degli
-indirizzi utilizzate, viene usato proprio questo meccanismo.
+ingresso.  Per far questo si usa il cosiddetto \textit{value result argument},
+si passa cioè, invece di una normale variabile, un puntatore alla stessa. Gli
+esempi di questa modalità di passaggio sono moltissimi, ad esempio essa viene
+usata nelle funzioni che gestiscono i socket (in
+sez.~\ref{sec:TCP_functions}), in cui, per permettere al kernel di restituire
+informazioni sulle dimensioni delle strutture degli indirizzi utilizzate,
+viene usato proprio questo meccanismo.
 
 Occorre tenere ben presente questa differenza, perché le variabili passate in
 maniera ordinaria, che vengono inserite nello \textit{stack}, cessano di
@@ -2276,12 +2291,13 @@ all'interno della stessa sparisce con la conclusione della stessa, per poter
 passare delle informazioni occorre quindi usare un puntatore che faccia
 riferimento ad un indirizzo accessibile alla funzione chiamante.
 
+\itindend{value~result~argument}
+
 Questo requisito di accessibilità è fondamentale, infatti dei possibili
 problemi che si possono avere con il passaggio dei dati è quello di restituire
-alla funzione chiamante dei dati che sono contenuti in una
-\index{variabili!automatiche} variabile automatica.  Ovviamente quando la
-funzione ritorna la sezione dello \itindex{stack} \textit{stack} che conteneva
-la \index{variabili!automatiche} variabile automatica (si ricordi quanto detto
+alla funzione chiamante dei dati che sono contenuti in una variabile
+automatica.  Ovviamente quando la funzione ritorna la sezione dello
+\textit{stack} che conteneva la variabile automatica (si ricordi quanto detto
 in sez.~\ref{sec:proc_mem_alloc}) verrà liberata automaticamente e potrà
 essere riutilizzata all'invocazione di un'altra funzione, con le immaginabili
 conseguenze, quasi invariabilmente catastrofiche, di sovrapposizione e
@@ -2289,15 +2305,15 @@ sovrascrittura dei dati.
 
 Per questo una delle regole fondamentali della programmazione in C è che
 all'uscita di una funzione non deve restare nessun riferimento alle sue
-\index{variabili!automatiche} variabili locali. Qualora sia necessario
-utilizzare delle variabili che devono essere viste anche dalla funzione
-chiamante queste devono essere allocate esplicitamente, o in maniera statica
-usando variabili globali o dichiarate come \direct{extern},\footnote{la
-  direttiva \direct{extern} informa il compilatore che la variabile che si è
-  dichiarata in una funzione non è da considerarsi locale, ma globale, e per
-  questo allocata staticamente e visibile da tutte le funzioni dello stesso
-  programma.} o dinamicamente con una delle funzioni della famiglia
-\func{malloc}, passando opportunamente il relativo puntatore fra le funzioni.
+variabili locali. Qualora sia necessario utilizzare delle variabili che devono
+essere viste anche dalla funzione chiamante queste devono essere allocate
+esplicitamente, o in maniera statica usando variabili globali o dichiarate
+come \direct{extern},\footnote{la direttiva \direct{extern} informa il
+  compilatore che la variabile che si è dichiarata in una funzione non è da
+  considerarsi locale, ma globale, e per questo allocata staticamente e
+  visibile da tutte le funzioni dello stesso programma.} o dinamicamente con
+una delle funzioni della famiglia \func{malloc}, passando opportunamente il
+relativo puntatore fra le funzioni.
 
 
 \subsection{Il passaggio di un numero variabile di argomenti}
@@ -2358,9 +2374,8 @@ Una volta dichiarata la funzione il secondo passo è accedere ai vari argomenti
 quando la si va a definire. Gli argomenti fissi infatti hanno un loro nome, ma
 quelli variabili vengono indicati in maniera generica dalla
 \textit{ellipsis}. L'unica modalità in cui essi possono essere recuperati è
-pertanto quella sequenziale, in cui vengono estratti dallo \itindex{stack}
-\textit{stack} secondo l'ordine in cui sono stati scritti nel prototipo della
-funzione. 
+pertanto quella sequenziale, in cui vengono estratti dallo \textit{stack}
+secondo l'ordine in cui sono stati scritti nel prototipo della funzione.
 
 Per fare questo in \headfile{stdarg.h} sono definite delle macro specifiche,
 previste dallo standard ISO C89, che consentono di eseguire questa operazione.
@@ -2457,17 +2472,19 @@ argomenti e poter memorizzare una posizione durante la stessa. In questo caso
 sembrerebbe naturale copiarsi la lista degli argomenti \param{ap} con una
 semplice assegnazione ad un'altra variabile dello stesso tipo. Dato che una
 delle realizzazioni più comuni di \type{va\_list} è quella di un puntatore
-nello \itindex{stack} \textit{stack} all'indirizzo dove sono stati salvati gli
-argomenti, è assolutamente normale pensare di poter effettuare questa
-operazione.
+nello \textit{stack} all'indirizzo dove sono stati salvati gli argomenti, è
+assolutamente normale pensare di poter effettuare questa operazione.
+
+\index{tipo!opaco|(}
 
 In generale però possono esistere anche realizzazioni diverse, ed è per questo
 motivo che invece che di un semplice puntatore viene \type{va\_list} è quello
-che viene chiamato un \index{tipo!opaco} \textsl{tipo opaco}. Si chiamano così
-quei tipi di dati, in genere usati da una libreria, la cui struttura interna
-non deve essere vista dal programma chiamante (da cui deriva il nome opaco)
-che li devono utilizzare solo attraverso dalle opportune funzioni di
-gestione. 
+che viene chiamato un \textsl{tipo opaco}. Si chiamano così quei tipi di dati,
+in genere usati da una libreria, la cui struttura interna non deve essere
+vista dal programma chiamante (da cui deriva il nome opaco) che li devono
+utilizzare solo attraverso dalle opportune funzioni di gestione.
+
+\index{tipo!opaco|)}
 
 Per questo motivo una variabile di tipo \type{va\_list} non può essere
 assegnata direttamente ad un'altra variabile dello stesso tipo, ma lo standard
@@ -2556,11 +2573,11 @@ scartando l'input come errato.\footnote{a meno che, come precisa
   ecc.), che non potrebbero essere eseguite con un salto non-locale.}
 
 Tutto ciò può essere realizzato proprio con un salto non-locale; questo di
-norma viene realizzato salvando il contesto dello \itindex{stack}
-\textit{stack} nel punto in cui si vuole tornare in caso di errore, e
-ripristinandolo, in modo da tornare quando serve nella funzione da cui si era
-partiti.  La funzione che permette di salvare il contesto dello
-\itindex{stack} \textit{stack} è \funcd{setjmp}, il cui prototipo è:
+norma viene realizzato salvando il contesto dello \textit{stack} nel punto in
+cui si vuole tornare in caso di errore, e ripristinandolo, in modo da tornare
+quando serve nella funzione da cui si era partiti.  La funzione che permette
+di salvare il contesto dello \textit{stack} è \funcd{setjmp}, il cui prototipo
+è:
 
 \begin{funcproto}{ 
 \fhead{setjmp.h}
@@ -2572,22 +2589,20 @@ partiti.  La funzione che permette di salvare il contesto dello
   salvato in precedenza.}
 \end{funcproto}
   
-Quando si esegue la funzione il contesto corrente dello \itindex{stack}
-\textit{stack} viene salvato nell'argomento \param{env}, una variabile di tipo
+Quando si esegue la funzione il contesto corrente dello \textit{stack} viene
+salvato nell'argomento \param{env}, una variabile di tipo
 \type{jmp\_buf}\footnote{anche questo è un classico esempio di variabile di
-  \index{tipo!opaco} \textsl{tipo opaco}.}  che deve essere stata definita in
-precedenza. In genere le variabili di tipo \type{jmp\_buf} vengono definite
-come \index{variabili!globali} variabili globali in modo da poter essere viste
-in tutte le funzioni del programma.
+  \textsl{tipo opaco}.}  che deve essere stata definita in precedenza. In
+genere le variabili di tipo \type{jmp\_buf} vengono definite come variabili
+globali in modo da poter essere viste in tutte le funzioni del programma.
 
 Quando viene eseguita direttamente la funzione ritorna sempre zero, un valore
 diverso da zero viene restituito solo quando il ritorno è dovuto ad una
 chiamata di \func{longjmp} in un'altra parte del programma che ripristina lo
-\itindex{stack} \textit{stack} effettuando il salto non-locale. Si tenga conto
-che il contesto salvato in \param{env} viene invalidato se la funzione che ha
-chiamato \func{setjmp} ritorna, nel qual caso un successivo uso di
-\func{longjmp} può comportare conseguenze imprevedibili (e di norma fatali)
-per il processo.
+\textit{stack} effettuando il salto non-locale. Si tenga conto che il contesto
+salvato in \param{env} viene invalidato se la funzione che ha chiamato
+\func{setjmp} ritorna, nel qual caso un successivo uso di \func{longjmp} può
+comportare conseguenze imprevedibili (e di norma fatali) per il processo.
   
 Come accennato per effettuare un salto non-locale ad un punto precedentemente
 stabilito con \func{setjmp} si usa la funzione \funcd{longjmp}; il suo
@@ -2601,11 +2616,11 @@ prototipo è:
 {La funzione non ritorna.}   
 \end{funcproto}
 
-La funzione ripristina il contesto dello \itindex{stack} \textit{stack}
-salvato da una chiamata a \func{setjmp} nell'argomento \param{env}. Dopo
-l'esecuzione della funzione il programma prosegue nel codice successivo alla
-chiamata della \func{setjmp} con cui si era salvato \param{env}, che
-restituirà il valore dell'argomento \param{val} invece di zero.  Il valore
+La funzione ripristina il contesto dello \textit{stack} salvato da una
+chiamata a \func{setjmp} nell'argomento \param{env}. Dopo l'esecuzione della
+funzione il programma prosegue nel codice successivo alla chiamata della
+\func{setjmp} con cui si era salvato \param{env}, che restituirà il valore
+dell'argomento \param{val} invece di zero.  Il valore
 dell'argomento \param{val} deve essere sempre diverso da zero, se si è
 specificato 0 sarà comunque restituito 1 al suo posto.
 
@@ -2617,11 +2632,11 @@ posizione della relativa \func{setjmp}. L'altra differenza fondamentale con
 diversi livelli di funzioni annidate.
 
 L'implementazione di queste funzioni comporta alcune restrizioni dato che esse
-interagiscono direttamente con la gestione dello \itindex{stack}
-\textit{stack} ed il funzionamento del compilatore stesso. In particolare
-\func{setjmp} è implementata con una macro, pertanto non si può cercare di
-ottenerne l'indirizzo, ed inoltre le chiamate a questa funzione sono sicure
-solo in uno dei seguenti casi:
+interagiscono direttamente con la gestione dello \textit{stack} ed il
+funzionamento del compilatore stesso. In particolare \func{setjmp} è
+implementata con una macro, pertanto non si può cercare di ottenerne
+l'indirizzo, ed inoltre le chiamate a questa funzione sono sicure solo in uno
+dei seguenti casi:
 \begin{itemize*}
 \item come espressione di controllo in un comando condizionale, di selezione o
   di iterazione (come \instruction{if}, \instruction{switch} o
@@ -2640,21 +2655,19 @@ di \func{setjmp}, pertanto quest'ultima viene usualmente chiamata all'interno
 di un una istruzione \instruction{if} che permetta di distinguere i due casi.
 
 Uno dei punti critici dei salti non-locali è quello del valore delle
-variabili, ed in particolare quello delle \index{variabili!automatiche}
-variabili automatiche della funzione a cui si ritorna. In generale le
-\index{variabili!globali} variabili globali e \index{variabili!statiche}
-statiche mantengono i valori che avevano al momento della chiamata di
-\func{longjmp}, ma quelli delle \index{variabili!automatiche} variabili
-automatiche (o di quelle dichiarate \direct{register}) sono in genere
-indeterminati.
+variabili, ed in particolare quello delle variabili automatiche della funzione
+a cui si ritorna. In generale le variabili globali e statiche mantengono i
+valori che avevano al momento della chiamata di \func{longjmp}, ma quelli
+delle variabili automatiche (o di quelle dichiarate \direct{register}) sono in
+genere indeterminati.
 
 Quello che succede infatti è che i valori delle variabili che sono tenute in
 memoria manterranno il valore avuto al momento della chiamata di
 \func{longjmp}, mentre quelli tenuti nei registri del processore (che nella
 chiamata ad un'altra funzione vengono salvati nel contesto nello
-\itindex{stack} \textit{stack}) torneranno al valore avuto al momento della
-chiamata di \func{setjmp}; per questo quando si vuole avere un comportamento
-coerente si può bloccare l'ottimizzazione che porta le variabili nei registri
+\textit{stack}) torneranno al valore avuto al momento della chiamata di
+\func{setjmp}; per questo quando si vuole avere un comportamento coerente si
+può bloccare l'ottimizzazione che porta le variabili nei registri
 dichiarandole tutte come \direct{volatile}.\footnote{la direttiva
   \direct{volatile} informa il compilatore che la variabile che è dichiarata
   può essere modificata, durante l'esecuzione del nostro, da altri programmi.
@@ -2668,7 +2681,7 @@ dichiarandole tutte come \direct{volatile}.\footnote{la direttiva
 
 
 \subsection{La \textit{endianness}}
-\label{sec:sock_endianness}
+\label{sec:endianness}
 
 \itindbeg{endianness} 
 
index 2fd1924c82ecb8e777fe443a3039b244dfbaa0c7..95df51da8b917df2af12cd4042c1f2e584b4467d 100644 (file)
@@ -295,13 +295,12 @@ multitasking.\footnote{oggi questa rilevanza, con la diffusione dell'uso dei
 
 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
 il processo figlio continuano ad essere eseguiti normalmente a partire
-dall'istruzione successiva alla \func{fork}. Il processo figlio è una copia del
-padre, e riceve una copia dei \index{segmento!testo} segmenti di testo,
-\index{segmento!dati} dati e dello \itindex{stack} \textit{stack} (vedi
-sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
-padre. Si tenga presente però che la memoria è copiata e non condivisa,
-pertanto padre e figlio vedranno variabili diverse e le eventuali modifiche
-saranno totalmente indipendenti.
+dall'istruzione successiva alla \func{fork}. Il processo figlio è una copia
+del padre, e riceve una copia dei segmenti di testo, dati e dello
+\textit{stack} (vedi sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo
+stesso codice del padre. Si tenga presente però che la memoria è copiata e non
+condivisa, pertanto padre e figlio vedranno variabili diverse e le eventuali
+modifiche saranno totalmente indipendenti.
 
 Per quanto riguarda la gestione della memoria, in generale il
 \index{segmento!testo} segmento di testo, che è identico per i due processi, è
@@ -921,12 +920,12 @@ occorrerà continuare a chiamare la funzione più volte fintanto che non si è
 recuperato lo stato di terminazione di tutti quanti.
 
 Al ritorno della funzione lo stato di terminazione del figlio viene salvato
-(come \itindex{value~result~argument} \textit{value result argument}) nella
-variabile puntata da \param{status} e tutte le risorse del kernel relative al
-processo (vedi sez.~\ref{sec:proc_termination}) vengono rilasciate.  Nel caso
-un processo abbia più figli il valore di ritorno della funzione sarà impostato
-al \ids{PID} del processo di cui si è ricevuto lo stato di terminazione, cosa
-che permette di identificare qual è il figlio che è terminato.
+(come \textit{value result argument}) nella variabile puntata
+da \param{status} e tutte le risorse del kernel relative al processo (vedi
+sez.~\ref{sec:proc_termination}) vengono rilasciate.  Nel caso un processo
+abbia più figli il valore di ritorno della funzione sarà impostato al
+\ids{PID} del processo di cui si è ricevuto lo stato di terminazione, cosa che
+permette di identificare qual è il figlio che è terminato.
 
 \itindend{termination~status} 
 
@@ -1122,12 +1121,12 @@ terminazione del processo tramite il puntatore \param{status}, e se non
 interessa memorizzare lo stato si può passare un puntatore nullo. Il valore
 restituito da entrambe le funzioni dipende dall'implementazione, ma
 tradizionalmente gli 8 bit meno significativi sono riservati per memorizzare
-lo \itindex{exit~status} stato di uscita del processo, e gli altri per
-indicare il segnale che ha causato la terminazione (in caso di conclusione
-anomala), uno per indicare se è stato generato un \textit{core dump} (vedi
-sez.~\ref{sec:sig_standard}), ecc.\footnote{le definizioni esatte si possono
-  trovare in \file{<bits/waitstatus.h>} ma questo file non deve mai essere
-  usato direttamente, esso viene incluso attraverso \file{<sys/wait.h>}.}
+lo stato di uscita del processo, e gli altri per indicare il segnale che ha
+causato la terminazione (in caso di conclusione anomala), uno per indicare se
+è stato generato un \textit{core dump} (vedi sez.~\ref{sec:sig_standard}),
+ecc.\footnote{le definizioni esatte si possono trovare in
+  \file{<bits/waitstatus.h>} ma questo file non deve mai essere usato
+  direttamente, esso viene incluso attraverso \file{<sys/wait.h>}.}
 
 \begin{table}[!htb]
   \centering
@@ -1367,10 +1366,9 @@ fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
 processo chiama una di queste funzioni esso viene completamente sostituito dal
 nuovo programma, il \ids{PID} del processo non cambia, dato che non viene
 creato un nuovo processo, la funzione semplicemente rimpiazza lo
-\itindex{stack} \textit{stack}, i \index{segmento!dati} dati ed il
-\index{segmento!testo} testo del processo corrente con un nuovo programma
-letto da disco, eseguendo il \itindex{link-loader} \textit{link-loader} con
-gli effetti illustrati in sez.~\ref{sec:proc_main}.
+\textit{stack}, i dati ed il testo del processo corrente con un nuovo
+programma letto da disco, eseguendo il \textit{link-loader} con gli effetti
+illustrati in sez.~\ref{sec:proc_main}.
 
 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
 famiglia di funzioni) che possono essere usate per questo compito, in realtà
@@ -1539,9 +1537,9 @@ seguente:
   (\ids{PPID});
 \item l'\textsl{user-ID reale}, il \textsl{group-ID reale} ed i
   \textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
-\item la directory radice e la directory di lavoro corrente (vedi
-  sez.~\ref{sec:file_work_dir});
-\item la maschera di creazione dei file \itindex{umask} (\textit{umask}, vedi
+\item la directory radice (vedi sez.~\ref{sec:file_chroot}) e la directory di
+  lavoro corrente (vedi sez.~\ref{sec:file_work_dir});
+\item la maschera di creazione dei file (\textit{umask}, vedi
   sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
   sez.~\ref{sec:file_locking});
 \item il valori di \textit{nice}, le priorità real-time e le affinità di
@@ -1575,8 +1573,7 @@ seguenti proprietà non vengano preservate:
 \item le mappature dei file in memoria (vedi sez.~\ref{sec:file_memory_map});
 \item i segmenti di memoria condivisa SysV (vedi sez.~\ref{sec:ipc_sysv_shm})
   e POSIX (vedi sez.~\ref{sec:ipc_posix_shm});
-\item i \itindex{memory~locking} \textit{memory lock} (vedi
-  sez.~\ref{sec:proc_mem_lock});
+\item i \textit{memory lock} (vedi sez.~\ref{sec:proc_mem_lock});
 \item le funzioni registrate all'uscita (vedi sez.~\ref{sec:proc_atexit});
 \item i semafori e le code di messaggi POSIX (vedi
   sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq});
@@ -2100,10 +2097,9 @@ identificatori; i loro prototipi sono:
 
 Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
 nessun privilegio. I valori sono restituiti negli argomenti, che vanno
-specificati come puntatori (è un altro esempio di
-\itindex{value~result~argument} \textit{value result argument}). Si noti che
-queste funzioni sono le uniche in grado di leggere gli identificatori del
-gruppo \textit{saved}.
+specificati come puntatori (è un altro esempio di \textit{value result
+  argument}). Si noti che queste funzioni sono le uniche in grado di leggere
+gli identificatori del gruppo \textit{saved}.
 
 Infine le funzioni \func{setfsuid} e \func{setfsgid} servono per impostare gli
 identificatori del gruppo \textit{filesystem} che sono usati da Linux per il
@@ -2209,10 +2205,10 @@ specificato per nome (e non con un \ids{UID}) nella stringa passata con
 l'argomento \param{user}. Ritorna poi nel vettore \param{groups} la lista dei
 \ids{GID} dei gruppi a cui l'utente appartiene. Si noti che \param{ngroups},
 che in ingresso deve indicare la dimensione di \param{group}, è passato come
-\itindex{value~result~argument} \textit{value result argument} perché, qualora
-il valore specificato sia troppo piccolo, la funzione ritorna $-1$, passando
-comunque indietro il numero dei gruppi trovati, in modo da poter ripetere la
-chiamata con un vettore di dimensioni adeguate.
+\textit{value result argument} perché, qualora il valore specificato sia
+troppo piccolo, la funzione ritorna $-1$, passando comunque indietro il numero
+dei gruppi trovati, in modo da poter ripetere la chiamata con un vettore di
+dimensioni adeguate.
 
 Infine per impostare i gruppi supplementari di un processo ci sono due
 funzioni, che possono essere usate solo se si hanno i privilegi di
@@ -2681,12 +2677,11 @@ un processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
   \textit{real-time} (o nel caso di Adeos gestiti dalle code del nano-kernel),
   in modo da poterli controllare direttamente qualora ci sia la necessità di
   avere un processo con priorità più elevata di un \textit{interrupt
-    handler}.} mentre con l'incorrere in un \itindex{page~fault} \textit{page
-  fault} si possono avere ritardi non previsti.  Se l'ultimo problema può
-essere aggirato attraverso l'uso delle funzioni di controllo della memoria
-virtuale (vedi sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può
-comportare ritardi non prevedibili riguardo ai tempi di esecuzione di
-qualunque processo.
+    handler}.} mentre con l'incorrere in un \textit{page fault} si possono
+avere ritardi non previsti.  Se l'ultimo problema può essere aggirato
+attraverso l'uso delle funzioni di controllo della memoria virtuale (vedi
+sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può comportare
+ritardi non prevedibili riguardo ai tempi di esecuzione di qualunque processo.
 
 Nonostante questo, ed in particolare con una serie di miglioramenti che sono
 stati introdotti nello sviluppo del kernel,\footnote{in particolare a partire
@@ -3186,13 +3181,13 @@ permette di identificare un insieme di processori. Il dato è normalmente una
 maschera binaria: nei casi più comuni potrebbe bastare un intero a 32 bit, in
 cui ogni bit corrisponde ad un processore, ma oggi esistono architetture in
 cui questo numero può non essere sufficiente, e per questo è stato creato
-questo \index{tipo!opaco} tipo opaco e una interfaccia di gestione che
-permette di usare a basso livello un tipo di dato qualunque rendendosi
-indipendenti dal numero di bit e dalla loro disposizione.  Per questo le
-funzioni richiedono anche che oltre all'insieme di processori si indichi anche
-la dimensione dello stesso con l'argomento \param{setsize}, per il quale, se
-non si usa l'allocazione dinamica che vedremo a breve, ed è in genere
-sufficiente passare il valore \code{sizeof(cpu\_set\_t)}.
+questo tipo opaco e una interfaccia di gestione che permette di usare a basso
+livello un tipo di dato qualunque rendendosi indipendenti dal numero di bit e
+dalla loro disposizione.  Per questo le funzioni richiedono anche che oltre
+all'insieme di processori si indichi anche la dimensione dello stesso con
+l'argomento \param{setsize}, per il quale, se non si usa l'allocazione
+dinamica che vedremo a breve, ed è in genere sufficiente passare il valore
+\code{sizeof(cpu\_set\_t)}.
 
 L'interfaccia di gestione degli insiemi di processori, oltre alla definizione
 del tipo \type{cpu\_set\_t}, prevede una serie di macro di preprocessore per
@@ -3667,18 +3662,18 @@ momento:\footnote{alla stesura di questa sezione, cioè con il kernel 3.2.}
   lo stato corrente del flag che controlla la effettiva generazione dei
   \textit{core dump}. Introdotta a partire dal kernel 2.3.20.
 
-\item[\const{PR\_SET\_ENDIAN}] Imposta la \itindex{endianness}
-  \textit{endianness} del processo chiamante secondo il valore fornito
-  in \param{arg2}. I valori possibili sono sono: \const{PR\_ENDIAN\_BIG}
-  (\textit{big endian}), \const{PR\_ENDIAN\_LITTLE} (\textit{little endian}),
-  \const{PR\_ENDIAN\_PPC\_LITTLE} (lo pseudo \textit{little endian} del
+\item[\const{PR\_SET\_ENDIAN}] Imposta la \textit{endianness} del processo
+  chiamante secondo il valore fornito in \param{arg2}. I valori possibili sono
+  sono: \const{PR\_ENDIAN\_BIG} (\textit{big endian}),
+  \const{PR\_ENDIAN\_LITTLE} (\textit{little endian}), e
+  \const{PR\_ENDIAN\_PPC\_LITTLE} (lo pseudo \textit{little endian} del
   PowerPC). Introdotta a partire dal kernel 2.6.18, solo per architettura
   PowerPC.
 
-\item[\const{PR\_GET\_ENDIAN}] Ottiene il valore della \itindex{endianness}
-  \textit{endianness} del processo chiamante, salvato sulla variabile puntata
-  da \param{arg2} che deve essere passata come di tipo ``\ctyp{int
-    *}''. Introdotta a partire dal kernel 2.6.18, solo su PowerPC.
+\item[\const{PR\_GET\_ENDIAN}] Ottiene il valore della \textit{endianness} del
+  processo chiamante, salvato sulla variabile puntata da \param{arg2} che deve
+  essere passata come di tipo ``\ctyp{int *}''. Introdotta a partire dal
+  kernel 2.6.18, solo su PowerPC.
 
 \item[\const{PR\_SET\_FPEMU}] Imposta i bit di controllo per l'emulazione
   della virgola mobile su architettura ia64, secondo il valore
@@ -3979,14 +3974,14 @@ spazio separato dagli altri, che costituisce poi quello che viene chiamato un
 La \textit{system call} richiede soltanto due argomenti: il
 primo, \param{flags}, consente di controllare le modalità di creazione del
 nuovo \textit{task}, il secondo, \param{child\_stack}, imposta l'indirizzo
-dello \itindex{stack} \textit{stack} per il nuovo \textit{task}, e deve essere
-indicato quando si intende creare un \textit{thread}. L'esecuzione del
-programma creato da \func{sys\_clone} riprende, come per \func{fork}, da
-dopo l'esecuzione della stessa.
-
-La necessità di avere uno \itindex{stack} \textit{stack} alternativo c'è solo
-quando si intende creare un \textit{thread}, in tal caso infatti il nuovo
-\textit{task} vede esattamente la stessa memoria del \textit{task}
+dello \textit{stack} per il nuovo \textit{task}, e deve essere indicato quando
+si intende creare un \textit{thread}. L'esecuzione del programma creato da
+\func{sys\_clone} riprende, come per \func{fork}, da dopo l'esecuzione della
+stessa.
+
+La necessità di avere uno \textit{stack} alternativo c'è solo quando si
+intende creare un \textit{thread}, in tal caso infatti il nuovo \textit{task}
+vede esattamente la stessa memoria del \textit{task}
 ``\textsl{padre}'',\footnote{in questo caso per padre si intende semplicemente
   il \textit{task} che ha eseguito \func{sys\_clone} rispetto al \textit{task}
   da essa creato, senza nessuna delle implicazioni che il concetto ha per i
@@ -4113,7 +4108,13 @@ elenco, che illustra quelle attualmente disponibili:\footnote{si fa
   illustreremo in dettaglio in sez.~\ref{sec:file_shared_access}.
 
 \item[\const{CLONE\_FS}] se questo flag viene impostato il nuovo processo
-  condividerà con il padre le informazioni 
+  condividerà con il padre le informazioni relative all'albero dei file, ed in
+  particolare avrà la stessa radice (vedi sez.~\ref{sec:file_chroot}), la
+  stessa directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) e la stessa
+  \textit{umask} (sez.~\ref{sec:file_perm_management}). Una modifica di una
+  qualunque di queste caratteristiche in un processo, avrà effetto anche
+  sull'altro. Se assente il nuovo processo riceverà una copia delle precedenti
+  informazioni, che saranno così indipendenti per i due processi.
 
 \item[\const{CLONE\_IO}]
 \item[\const{CLONE\_NEWIPC}]
@@ -4302,12 +4303,16 @@ gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
 condivisa. 
 
+\index{sezione~critica|(}
+
 In questi casi, se non si dispone della possibilità di eseguire atomicamente
 le operazioni necessarie, occorre che quelle parti di codice in cui si
-compiono le operazioni sulle risorse condivise (le cosiddette
-\index{sezione~critica} \textsl{sezioni critiche}) del programma, siano
-opportunamente protette da meccanismi di sincronizzazione (torneremo su queste
-problematiche di questo tipo in cap.~\ref{cha:IPC}).
+compiono le operazioni sulle risorse condivise, quelle che in genere vengono
+denominate ``\textsl{sezioni critiche}'' del programma, siano opportunamente
+protette da meccanismi di sincronizzazione (vedremo alcune problematiche di
+questo tipo in cap.~\ref{cha:IPC}).
+
+\index{sezione~critica|)}
 
 Nel caso dei \textit{thread} invece la situazione è molto più delicata e
 sostanzialmente qualunque accesso in memoria (a buffer, variabili o altro) può
@@ -4317,9 +4322,11 @@ con estrema attenzione l'uso delle variabili ed utilizzare i vari meccanismi
 di sincronizzazione che anche in questo caso sono disponibili (torneremo su
 queste problematiche di questo tipo in cap.~\ref{sez:thread_xxx})
 
-\itindbeg{deadlock} Un caso particolare di \textit{race condition} sono poi i
-cosiddetti \textit{deadlock} (traducibile in \textsl{condizione di stallo}),
-che particolarmente gravi in quanto comportano spesso il blocco completo di un
+\itindbeg{deadlock} 
+
+Un caso particolare di \textit{race condition} sono poi i cosiddetti
+\textit{deadlock} (traducibile in \textsl{condizione di stallo}), che
+particolarmente gravi in quanto comportano spesso il blocco completo di un
 servizio, e non il fallimento di una singola operazione. Per definizione un
 \textit{deadlock} è una situazione in cui due o più processi non sono più in
 grado di proseguire perché ciascuno aspetta il risultato di una operazione che
@@ -4350,19 +4357,16 @@ eseguire in maniera atomica le operazioni necessarie.
 
 Si dice \textsl{rientrante} una funzione che può essere interrotta in
 qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
-un altro \itindex{thread} \textit{thread} di esecuzione senza che questo
-comporti nessun problema nell'esecuzione della stessa. La problematica è
-comune nella programmazione \itindex{thread} \textit{multi-thread}, ma si
-hanno gli stessi problemi quando si vogliono chiamare delle funzioni
-all'interno dei gestori dei segnali.
+un altro \textit{thread} di esecuzione senza che questo comporti nessun
+problema nell'esecuzione della stessa. La problematica è comune nella
+programmazione \textit{multi-thread}, ma si hanno gli stessi problemi quando
+si vogliono chiamare delle funzioni all'interno dei gestori dei segnali.
 
 Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
-queste infatti vengono allocate nello \itindex{stack} \textit{stack}, ed
-un'altra invocazione non fa altro che allocarne un'altra copia. Una funzione
-può non essere rientrante quando opera su memoria che non è nello
-\itindex{stack} \textit{stack}.  Ad esempio una funzione non è mai rientrante
-se usa una \index{variabili!globali} variabile globale o
-\index{variabili!statiche} statica.
+queste infatti vengono allocate nello \textit{stack}, ed un'altra invocazione
+non fa altro che allocarne un'altra copia. Una funzione può non essere
+rientrante quando opera su memoria che non è nello \textit{stack}.  Ad esempio
+una funzione non è mai rientrante se usa una variabile globale o statica.
 
 Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
 cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
@@ -4375,11 +4379,11 @@ se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
 parte del programmatore.
 
 In genere le funzioni di libreria non sono rientranti, molte di esse ad
-esempio utilizzano \index{variabili!statiche} variabili statiche, la
-\acr{glibc} però mette a disposizione due macro di compilatore,
-\macro{\_REENTRANT} e \macro{\_THREAD\_SAFE}, la cui definizione attiva le
-versioni rientranti di varie funzioni di libreria, che sono identificate
-aggiungendo il suffisso \code{\_r} al nome della versione normale.
+esempio utilizzano variabili statiche, la \acr{glibc} però mette a
+disposizione due macro di compilatore, \macro{\_REENTRANT} e
+\macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
+varie funzioni di libreria, che sono identificate aggiungendo il suffisso
+\code{\_r} al nome della versione normale.
 
 \index{funzioni!rientranti|)}
 
index dd98e69ffd74cc868a830fa03e263e08ab7c1615..10cc5cf12f4e71b63d5de7ece69c56e7e3a84d25 100644 (file)
@@ -1011,8 +1011,8 @@ funzione è originaria di BSD e per utilizzarla deve essere definito
 La sola differenza con \func{syslog} è quella di prendere invece di una lista
 di argomenti esplicita un unico argomento finale passato nella forma di una
 \macro{va\_list}; la funzione risulta utile qualora si ottengano gli argomenti
-dalla invocazione di un'altra funzione \index{funzioni!variadic}
-\textit{variadic} (si rammenti quanto visto in sez.~\ref{sec:proc_variadic}).
+dalla invocazione di un'altra funzione \textit{variadic} (si ricordi quanto
+visto in sez.~\ref{sec:proc_variadic}).
 
 Per semplificare la gestione della scelta del livello di priorità a partire
 dal quale si vogliono registrare i messaggi, le funzioni di gestione
index b26cddf79438b76ba0d4447d92539bcaf45c3d1f..493bf4460479e0a99b737de9537db9535557c400 100644 (file)
@@ -477,20 +477,20 @@ affrontata nei paragrafi successivi.
 \label{sec:sig_prog_error}
 
 Questi segnali sono generati quando il sistema, o in certi casi direttamente
-l'hardware (come per i \itindex{page~fault} \textit{page fault} non validi o
-le eccezioni del processore) rileva un qualche errore insanabile nel programma
-in esecuzione. In generale la generazione di questi segnali significa che il
+l'hardware (come per i \textit{page fault} non validi o le eccezioni del
+processore) rileva un qualche errore insanabile nel programma in
+esecuzione. In generale la generazione di questi segnali significa che il
 programma ha dei gravi problemi (ad esempio ha dereferenziato un puntatore non
 valido o ha eseguito una operazione aritmetica proibita) e l'esecuzione non
 può essere proseguita.
 
 In genere si intercettano questi segnali per permettere al programma di
 terminare in maniera pulita, ad esempio per ripristinare le impostazioni della
-console o eliminare i \index{file!di lock} file di lock prima dell'uscita.  In
-questo caso il gestore deve concludersi ripristinando l'azione predefinita e
-rialzando il segnale, in questo modo il programma si concluderà senza effetti
-spiacevoli, ma riportando lo stesso stato di uscita che avrebbe avuto se il
-gestore non ci fosse stato.
+console o eliminare i file di lock prima dell'uscita.  In questo caso il
+gestore deve concludersi ripristinando l'azione predefinita e rialzando il
+segnale, in questo modo il programma si concluderà senza effetti spiacevoli,
+ma riportando lo stesso stato di uscita che avrebbe avuto se il gestore non ci
+fosse stato.
 
 L'azione predefinita per tutti questi segnali è causare la terminazione del
 processo che li ha causati. In genere oltre a questo il segnale provoca pure
@@ -517,10 +517,10 @@ terminazione.  Questi segnali sono:
   file eseguibile è corrotto o si stanno cercando di eseguire dei dati.
   Quest'ultimo caso può accadere quando si passa un puntatore sbagliato al
   posto di un puntatore a funzione, o si eccede la scrittura di un vettore di
-  una variabile locale, andando a corrompere lo \itindex{stack}
-  \textit{stack}. Lo stesso segnale viene generato in caso di overflow dello
-  \itindex{stack} \textit{stack} o di problemi nell'esecuzione di un gestore.
-  Se il gestore ritorna il comportamento del processo è indefinito.
+  una variabile locale, andando a corrompere lo \textit{stack}. Lo stesso
+  segnale viene generato in caso di overflow dello \textit{stack} o di
+  problemi nell'esecuzione di un gestore.  Se il gestore ritorna il
+  comportamento del processo è indefinito.
 
 \item[\signal{SIGSEGV}] Il nome deriva da \itindex{segment~violation}
   \textit{segment violation}, e significa che il programma sta cercando di
@@ -535,9 +535,9 @@ terminazione.  Questi segnali sono:
   \signal{SIGSEGV} questo è un segnale che viene generato di solito quando si
   dereferenzia un puntatore non inizializzato, la differenza è che
   \signal{SIGSEGV} indica un accesso non permesso su un indirizzo esistente
-  (al di fuori dallo \itindex{heap} \textit{heap} o dallo \itindex{stack}
-  \textit{stack}), mentre \signal{SIGBUS} indica l'accesso ad un indirizzo non
-  valido, come nel caso di un puntatore non allineato.
+  (al di fuori dallo \textit{heap} o dallo \textit{stack}), mentre
+  \signal{SIGBUS} indica l'accesso ad un indirizzo non valido, come nel caso
+  di un puntatore non allineato.
 
 \item[\signal{SIGABRT}] Il nome deriva da \textit{abort}. Il segnale indica
   che il programma stesso ha rilevato un errore che viene riportato chiamando
@@ -860,9 +860,9 @@ stringa passata nell'argomento \param{s}, seguita dal carattere di due punti
 ed una descrizione del segnale indicato dall'argomento \param{sig}. 
 
 Una modalità alternativa per utilizzare le descrizioni restituite da
-\func{strsignal} e \func{psignal} è quello di usare la
-\index{variabili!globali} variabile globale \var{sys\_siglist}, che è definita
-in \headfile{signal.h} e può essere acceduta con la dichiarazione:
+\func{strsignal} e \func{psignal} è quello di usare la variabile globale
+\var{sys\_siglist}, che è definita in \headfile{signal.h} e può essere
+acceduta con la dichiarazione:
 \includecodesnip{listati/siglist.c}
 
 L'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
@@ -1836,11 +1836,11 @@ da controllare nel corpo principale del programma, con un codice del tipo di
 quello riportato in fig.~\ref{fig:sig_event_wrong}.
 
 La logica del programma è quella di far impostare al gestore (\texttt{\small
-  14--19}) una \index{variabili!globali} variabile globale, preventivamente
-inizializzata nel programma principale, ad un diverso valore. In questo modo
-dal corpo principale del programma si potrà determinare, osservandone il
-contenuto di detta variabile, l'occorrenza o meno del segnale, ed eseguire le
-azioni conseguenti (\texttt{\small 6--11}) relative.
+  14--19}) una variabile globale, preventivamente inizializzata nel programma
+principale, ad un diverso valore. In questo modo dal corpo principale del
+programma si potrà determinare, osservandone il contenuto di detta variabile,
+l'occorrenza o meno del segnale, ed eseguire le azioni conseguenti
+(\texttt{\small 6--11}) relative.
 
 \begin{figure}[!htbp]
   \footnotesize\centering
@@ -2114,9 +2114,8 @@ tab.~\ref{tab:sig_sa_flag}.
     \const{SA\_ONESHOT}  & Nome obsoleto e sinonimo non standard di
                            \const{SA\_RESETHAND}, non deve essere più
                            utilizzato.\\ 
-    \const{SA\_ONSTACK}  & Stabilisce l'uso di uno \itindex{stack} 
-                           \textit{stack} alternativo per l'esecuzione del
-                           gestore (vedi
+    \const{SA\_ONSTACK}  & Stabilisce l'uso di uno \textit{stack} alternativo
+                           per l'esecuzione del gestore (vedi
                            sez.~\ref{sec:sig_specific_features}).\\  
     \const{SA\_RESETHAND}& Ristabilisce l'azione per il segnale al valore 
                            predefinito una volta che il gestore è stato
@@ -2356,12 +2355,11 @@ kernel, dove in certi casi le ottimizzazioni dal compilatore, tarate per l'uso
 in \textit{user space}, non sono sempre adatte.
 
 In tal caso infatti le istruzioni per creare un nuovo frame nello
-\itindex{stack} \textit{stack} per chiamare la funzione costituirebbero una
-parte rilevante del codice, appesantendo inutilmente il programma.
-Originariamente questo comportamento veniva ottenuto con delle macro, ma
-queste hanno tutta una serie di problemi di sintassi nel passaggio degli
-argomenti (si veda ad esempio \cite{PratC}) che in questo modo possono essere
-evitati.
+\textit{stack} per chiamare la funzione costituirebbero una parte rilevante
+del codice, appesantendo inutilmente il programma.  Originariamente questo
+comportamento veniva ottenuto con delle macro, ma queste hanno tutta una serie
+di problemi di sintassi nel passaggio degli argomenti (si veda ad esempio
+\cite{PratC}) che in questo modo possono essere evitati.
 
 
 
@@ -2449,24 +2447,23 @@ quell'indirizzo.
 \end{table}
 
 In questo modo diventa possibile proteggere delle sezioni di codice bloccando
-l'insieme di segnali voluto per poi riabilitarli alla fine della
-\index{sezione~critica} sezione critica. La funzione permette di risolvere
-problemi come quelli mostrati in fig.~\ref{fig:sig_event_wrong}, proteggendo
-la sezione fra il controllo del flag e la sua cancellazione.  La funzione può
-essere usata anche all'interno di un gestore, ad esempio per riabilitare la
-consegna del segnale che l'ha invocato, in questo caso però occorre ricordare
-che qualunque modifica alla maschera dei segnali viene perduta al ritorno
-dallo stesso.
+l'insieme di segnali voluto per poi riabilitarli alla fine della sezione
+critica. La funzione permette di risolvere problemi come quelli mostrati in
+fig.~\ref{fig:sig_event_wrong}, proteggendo la sezione fra il controllo del
+flag e la sua cancellazione.  La funzione può essere usata anche all'interno
+di un gestore, ad esempio per riabilitare la consegna del segnale che l'ha
+invocato, in questo caso però occorre ricordare che qualunque modifica alla
+maschera dei segnali viene perduta al ritorno dallo stesso.
 
 Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
-dei casi di \itindex{race~condition} \textit{race condition} restano aperte
-alcune possibilità legate all'uso di \func{pause}.  Il caso è simile a quello
-del problema illustrato nell'esempio di fig.~\ref{fig:sig_sleep_incomplete}, e
-cioè la possibilità che il processo riceva il segnale che si intende usare per
-uscire dallo stato di attesa invocato con \func{pause} immediatamente prima
-dell'esecuzione di quest'ultima. Per poter effettuare atomicamente la modifica
-della maschera dei segnali (di solito attivandone uno specifico) insieme alla
-sospensione del processo lo standard POSIX ha previsto la funzione di sistema
+dei casi di \textit{race condition} restano aperte alcune possibilità legate
+all'uso di \func{pause}.  Il caso è simile a quello del problema illustrato
+nell'esempio di fig.~\ref{fig:sig_sleep_incomplete}, e cioè la possibilità che
+il processo riceva il segnale che si intende usare per uscire dallo stato di
+attesa invocato con \func{pause} immediatamente prima dell'esecuzione di
+quest'ultima. Per poter effettuare atomicamente la modifica della maschera dei
+segnali (di solito attivandone uno specifico) insieme alla sospensione del
+processo lo standard POSIX ha previsto la funzione di sistema
 \funcd{sigsuspend}, il cui prototipo è:
 
 \begin{funcproto}{
@@ -2641,11 +2638,10 @@ ulteriori funzioni in fig.~\ref{fig:sig_safe_functions_posix_2008}.
 Per questo motivo è opportuno mantenere al minimo indispensabile le operazioni
 effettuate all'interno di un gestore di segnali, qualora si debbano compiere
 operazioni complesse è sempre preferibile utilizzare la tecnica in cui si usa
-il gestore per impostare il valore di una qualche \index{variabili!globali}
-variabile globale, e poi si eseguono le operazioni complesse nel programma
-verificando (con tutti gli accorgimenti visti in precedenza) il valore di
-questa variabile tutte le volte che si è rilevata una interruzione dovuta ad
-un segnale.
+il gestore per impostare il valore di una qualche variabile globale, e poi si
+eseguono le operazioni complesse nel programma verificando (con tutti gli
+accorgimenti visti in precedenza) il valore di questa variabile tutte le volte
+che si è rilevata una interruzione dovuta ad un segnale.
 
 
 \section{Funzionalità avanzate}
@@ -3676,13 +3672,14 @@ dato che essa può solo assicurare che un segnale è stato inviato, dato che
 escluderne l'avvenuto invio al momento della chiamata non significa nulla
 rispetto a quanto potrebbe essere in un qualunque momento successivo.
 
+\itindbeg{stack} 
+
 Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità
-di usare uno \itindex{stack} \textit{stack} alternativo per i segnali; è cioè
-possibile fare usare al sistema un altro \itindex{stack} \textit{stack}
-(invece di quello relativo al processo, vedi sez.~\ref{sec:proc_mem_layout})
-solo durante l'esecuzione di un gestore.  L'uso di uno \textit{stack}
-alternativo è del tutto trasparente ai gestori, occorre però seguire una certa
-procedura:
+di usare uno \textit{stack} alternativo per i segnali; è cioè possibile fare
+usare al sistema un altro \textit{stack} (invece di quello relativo al
+processo, vedi sez.~\ref{sec:proc_mem_layout}) solo durante l'esecuzione di un
+gestore.  L'uso di uno \textit{stack} alternativo è del tutto trasparente ai
+gestori, occorre però seguire una certa procedura:
 \begin{enumerate*}
 \item allocare un'area di memoria di dimensione sufficiente da usare come
   \textit{stack} alternativo;
@@ -3698,18 +3695,18 @@ In genere il primo passo viene effettuato allocando un'opportuna area di
 memoria con \code{malloc}; in \headfile{signal.h} sono definite due costanti,
 \const{SIGSTKSZ} e \const{MINSIGSTKSZ}, che possono essere utilizzate per
 allocare una quantità di spazio opportuna, in modo da evitare overflow. La
-prima delle due è la dimensione canonica per uno \itindex{stack}
-\textit{stack} di segnali e di norma è sufficiente per tutti gli usi normali.
+prima delle due è la dimensione canonica per uno \textit{stack} di segnali e
+di norma è sufficiente per tutti gli usi normali.
 
 La seconda è lo spazio che occorre al sistema per essere in grado di lanciare
 il gestore e la dimensione di uno \textit{stack} alternativo deve essere
 sempre maggiore di questo valore. Quando si conosce esattamente quanto è lo
 spazio necessario al gestore gli si può aggiungere questo valore per allocare
-uno \itindex{stack} \textit{stack} di dimensione sufficiente.
+uno \textit{stack} di dimensione sufficiente.
 
-Come accennato, per poter essere usato, lo \itindex{stack} \textit{stack} per
-i segnali deve essere indicato al sistema attraverso la funzione
-\funcd{sigaltstack}; il suo prototipo è:
+Come accennato, per poter essere usato, lo \textit{stack} per i segnali deve
+essere indicato al sistema attraverso la funzione \funcd{sigaltstack}; il suo
+prototipo è:
 
 \begin{funcproto}{
 \fhead{signal.h}
@@ -3735,8 +3732,8 @@ i segnali deve essere indicato al sistema attraverso la funzione
 La funzione prende come argomenti puntatori ad una struttura di tipo
 \var{stack\_t}, definita in fig.~\ref{fig:sig_stack_t}. I due valori
 \param{ss} e \param{oss}, se non nulli, indicano rispettivamente il nuovo
-\itindex{stack} \textit{stack} da installare e quello corrente (che viene
-restituito dalla funzione per un successivo ripristino).
+\textit{stack} da installare e quello corrente (che viene restituito dalla
+funzione per un successivo ripristino).
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -3749,35 +3746,35 @@ restituito dalla funzione per un successivo ripristino).
 \end{figure}
 
 Il campo \var{ss\_sp} di \struct{stack\_t} indica l'indirizzo base dello
-\itindex{stack} \textit{stack}, mentre \var{ss\_size} ne indica la dimensione;
-il campo \var{ss\_flags} invece indica lo stato dello \textit{stack}.
-Nell'indicare un nuovo \textit{stack} occorre inizializzare \var{ss\_sp} e
-\var{ss\_size} rispettivamente al puntatore e alla dimensione della memoria
-allocata, mentre \var{ss\_flags} deve essere nullo.  Se invece si vuole
-disabilitare uno \textit{stack} occorre indicare \const{SS\_DISABLE} come
-valore di \var{ss\_flags} e gli altri valori saranno ignorati.
+\textit{stack}, mentre \var{ss\_size} ne indica la dimensione; il campo
+\var{ss\_flags} invece indica lo stato dello \textit{stack}.  Nell'indicare un
+nuovo \textit{stack} occorre inizializzare \var{ss\_sp} e \var{ss\_size}
+rispettivamente al puntatore e alla dimensione della memoria allocata, mentre
+\var{ss\_flags} deve essere nullo.  Se invece si vuole disabilitare uno
+\textit{stack} occorre indicare \const{SS\_DISABLE} come valore di
+\var{ss\_flags} e gli altri valori saranno ignorati.
 
 Se \param{oss} non è nullo verrà restituito dalla funzione indirizzo e
-dimensione dello \itindex{stack} \textit{stack} corrente nei relativi campi,
-mentre \var{ss\_flags} potrà assumere il valore \const{SS\_ONSTACK} se il
-processo è in esecuzione sullo \textit{stack} alternativo (nel qual caso non è
-possibile cambiarlo) e \const{SS\_DISABLE} se questo non è abilitato.
-
-In genere si installa uno \itindex{stack} \textit{stack} alternativo per i
-segnali quando si teme di avere problemi di esaurimento dello \textit{stack}
-standard o di superamento di un limite (vedi
-sez.~\ref{sec:sys_resource_limit}) imposto con chiamate del tipo
-\code{setrlimit(RLIMIT\_STACK, \&rlim)}.  In tal caso infatti si avrebbe un
-segnale di \signal{SIGSEGV}, che potrebbe essere gestito soltanto avendo
-abilitato uno \itindex{stack} \textit{stack} alternativo.
+dimensione dello \textit{stack} corrente nei relativi campi, mentre
+\var{ss\_flags} potrà assumere il valore \const{SS\_ONSTACK} se il processo è
+in esecuzione sullo \textit{stack} alternativo (nel qual caso non è possibile
+cambiarlo) e \const{SS\_DISABLE} se questo non è abilitato.
+
+In genere si installa uno \textit{stack} alternativo per i segnali quando si
+teme di avere problemi di esaurimento dello \textit{stack} standard o di
+superamento di un limite (vedi sez.~\ref{sec:sys_resource_limit}) imposto con
+chiamate del tipo \code{setrlimit(RLIMIT\_STACK, \&rlim)}.  In tal caso
+infatti si avrebbe un segnale di \signal{SIGSEGV}, che potrebbe essere gestito
+soltanto avendo abilitato uno \textit{stack} alternativo.
 
 Si tenga presente che le funzioni chiamate durante l'esecuzione sullo
 \textit{stack} alternativo continueranno ad usare quest'ultimo, che, al
-contrario di quanto avviene per lo \itindex{stack} \textit{stack} ordinario
-dei processi, non si accresce automaticamente (ed infatti eccederne le
-dimensioni può portare a conseguenze imprevedibili).  Si ricordi infine che
-una chiamata ad una funzione della famiglia \func{exec} cancella ogni
-\textit{stack} alternativo.
+contrario di quanto avviene per lo \textit{stack} ordinario dei processi, non
+si accresce automaticamente (ed infatti eccederne le dimensioni può portare a
+conseguenze imprevedibili).  Si ricordi infine che una chiamata ad una
+funzione della famiglia \func{exec} cancella ogni \textit{stack} alternativo.
+
+\itindend{stack} 
 
 Abbiamo visto in fig.~\ref{fig:sig_sleep_incomplete} come si possa usare
 \func{longjmp} per uscire da un gestore rientrando direttamente nel corpo
@@ -3814,19 +3811,17 @@ prototipi sono:
 \end{funcproto}
 
 Le due funzioni prendono come primo argomento la variabile su cui viene
-salvato il contesto dello \itindex{stack} \textit{stack} per permettere il
-\index{salto~non-locale} salto non-locale; nel caso specifico essa è di tipo
-\type{sigjmp\_buf}, e non \type{jmp\_buf} come per le analoghe di
-sez.~\ref{sec:proc_longjmp} in quanto in questo caso viene salvata anche la
-maschera dei segnali. 
+salvato il contesto dello \textit{stack} per permettere il salto non-locale;
+nel caso specifico essa è di tipo \type{sigjmp\_buf}, e non \type{jmp\_buf}
+come per le analoghe di sez.~\ref{sec:proc_longjmp} in quanto in questo caso
+viene salvata anche la maschera dei segnali.
 
 Nel caso di \func{sigsetjmp}, se si specifica un valore di \param{savesigs}
 diverso da zero la maschera dei valori verrà salvata in \param{env} insieme al
-contesto dello \itindex{stack} \textit{stack} usato per il salto non
-locale. Se così si è fatto la maschera dei segnali verrà ripristinata in una
-successiva chiamata a \func{siglongjmp}. Quest'ultima, a parte l'uso di un
-valore di \param{env} di tipo \type{sigjmp\_buf}, è assolutamente identica a
-\func{longjmp}.
+contesto dello \textit{stack} usato per il salto non locale. Se così si è
+fatto la maschera dei segnali verrà ripristinata in una successiva chiamata a
+\func{siglongjmp}. Quest'ultima, a parte l'uso di un valore di \param{env} di
+tipo \type{sigjmp\_buf}, è assolutamente identica a \func{longjmp}.
 
 
 % TODO: se e quando si troverà un argomento adeguato inserire altre funzioni
index 196c410f98fee1a413be763fa9b0355f75557eb5..429fdecc17d973cd142c9ff6bace81e5ce9b94c8 100644 (file)
@@ -828,10 +828,10 @@ lunghezza di questo buffer devono essere indicati con gli argomenti
 \param{buf} e \param{buflen}.
 
 Gli ultimi due argomenti vengono utilizzati per avere indietro i risultati
-come \itindex{value~result~argument} \textit{value result argument}, si deve
-specificare l'indirizzo della variabile su cui la funzione dovrà salvare il
-codice di errore con \param{h\_errnop} e quello su cui dovrà salvare il
-puntatore che si userà per accedere i dati con \param{result}.
+come \textit{value result argument}, si deve specificare l'indirizzo della
+variabile su cui la funzione dovrà salvare il codice di errore
+con \param{h\_errnop} e quello su cui dovrà salvare il puntatore che si userà
+per accedere i dati con \param{result}.
 
 In caso di successo entrambe le funzioni restituiscono un valore nullo,
 altrimenti restituiscono un codice di errore negativo e all'indirizzo puntato
@@ -1263,13 +1263,12 @@ TCP o UDP) che questi possono utilizzare.
 
 Come ultimo argomento in \param{res} deve essere passato un puntatore ad una
 variabile (di tipo puntatore ad una struttura \struct{addrinfo}) che verrà
-utilizzata dalla funzione per riportare (come \itindex{value~result~argument}
-\textit{value result argument}) i propri risultati. La funzione infatti è
-rientrante, ed alloca autonomamente tutta la memoria necessaria in cui
-verranno riportati i risultati della risoluzione.  La funzione scriverà
-all'indirizzo puntato da \param{res} il puntatore iniziale ad una
-\itindex{linked~list} \textit{linked list} di strutture di tipo
-\struct{addrinfo} contenenti tutte le informazioni ottenute.
+utilizzata dalla funzione per riportare (come \textit{value result argument})
+i propri risultati. La funzione infatti è rientrante, ed alloca autonomamente
+tutta la memoria necessaria in cui verranno riportati i risultati della
+risoluzione.  La funzione scriverà all'indirizzo puntato da \param{res} il
+puntatore iniziale ad una \itindex{linked~list} \textit{linked list} di
+strutture di tipo \struct{addrinfo} contenenti tutte le informazioni ottenute.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -1753,7 +1752,7 @@ valore del relativo puntatore precedentemente (\texttt{\small 17}) salvato.
 Si noti come per la funzione sia del tutto irrilevante se la struttura
 ritornata contiene indirizzi IPv6 o IPv4, in quanto si fa uso direttamente dei
 dati relativi alle strutture degli indirizzi di \struct{addrinfo} che sono
-\index{tipo!opaco} opachi rispetto all'uso della funzione \func{connect}.
+opachi rispetto all'uso della funzione \func{connect}.
 
 \begin{figure}[!htbp]
   \footnotesize \centering
@@ -1993,12 +1992,11 @@ di \func{setsockopt}, anche se non è detto che tutte le opzioni siano definite
 per entrambe le funzioni. In questo caso \param{optval} viene usato per
 ricevere le informazioni ed indica l'indirizzo a cui andranno scritti i dati
 letti dal socket, infine \param{optlen} diventa un puntatore ad una variabile
-che viene usata come \itindex{value~result~argument} \textit{value result
-  argument} per indicare, prima della chiamata della funzione, la lunghezza
-del buffer allocato per \param{optval} e per ricevere indietro, dopo la
-chiamata della funzione, la dimensione effettiva dei dati scritti su di esso.
-Se la dimensione del buffer allocato per \param{optval} non è sufficiente si
-avrà un errore.
+che viene usata come \textit{value result argument} per indicare, prima della
+chiamata della funzione, la lunghezza del buffer allocato per \param{optval} e
+per ricevere indietro, dopo la chiamata della funzione, la dimensione
+effettiva dei dati scritti su di esso.  Se la dimensione del buffer allocato
+per \param{optval} non è sufficiente si avrà un errore.
 
 
 
@@ -3577,10 +3575,10 @@ tipo di operazione da effettuare) quando essa viene applicata ad un socket
 generico. Nell'elenco si illustrerà anche, per ciascuna operazione, il tipo di
 dato usato come terzo argomento della funzione ed il significato che esso
 viene ad assumere.  Dato che in caso di lettura questi dati vengono restituiti
-come \itindex{value~result~argument} \textit{value result argument}, con
-queste operazioni il terzo argomento deve sempre essere passato come puntatore
-ad una variabile (o struttura) precedentemente allocata. Le costanti che
-identificano le operazioni sono le seguenti:
+come \textit{value result argument}, con queste operazioni il terzo argomento
+deve sempre essere passato come puntatore ad una variabile (o struttura)
+precedentemente allocata. Le costanti che identificano le operazioni sono le
+seguenti:
 \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
 \item[\const{SIOCGSTAMP}] restituisce il contenuto di una struttura
   \struct{timeval} con la marca temporale dell'ultimo pacchetto ricevuto sul
@@ -3939,8 +3937,8 @@ Le operazioni di controllo disponibili per i socket TCP sono illustrate dalla
 relativa pagina di manuale, accessibile con \texttt{man 7 tcp}, e prevedono
 come possibile valore per il secondo argomento della funzione le costanti
 illustrate nell'elenco seguente; il terzo argomento della funzione, gestito
-come \itindex{value~result~argument} \textit{value result argument}, deve
-essere sempre il puntatore ad una variabile di tipo \ctyp{int}:
+come \textit{value result argument}, deve essere sempre il puntatore ad una
+variabile di tipo \ctyp{int}:
 \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
 \item[\const{SIOCINQ}] restituisce la quantità di dati non ancora letti
   presenti nel buffer di ricezione; il socket non deve essere in stato
@@ -3972,9 +3970,8 @@ essere sempre il puntatore ad una variabile di tipo \ctyp{int}:
 Le operazioni di controllo disponibili per i socket UDP, anch'esse illustrate
 dalla relativa pagina di manuale accessibile con \texttt{man 7 udp}, sono
 quelle indicate dalle costanti del seguente elenco; come per i socket TCP il
-terzo argomento viene gestito come \itindex{value~result~argument}
-\textit{value result argument} e deve essere un puntatore ad una variabile di
-tipo \ctyp{int}:
+terzo argomento viene gestito come \textit{value result argument} e deve
+essere un puntatore ad una variabile di tipo \ctyp{int}:
 \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
 \item[\const{FIONREAD}] restituisce la dimensione in byte del primo pacchetto
   in attesa di ricezione, o 0 qualora non ci sia nessun pacchetto.
index 43a5dbd75a0e4bdbebedd0960eb687bb62d581b7..d3bbecc6a4f764f3da529aa3595c1517a3eb0501 100644 (file)
@@ -524,7 +524,7 @@ tab.~\ref{tab:TCP_ipv4_addr}, che rincontreremo più avanti.
 Infine occorre sottolineare che sia gli indirizzi che i numeri di porta devono
 essere specificati in quello che viene chiamato \textit{network order}, cioè
 con i bit ordinati in formato \textit{big endian} (vedi
-sez.~\ref{sec:sock_endianness}), questo comporta la necessità di usare apposite
+sez.~\ref{sec:endianness}), questo comporta la necessità di usare apposite
 funzioni di conversione per mantenere la portabilità del codice (vedi
 sez.~\ref{sec:sock_addr_func} per i dettagli del problema e le relative
 soluzioni).
@@ -640,7 +640,7 @@ inferiori a 129 sono usati per le \textsl{porte riservate}, e possono essere
 usati solo da processi con i privilegi di amministratore o con la
 \textit{capability} \const{CAP\_NET\_BIND\_SERVICE}.  L'indirizzo remoto è
 specificato nella struttura \var{sat\_addr}, e deve essere in \textit{network
-  order} (vedi sez.~\ref{sec:sock_endianness}); esso è composto da un parte di
+  order} (vedi sez.~\ref{sec:endianness}); esso è composto da un parte di
 rete data dal campo \var{s\_net}, che può assumere il valore
 \const{AT\_ANYNET}, che indica una rete generica e vale anche per indicare la
 rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e può prendere
@@ -786,15 +786,15 @@ può comportare la necessità di eseguire delle conversioni.
 \subsection{Le funzioni per il riordinamento}
 \label{sec:sock_func_ord}
 
-Come già visto in sez.~\ref{sec:sock_endianness} il problema connesso
-\itindex{endianness} all'\textit{endianness} è che quando si passano dei dati da
-un tipo di architettura all'altra i dati vengono interpretati in maniera
-diversa, e ad esempio nel caso dell'intero a 16 bit ci si ritroverà con i due
-byte in cui è suddiviso scambiati di posto.  Per questo motivo si usano delle
-funzioni di conversione che servono a tener conto automaticamente della
-possibile differenza fra l'ordinamento usato sul computer e quello che viene
-usato nelle trasmissione sulla rete; queste funzioni sono \funcd{htonl},
-\funcd{htons}, \funcd{ntohl} e \funcd{ntohs} ed i rispettivi prototipi sono:
+Come già visto in sez.~\ref{sec:endianness} il problema connesso
+all'\textit{endianness} è che quando si passano dei dati da un tipo di
+architettura all'altra i dati vengono interpretati in maniera diversa, e ad
+esempio nel caso dell'intero a 16 bit ci si ritroverà con i due byte in cui è
+suddiviso scambiati di posto.  Per questo motivo si usano delle funzioni di
+conversione che servono a tener conto automaticamente della possibile
+differenza fra l'ordinamento usato sul computer e quello che viene usato nelle
+trasmissione sulla rete; queste funzioni sono \funcd{htonl}, \funcd{htons},
+\funcd{ntohl} e \funcd{ntohs} ed i rispettivi prototipi sono:
 \begin{functions}
   \headdecl{netinet/in.h}
   \funcdecl{unsigned long int htonl(unsigned long int hostlong)} 
index 228905ebca6b50dd5c7a91275e0be372c4dc0c1a..ca0510985e39fdad1f8b623e0fa648a8e47ada13 100644 (file)
@@ -1687,7 +1687,7 @@ riportati nel seguente elenco:
   processo con la prima ricezione.
 
 \item[\const{RLIMIT\_DATA}] Questa risorsa indica, in byte, la massima
-  dimensione del \index{segmento!dati} segmento dati di un processo (vedi
+  dimensione del segmento dati di un processo (vedi
   sez.~\ref{sec:proc_mem_layout}).  Il tentativo di allocare più memoria di
   quanto indicato dal limite corrente causa il fallimento della funzione di
   allocazione eseguita (\func{brk} o \func{sbrk}) con un errore di
@@ -1708,14 +1708,13 @@ riportati nel seguente elenco:
 
 \item[\const{RLIMIT\_MEMLOCK}] Questa risorsa indica, in byte, l'ammontare
   massimo di memoria che può essere bloccata in RAM da un processo (vedi
-  sez.~\ref{sec:proc_mem_lock}). Dato che il \itindex{memory~locking}
-  \textit{memory locking} viene effettuato sulle pagine di memoria, il valore
-  indicato viene automaticamente arrotondato al primo multiplo successivo
-  della dimensione di una pagina di memoria. Il limite comporta il fallimento
-  delle \textit{system call} che eseguono il \textit{memory locking}
-  (\func{mlock}, \func{mlockall} ed anche, vedi
-  sez.~\ref{sec:file_memory_map}, \func{mmap} con l'operazione
-  \const{MAP\_LOCKED}). 
+  sez.~\ref{sec:proc_mem_lock}). Dato che il \textit{memory locking} viene
+  effettuato sulle pagine di memoria, il valore indicato viene automaticamente
+  arrotondato al primo multiplo successivo della dimensione di una pagina di
+  memoria. Il limite comporta il fallimento delle \textit{system call} che
+  eseguono il \textit{memory locking} (\func{mlock}, \func{mlockall} ed anche,
+  vedi sez.~\ref{sec:file_memory_map}, \func{mmap} con l'operazione
+  \const{MAP\_LOCKED}).
 
   Dal kernel 2.6.9 questo limite comprende anche la memoria che può essere
   bloccata da ciascun utente nell'uso della memoria condivisa (vedi
@@ -1761,10 +1760,10 @@ messaggi vuoti che comunque richiede delle risorse di gestione. Questa risorsa
   \itindex{Resident~Set~Size~(RSS)} \textit{Resident Set Size}) cioè
   l'ammontare della memoria associata al processo che risiede effettivamente
   in RAM e non a quella eventualmente portata sulla \textit{swap} o non ancora
-  caricata dal filesystem per il \index{segmento!testo} segmento testo del
-  programma.  Ha effetto solo sulle chiamate a \func{madvise} con
-  \const{MADV\_WILLNEED} (vedi sez.~\ref{sec:file_memory_map}). Presente solo
-  sui i kernel precedenti il 2.4.30.
+  caricata dal filesystem per il segmento testo del programma.  Ha effetto
+  solo sulle chiamate a \func{madvise} con \const{MADV\_WILLNEED} (vedi
+  sez.~\ref{sec:file_memory_map}). Presente solo sui i kernel precedenti il
+  2.4.30.
 
 \item[\const{RLIMIT\_RTPRIO}] Questa risorsa indica il valore massimo della
   priorità statica che un processo può assegnarsi o assegnare con
@@ -2774,12 +2773,11 @@ informazioni relative al proprio fuso orario per determinare lo stato dell'ora
 legale.  
 
 La funzione inoltre modifica i valori della struttura \struct{tm} in forma di
-\itindex{value~result~argument} \textit{value result argument}, normalizzando
-i valori dei vari campi, impostando i valori risultanti per \var{tm\_wday} e
-\var{tm\_yday} e assegnando a \var{tm\_isdst} il valore (positivo o nullo)
-corrispondente allo stato dell'ora legale. La funzione inoltre provvede ad
-impostare il valore della \index{variabili!globali} variabile globale
-\var{tzname}.
+\textit{value result argument}, normalizzando i valori dei vari campi,
+impostando i valori risultanti per \var{tm\_wday} e \var{tm\_yday} e
+assegnando a \var{tm\_isdst} il valore (positivo o nullo) corrispondente allo
+stato dell'ora legale. La funzione inoltre provvede ad impostare il valore
+della variabile globale \var{tzname}.
 
 \itindend{calendar~time}
 
@@ -2790,8 +2788,8 @@ impostare il valore della \index{variabili!globali} variabile globale
     \includestruct{listati/time_zone_var.c}
   \end{minipage} 
   \normalsize 
-  \caption{Le \index{variabili!globali} variabili globali usate per la
-    gestione delle \itindex{timezone} \textit{timezone}.}
+  \caption{Le variabili globali usate per la gestione delle \itindex{timezone}
+    \textit{timezone}.}
   \label{fig:sys_tzname}
 \end{figure}
 
@@ -2799,12 +2797,11 @@ Come accennato l'uso del \textit{broken-down time} permette di tenere conto
 anche della differenza fra tempo universale e ora locale, compresa l'eventuale
 ora legale.  Questo viene fatto dalle funzioni di conversione grazie alle
 informazioni riguardo la propria \itindex{timezone} \textit{timezone}
-mantenute nelle tre \index{variabili!globali} variabili globali mostrate in
-fig.~\ref{fig:sys_tzname}, cui si si può accedere direttamente includendo
-\headfile{time.h}. Come illustrato queste variabili vengono impostate
-internamente da alcune delle delle precedenti funzioni di conversione, ma lo
-si può fare esplicitamente chiamando direttamente la funzione \funcd{tzset},
-il cui prototipo è:
+mantenute nelle tre variabili globali mostrate in fig.~\ref{fig:sys_tzname},
+cui si si può accedere direttamente includendo \headfile{time.h}. Come
+illustrato queste variabili vengono impostate internamente da alcune delle
+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}
@@ -2966,13 +2963,13 @@ c'è stato un errore. Di solito questo valore, a seconda della funzione, è $-1$
 o un puntatore nullo o la costante \val{EOF}; ma questo valore segnala solo
 che c'è stato un errore, e non il tipo di errore.
 
-Per riportare il tipo di errore il sistema usa \index{variabili!globali} la
-variabile globale \var{errno}, definita nell'header \headfile{errno.h}.  Come
-accennato l'uso di una variabile globale può comportare problemi nel caso dei
-\itindex{thread} \textit{thread}, ma lo standard ISO C consente anche di
-definire \var{errno} come un cosiddetto ``\textit{modifiable lvalue}'', cosa
-che consente di usare anche una macro, e questo è infatti il metodo usato da
-Linux per renderla locale ai singoli \itindex{thread} \textit{thread}.
+Per riportare il tipo di errore il sistema usa la variabile globale
+\var{errno}, definita nell'header \headfile{errno.h}.  Come accennato l'uso di
+una variabile globale può comportare problemi nel caso dei \itindex{thread}
+\textit{thread}, ma lo standard ISO C consente anche di definire \var{errno}
+come un cosiddetto ``\textit{modifiable lvalue}'', cosa che consente di usare
+anche una macro, e questo è infatti il metodo usato da Linux per renderla
+locale ai singoli \itindex{thread} \textit{thread}.
 
 La variabile è in genere definita come \direct{volatile} dato che può essere
 cambiata in modo asincrono da un segnale, per un esempio si veda
@@ -3100,7 +3097,7 @@ riferiscono all'ultimo errore avvenuto. La stringa specificata con
 personalizzazione (ad esempio l'indicazione del contesto in cui si è
 verificato), seguita dai due punti e da uno spazio, il messaggio è terminato
 con un a capo.  Il messaggio può essere riportato anche usando le due
-\index{variabili!globali} variabili globali:
+variabili globali:
 \includecodesnip{listati/errlist.c} 
 dichiarate in \headfile{errno.h}. La prima contiene i puntatori alle stringhe
 di errore indicizzati da \var{errno}; la seconda esprime il valore più alto
@@ -3175,12 +3172,11 @@ sez.~\ref{sec:file_formatted_io}), ed i relativi argomenti devono essere
 forniti allo stesso modo, mentre \param{errnum} indica l'errore che si vuole
 segnalare (non viene quindi usato il valore corrente di \var{errno}).
 
-La funzione stampa sullo \itindex{standard~error} \textit{standard error} il
-nome del programma, come indicato dalla \index{variabili!globali} variabile
-globale \var{program\_name}, seguito da due punti ed uno spazio, poi dalla
-stringa generata da \param{format} e dagli argomenti seguenti, seguita da due
-punti ed uno spazio infine il messaggio di errore relativo ad \param{errnum},
-il tutto è terminato da un a capo.
+La funzione stampa sullo \textit{standard error} il nome del programma, come
+indicato dalla variabile globale \var{program\_name}, seguito da due punti ed
+uno spazio, poi dalla stringa generata da \param{format} e dagli argomenti
+seguenti, seguita da due punti ed uno spazio infine il messaggio di errore
+relativo ad \param{errnum}, il tutto è terminato da un a capo.
 
 Il comportamento della funzione può essere ulteriormente controllato se si
 definisce una variabile \var{error\_print\_progname} come puntatore ad una
@@ -3191,8 +3187,8 @@ L'argomento \param{status} può essere usato per terminare direttamente il
 programma in caso di errore, nel qual caso \func{error} dopo la stampa del
 messaggio di errore chiama \func{exit} con questo stato di uscita. Se invece
 il valore è nullo \func{error} ritorna normalmente ma viene incrementata
-un'altra \index{variabili!globali} variabile globale,
-\var{error\_message\_count}, che tiene conto di quanti errori ci sono stati.
+un'altra variabile globale, \var{error\_message\_count}, che tiene conto di
+quanti errori ci sono stati.
 
 Un'altra funzione per la stampa degli errori, ancora più sofisticata, che
 prende due argomenti aggiuntivi per indicare linea e file su cui è avvenuto
@@ -3212,10 +3208,9 @@ l'errore è \funcd{error\_at\_line}; il suo prototipo è:
 \noindent ed il suo comportamento è identico a quello di \func{error} se non
 per il fatto che, separati con il solito due punti-spazio, vengono inseriti un
 nome di file indicato da \param{fname} ed un numero di linea subito dopo la
-stampa del nome del programma. Inoltre essa usa un'altra
-\index{variabili!globali} variabile globale, \var{error\_one\_per\_line}, che
-impostata ad un valore diverso da zero fa si che errori relativi alla stessa
-linea non vengano ripetuti.
+stampa del nome del programma. Inoltre essa usa un'altra variabile globale,
+\var{error\_one\_per\_line}, che impostata ad un valore diverso da zero fa si
+che errori relativi alla stessa linea non vengano ripetuti.
 
 
 % LocalWords:  filesystem like kernel saved header limits sysconf sez tab float
index 613aea4de6e9afa31dfdbee8925dc179d4b01bc8..fe2891fbe2bfad56cfed95caf30799e301c87eb2 100644 (file)
@@ -730,9 +730,9 @@ Si noti che si è usato \func{htonl} per assegnare il valore
 \const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è
 inutile.  Si tenga presente comunque che tutte le costanti \val{INADDR\_}
 (riportate in tab.~\ref{tab:TCP_ipv4_addr}) sono definite secondo
-\itindex{endianness} l'\textit{endianness} della macchina, ed anche se esse
-possono essere invarianti rispetto all'ordinamento dei bit, è comunque buona
-norma usare sempre la funzione \func{htonl}.
+l'\textit{endianness} della macchina, ed anche se esse possono essere
+invarianti rispetto all'ordinamento dei bit, è comunque buona norma usare
+sempre la funzione \func{htonl}.
 
 \begin{table}[htb]
   \centering