X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=process.tex;fp=process.tex;h=be725cdfa077dceb0143a4e0b48c180415233a1d;hp=6a37bb0968d2f534ac0571099399027f159732ff;hb=9b7af600ff0f73bc946c9d160c320667c7a91347;hpb=88d22f4971adcbdb816c405a1375ae0a8d57bdde

diff --git a/process.tex b/process.tex
index 6a37bb0..be725cd 100644
--- a/process.tex
+++ b/process.tex
@@ -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}