Cambiato il riferimento nelle note di copyright alla nuova sezione invariante
[gapil.git] / process.tex
index 5a3e630b84e9030f61e7ba60d8707c0d4fa73f10..006947bc34838132a54e1fce083a7b3069fef5a8 100644 (file)
@@ -1,9 +1,9 @@
 %% process.tex
 %%
-%% Copyright (C) 2000-2002 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2004 Simone Piccardi.  Permission is granted to
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
-%% Free Software Foundation; with the Invariant Sections being "Prefazione",
+%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
 %% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
 %% license is included in the section entitled "GNU Free Documentation
 %% License".
@@ -46,26 +46,24 @@ avvio, usando il programma \cmd{ld-linux.so}.  Questo programma prima carica
 le librerie condivise che servono al programma, poi effettua il link dinamico
 del codice e alla fine lo esegue. Infatti, a meno di non aver specificato il
 flag \texttt{-static} durante la compilazione, tutti i programmi in Linux sono
-incompleti e necessitano di essere linkati alle librerie condivise quando
-vengono avviati.  La procedura è controllata da alcune variabili di ambiente e
-dal contenuto di \file{/etc/ld.so.conf}. I dettagli sono riportati nella man
-page di \cmd{ld.so}.
+incompleti e necessitano di essere \textit{linkati} alle librerie condivise
+quando vengono avviati.  La procedura è controllata da alcune variabili di
+ambiente e dal contenuto di \file{/etc/ld.so.conf}. I dettagli sono riportati
+nella man page di \cmd{ld.so}.
 
 Il sistema fa partire qualunque programma chiamando la funzione \func{main};
 sta al programmatore chiamare così la funzione principale del programma da cui
 si suppone iniziare l'esecuzione; in ogni caso senza questa funzione lo stesso
-linker darebbe luogo ad errori.
+\textit{linker} darebbe luogo ad errori.
 
 Lo standard ISO C specifica che la funzione \func{main} può non avere 
 argomenti o prendere due argomenti che rappresentano gli argomenti passati da
 linea di comando, in sostanza un prototipo che va sempre bene è il seguente:
-\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
-    int main (int argc, char *argv[])
-\end{lstlisting}
+\includecodesnip{listati/main_def.c}
 
 In realtà nei sistemi Unix esiste un'altro modo per definire la funzione
 \func{main}, che prevede la presenza di un terzo parametro, \code{char
-  *envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{sec:proc_environ})
+  *envp[]}, che fornisce l'\textsl{ambiente} (vedi sez.~\ref{sec:proc_environ})
 del programma; questa forma però non è prevista dallo standard POSIX.1 per cui
 se si vogliono scrivere programmi portabili è meglio evitarla.
 
@@ -80,10 +78,10 @@ automaticamente quando \func{main} ritorna).  Una forma alternativa 
 di chiamare direttamente la system call \func{\_exit}, che restituisce il
 controllo direttamente alla routine di conclusione dei processi del kernel.
 
-Oltre alla conclusione ``normale'' esiste anche la possibilità di una
-conclusione ``anomala'' del programma a causa della ricezione di un segnale
-(si veda \capref{cha:signals}) o della chiamata alla funzione \func{abort};
-torneremo su questo in \secref{sec:proc_termination}.
+Oltre alla conclusione ``\textsl{normale}'' esiste anche la possibilità di una
+conclusione ``\textsl{anomala}'' del programma a causa della ricezione di un
+segnale (si veda cap.~\ref{cha:signals}) o della chiamata alla funzione
+\func{abort}; torneremo su questo in sez.~\ref{sec:proc_termination}.
 
 Il valore di ritorno della funzione \func{main}, o quello usato nelle chiamate
 ad \func{exit} e \func{\_exit}, viene chiamato \textsl{stato di uscita} (o
@@ -109,7 +107,7 @@ universalmente seguita 
 
 Si tenga presente inoltre che non è una buona idea usare il codice di errore
 restituito dalla variabile \var{errno} (per i dettagli si veda
-\secref{sec:sys_errors}) come stato di uscita. In generale infatti una shell
+sez.~\ref{sec:sys_errors}) come stato di uscita. In generale infatti una shell
 non si cura del valore se non per vedere se è diverso da zero; inoltre il
 valore dello stato di uscita è sempre troncato ad 8 bit, per cui si potrebbe
 incorrere nel caso in cui restituendo un codice di errore 256, si otterrebbe
@@ -124,9 +122,9 @@ valori di tipo \ctyp{int} 0 e 1.
 \subsection{Le funzioni \func{exit} e \func{\_exit}}
 \label{sec:proc_exit}
 
-Come accennato le funzioni usate per effettuare un'uscita ``normale'' da un
-programma sono due, la prima è la funzione \funcd{exit}, che è definita dallo
-standard ANSI C ed il cui prototipo è:
+Come accennato le funzioni usate per effettuare un'uscita ``\textit{normale}''
+da un programma sono due, la prima è la funzione \funcd{exit}, che è definita
+dallo standard ANSI C ed il cui prototipo è:
 \begin{prototype}{stdlib.h}{void exit(int status)}
   Causa la conclusione ordinaria del programma.
 
@@ -136,9 +134,9 @@ standard ANSI C ed il cui prototipo 
 La funzione \func{exit} è pensata per eseguire una conclusione pulita di un
 programma che usi le librerie standard del C; essa esegue tutte le funzioni
 che sono state registrate con \func{atexit} e \func{on\_exit} (vedi
-\secref{sec:proc_atexit}), e chiude tutti gli stream effettuando il
+sez.~\ref{sec:proc_atexit}), e chiude tutti gli stream effettuando il
 salvataggio dei dati sospesi (chiamando \func{fclose}, vedi
-\secref{sec:file_fopen}), infine passa il controllo al kernel chiamando
+sez.~\ref{sec:file_fopen}), infine passa il controllo al kernel chiamando
 \func{\_exit} e restituendo il valore di \param{status} come stato di uscita.
 
 La system call \funcd{\_exit} restituisce direttamente il controllo al kernel,
@@ -154,10 +152,10 @@ non vengono salvati e le eventuali funzioni registrate con \func{atexit} e
 La funzione chiude tutti i file descriptor appartenenti al processo (si tenga
 presente che questo non comporta il salvataggio dei dati bufferizzati degli
 stream), fa sì che ogni figlio del processo sia ereditato da \cmd{init} (vedi
-\secref{cha:process_handling}), manda un segnale \const{SIGCHLD} al processo
-padre (vedi \secref{sec:sig_job_control}) ed infine ritorna lo stato di uscita
-specificato in \param{status} che può essere raccolto usando la funzione
-\func{wait} (vedi \secref{sec:proc_wait}).
+cap.~\ref{cha:process_handling}), manda un segnale \const{SIGCHLD} al processo
+padre (vedi sez.~\ref{sec:sig_job_control}) ed infine ritorna lo stato di
+uscita specificato in \param{status} che può essere raccolto usando la
+funzione \func{wait} (vedi sez.~\ref{sec:proc_wait}).
 
 
 \subsection{Le funzioni \func{atexit} e \func{on\_exit}}
@@ -175,9 +173,9 @@ pulizia al programmatore che la utilizza.
 all'utente, avere la possibilità di effettuare automaticamente la chiamata ad
 una funzione che effettui tali operazioni all'uscita dal programma. A questo
 scopo lo standard ANSI C prevede la possibilità di registrare un certo numero
-funzioni che verranno eseguite all'uscita dal programma (sia per la chiamata
-ad \func{exit} che per il ritorno di \func{main}). La prima funzione che si
-può utilizzare a tal fine è \funcd{atexit} il cui prototipo è:
+di funzioni che verranno eseguite all'uscita dal programma (sia per la
+chiamata ad \func{exit} che per il ritorno di \func{main}). La prima funzione
+che si può utilizzare a tal fine è \funcd{atexit} il cui prototipo è:
 \begin{prototype}{stdlib.h}{void atexit(void (*function)(void))}
   Registra la funzione \param{function} per la chiamata all'uscita dal
   programma.
@@ -187,8 +185,8 @@ pu
 \end{prototype}
 \noindent la funzione richiede come argomento l'indirizzo di una opportuna
 funzione di pulizia da chiamare all'uscita del programma, che non deve
-prendere argomenti e non deve ritornare niente (deve essere essere cioè
-definita come \code{void function(void)}).
+prendere argomenti e non deve ritornare niente (deve essere cioè definita come
+\code{void function(void)}).
 
 Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che le
 \acr{glibc} includono per compatibilità con SunOS, ma che non è detto sia
@@ -222,7 +220,7 @@ Data l'importanza dell'argomento 
 in un sistema Unix l'unico modo in cui un programma può essere eseguito dal
 kernel è attraverso la chiamata alla system call \func{execve} (o attraverso
 una delle funzioni della famiglia \func{exec} che vedremo in
-\secref{sec:proc_exec}).
+sez.~\ref{sec:proc_exec}).
 
 Allo stesso modo l'unico modo in cui un programma può concludere
 volontariamente la sua esecuzione è attraverso una chiamata alla system call
@@ -230,19 +228,19 @@ volontariamente la sua esecuzione 
 \func{exit} o il ritorno di \func{main}.
 
 Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
-normalmente un programma è riportato in \figref{fig:proc_prog_start_stop}.
+normalmente un programma è riportato in fig.~\ref{fig:proc_prog_start_stop}.
 
 \begin{figure}[htb]
   \centering
-  \includegraphics[width=12cm]{img/proc_beginend}
+  \includegraphics[width=14cm]{img/proc_beginend}
   \caption{Schema dell'avvio e della conclusione di un programma.}
   \label{fig:proc_prog_start_stop}
 \end{figure}
 
 Si ricordi infine che un programma può anche essere interrotto dall'esterno
 attraverso l'uso di un segnale (modalità di conclusione non mostrata in
-\figref{fig:proc_prog_start_stop}); torneremo su questo aspetto in
-\capref{cha:signals}.
+fig.~\ref{fig:proc_prog_start_stop}); torneremo su questo aspetto in
+cap.~\ref{cha:signals}.
 
 
 
@@ -269,7 +267,7 @@ in cui gli indirizzi vanno da zero ad un qualche valore massimo.\footnote{nel
   2Gb. Con il kernel 2.4 ed il supporto per la \textit{high-memory} il limite
   è stato esteso.}
 
-Come accennato in \capref{cha:intro_unix} questo spazio di indirizzi è
+Come accennato in cap.~\ref{cha:intro_unix} questo spazio di indirizzi è
 virtuale e non corrisponde all'effettiva posizione dei dati nella RAM del
 computer; in genere detto spazio non è neppure continuo (cioè non tutti gli
 indirizzi possibili sono utilizzabili, e quelli usabili non sono
@@ -278,10 +276,13 @@ necessariamente adiacenti).
 Per la gestione da parte del kernel la memoria virtuale viene divisa in pagine
 di dimensione fissa (che ad esempio sono di 4kb su macchine a 32 bit e 8kb
 sulle alpha, valori strettamente connessi all'hardware di gestione della
-memoria), e ciascuna pagina della memoria virtuale è associata ad un supporto
-che può essere una pagina di memoria reale o ad un dispositivo di stoccaggio
-secondario (in genere lo spazio disco riservato alla swap, o i file che
-contengono il codice).
+memoria),\footnote{con le versioni più recenti del kernel è possibile anche
+  utilizzare pagine di dimensioni maggiori, per sistemi con grandi
+  quantitativi di memoria in cui l'uso di pagine troppo piccole comporta una
+  perdita di prestazioni.} e ciascuna pagina della memoria virtuale è
+associata ad un supporto che può essere una pagina di memoria reale o ad un
+dispositivo di stoccaggio secondario (in genere lo spazio disco riservato alla
+swap, o i file che contengono il codice).
 
 Lo stesso pezzo di memoria reale (o di spazio disco) può fare da supporto a
 diverse pagine di memoria virtuale appartenenti a processi diversi (come
@@ -317,7 +318,7 @@ Normalmente questo 
 in genere il sistema è molto efficiente in questo lavoro; quando però ci siano
 esigenze specifiche di prestazioni è possibile usare delle funzioni che
 permettono di bloccare il meccanismo della paginazione\index{paginazione} e
-mantenere fisse delle pagine in memoria (vedi \ref{sec:proc_mem_lock}).
+mantenere fisse delle pagine in memoria (vedi sez.~\ref{sec:proc_mem_lock}).
 
 
 \subsection{La struttura della memoria di un processo}
@@ -358,9 +359,7 @@ seguenti segmenti:
   La prima parte è il segmento dei dati inizializzati, che contiene le
   variabili il cui valore è stato assegnato esplicitamente. Ad esempio
   se si definisce:
-  \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
-    double pi = 3.14;
-  \end{lstlisting}
+\includecodesnip{listati/pi.c}
   questo valore sarà immagazzinato in questo segmento. La memoria di questo
   segmento viene preallocata all'avvio del programma e inizializzata ai valori
   specificati.
@@ -368,22 +367,20 @@ seguenti segmenti:
   La seconda parte è il segmento dei dati non inizializzati, che contiene le
   variabili il cui valore non è stato assegnato esplicitamente. Ad esempio se
   si definisce:
-  \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
-    int vect[100];
-  \end{lstlisting}
+\includecodesnip{listati/vect.c}
   questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
   allocato all'avvio, e tutte le variabili vengono inizializzate a zero (ed i
   puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
     variabili che vanno nel segmento dati, e non è affatto vero in generale.}
    
-  Storicamente questo segmento viene chiamato BBS (da \textit{block started by
+  Storicamente questo segmento viene chiamato BSS (da \textit{block started by
     symbol}). La sua dimensione è fissa.
   
 \item Lo \textit{heap}. Tecnicamente lo si può considerare l'estensione del
   segmento dati, a cui di solito è posto giusto di seguito. È qui che avviene
   l'allocazione dinamica della memoria; può essere ridimensionato allocando e
   disallocando la memoria dinamica con le apposite funzioni (vedi
-  \secref{sec:proc_mem_alloc}), ma il suo limite inferiore (quello adiacente
+  sez.~\ref{sec:proc_mem_alloc}), ma il suo limite inferiore (quello adiacente
   al segmento dati) ha una posizione fissa.
   
 \item Il segmento di \textit{stack}, che contiene lo \textit{stack} del
@@ -392,10 +389,10 @@ seguenti segmenti:
   del chiamante (tipo il contenuto di alcuni registri della CPU). Poi la
   funzione chiamata alloca qui lo spazio per le sue variabili locali: in
   questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
-  della funzione lo spazio è automaticamente rilasciato e ``ripulito''. La
-  pulizia in C e C++ viene fatta dal chiamante.\footnote{a meno che non sia
-    stato specificato l'utilizzo di una calling convention diversa da quella
-    standard.}
+  della funzione lo spazio è automaticamente rilasciato e
+  ``\textsl{ripulito}''. La pulizia in C e C++ viene fatta dal
+  chiamante.\footnote{a meno che non sia stato specificato l'utilizzo di una
+    calling convention diversa da quella standard.}
   
   La dimensione di questo segmento aumenta seguendo la crescita dello stack
   del programma, ma non viene ridotta quando quest'ultimo si restringe.
@@ -403,13 +400,13 @@ seguenti segmenti:
 
 \begin{figure}[htb]
   \centering
-  \includegraphics[width=5cm]{img/memory_layout}
+  \includegraphics[height=12cm]{img/memory_layout}
   \caption{Disposizione tipica dei segmenti di memoria di un processo.}
   \label{fig:proc_mem_layout}
 \end{figure}
 
 Una disposizione tipica di questi segmenti è riportata in
-\figref{fig:proc_mem_layout}. Usando il comando \cmd{size} su un programma se
+fig.~\ref{fig:proc_mem_layout}. Usando il comando \cmd{size} su un programma se
 ne può stampare le dimensioni dei segmenti di testo e di dati (inizializzati e
 BSS); si tenga presente però che il BSS non è mai salvato sul file che
 contiene l'eseguibile, dato che viene sempre inizializzato a zero al
@@ -531,7 +528,7 @@ in ingresso; per questo si dovr
 ad un adeguato aggiornamento di tutti gli altri puntatori all'interno del
 blocco di dati ridimensionato.
 
-Un errore abbastanza frequente (specie se si ha a che fare con array di
+Un errore abbastanza frequente (specie se si ha a che fare con vettori di
 puntatori) è quello di chiamare \func{free} più di una volta sullo stesso
 puntatore; per evitare questo problema una soluzione di ripiego è quella di
 assegnare sempre a \val{NULL} ogni puntatore liberato con \func{free}, dato
@@ -541,22 +538,22 @@ operazione.
 Le \acr{glibc} hanno un'implementazione delle routine di allocazione che è
 controllabile dall'utente attraverso alcune variabili di ambiente, in
 particolare diventa possibile tracciare questo tipo di errori usando la
-variabile d'ambiente \val{MALLOC\_CHECK\_} che quando viene definita mette in
+variabile dambiente \val{MALLOC\_CHECK\_} che quando viene definita mette in
 uso una versione meno efficiente delle funzioni suddette, che però è più
 tollerante nei confronti di piccoli errori come quello di chiamate doppie a
 \func{free}.  In particolare:
 \begin{itemize}
 \item se la variabile è posta a zero gli errori vengono ignorati.
 \item se è posta ad 1 viene stampato un avviso sullo \textit{standard error}
-  (vedi \secref{sec:file_std_stream}).
+  (vedi sez.~\ref{sec:file_std_stream}).
 \item se è posta a 2 viene chiamata \func{abort}, che in genere causa
   l'immediata conclusione del programma.
 \end{itemize}
 
 Il problema più comune e più difficile da risolvere che si incontra con le
 routine di allocazione è quando non viene opportunamente liberata la memoria
-non più utilizzata, quello che in inglese viene chiamato \textit{memory-leak},
-cioè una \textsl{perdita di memoria}.
+non più utilizzata, quello che in inglese viene chiamato \textit{memory
+  leak}\index{memory leak}, cioè una \textsl{perdita di memoria}.
 
 Un caso tipico che illustra il problema è quello in cui in una subroutine si
 alloca della memoria per uso locale senza liberarla prima di uscire. La
@@ -569,12 +566,12 @@ Il problema 
 momento, in corrispondenza ad una qualunque chiamata di \func{malloc}, che può
 essere in una sezione del codice che non ha alcuna relazione con la subroutine
 che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
-\textit{memory leak}.
+\textit{memory leak}\index{memory leak}.
 
 In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
 programmazione ad oggetti, il problema dei \textit{memory leak} è notevolmente
 ridimensionato attraverso l'uso accurato di appositi oggetti come gli
-\textit{smartpointers}.  Questo però va a scapito delle performance
+\textit{smartpointers}.  Questo però va a scapito delle prestazioni
 dell'applicazione in esecuzione.
 
 In altri linguaggi come il java e recentemente il C\# il problema non si pone
@@ -587,11 +584,11 @@ In tal caso, attraverso meccanismi simili a quelli del \textit{reference
 riferita da nessuna parte del codice in esecuzione, può essere deallocata
 automaticamente in qualunque momento dall'infrastruttura.
 
-Anche questo va a scapito delle performance dell'applicazione in esecuzione
+Anche questo va a scapito delle prestazioni dell'applicazione in esecuzione
 (inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
 eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
 la presenza di una infrastruttura per la loro interpretazione e pertanto hanno
-di per sé delle performance più scadenti rispetto alle stesse applicazioni
+di per sé delle prestazioni più scadenti rispetto alle stesse applicazioni
 compilate direttamente).  Questo comporta però il problema della non
 predicibilità del momento in cui viene deallocata la memoria precedentemente
 allocata da un oggetto.
@@ -615,10 +612,10 @@ molto complesse riguardo l'allocazione della memoria.
 \label{sec:proc_mem_alloca}
 
 Una possibile alternativa all'uso di \func{malloc}, che non soffre dei
-problemi di \textit{memory leak} descritti in precedenza, è la funzione
-\funcd{alloca}, che invece di allocare la memoria nello heap usa il segmento
-di stack della funzione corrente. La sintassi è identica a quella di
-\func{malloc}, il suo prototipo è:
+problemi di \textit{memory leak}\index{memory leak} descritti in precedenza, è
+la funzione \funcd{alloca}, che invece di allocare la memoria nello heap usa
+il segmento di stack della funzione corrente. La sintassi è identica a quella
+di \func{malloc}, il suo prototipo è:
 \begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
   Alloca \param{size} byte nello stack.
   
@@ -634,10 +631,10 @@ quindi non esiste un analogo della \func{free}) in quanto essa viene
 rilasciata automaticamente al ritorno della funzione.
 
 Come è evidente questa funzione ha molti vantaggi, anzitutto permette di
-evitare alla radice i problemi di 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 \secref{sec:proc_longjmp}).
+evitare alla radice i problemi di memory leak\index{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
@@ -664,7 +661,7 @@ che deve poi essere usata anche al di fuori della funzione in cui essa viene
 chiamata, dato che all'uscita dalla funzione lo spazio allocato diventerebbe
 libero, e potrebbe essere sovrascritto all'invocazione di nuove funzioni.
 Questo è lo stesso problema che si può avere con le variabili automatiche, su
-cui torneremo in \secref{sec:proc_auto_var}.
+cui torneremo in sez.~\ref{sec:proc_auto_var}.
 
 
 \subsection{Le funzioni \func{brk} e \func{sbrk}}  
@@ -673,8 +670,8 @@ cui torneremo in \secref{sec:proc_auto_var}.
 Queste due funzioni vengono utilizzate soltanto quando è necessario effettuare
 direttamente la gestione della memoria associata allo spazio dati di un
 processo, ad esempio qualora si debba implementare la propria versione delle
-routine di allocazione della memoria viste in \secref{sec:proc_mem_malloc}. La
-prima funzione è \funcd{brk}, ed il suo prototipo è:
+routine di allocazione della memoria viste in sez.~\ref{sec:proc_mem_malloc}.
+La prima funzione è \funcd{brk}, ed il suo prototipo è:
 \begin{prototype}{unistd.h}{int brk(void *end\_data\_segment)}
   Sposta la fine del segmento dei dati.
   
@@ -682,16 +679,16 @@ prima funzione 
     fallimento, nel qual caso \var{errno} assumerà il valore \errval{ENOMEM}.}
 \end{prototype}
 
-La funzione è un'interfaccia diretta all'ominima system call ed imposta
+La funzione è un'interfaccia diretta all'omonima system call ed imposta
 l'indirizzo finale del segmento dati di un processo all'indirizzo specificato
 da \param{end\_data\_segment}. Quest'ultimo deve essere un valore ragionevole,
 ed inoltre la dimensione totale del segmento non deve comunque eccedere un
-eventuale limite (si veda \secref{sec:sys_resource_limit}) imposto sulle
+eventuale limite (si veda sez.~\ref{sec:sys_resource_limit}) imposto sulle
 dimensioni massime dello spazio dati del processo.
 
 La seconda funzione per la manipolazione delle dimensioni del segmento
 dati\footnote{in questo caso si tratta soltanto di una funzione di libreria, e
-  non di una sistem call.} è \funcd{sbrk}, ed il suo prototipo è:
+  non di una system call.} è \funcd{sbrk}, ed il suo prototipo è:
 \begin{prototype}{unistd.h}{void *sbrk(ptrdiff\_t increment)} 
   Incrementa la dimensione dello spazio dati.
   
@@ -716,7 +713,7 @@ standard descritte in precedenza, che sono costruite su di esse.
 \subsection{Il controllo della memoria virtuale\index{memoria virtuale}}  
 \label{sec:proc_mem_lock}
 
-Come spiegato in \secref{sec:proc_mem_gen} il kernel gestisce la memoria
+Come spiegato in sez.~\ref{sec:proc_mem_gen} il kernel gestisce la memoria
 virtuale in maniera trasparente ai processi, decidendo quando rimuovere pagine
 dalla memoria per metterle nello swap, sulla base dell'utilizzo corrente da
 parte dei vari processi.
@@ -740,7 +737,7 @@ motivi per cui si possono avere di queste necessit
   quali pagine di memoria è opportuno che restino in memoria per un aumento
   delle prestazioni. In genere queste sono esigenze particolari e richiedono
   anche un aumento delle priorità in esecuzione del processo (vedi
-  \secref{sec:proc_real_time}).
+  sez.~\ref{sec:proc_real_time}).
   
 \item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro
   in memoria queste possono essere portate su disco dal meccanismo della
@@ -769,7 +766,7 @@ 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}.  Infine \textit{memory lock} non sono
 ereditati dai processi figli.\footnote{ma siccome Linux usa il \textit{copy on
-    write}\index{copy on write} (vedi \secref{sec:proc_fork}) gli indirizzi
+    write}\index{copy on write} (vedi sez.~\ref{sec:proc_fork}) gli indirizzi
   virtuali del figlio sono mantenuti sullo stesso segmento di RAM del padre,
   quindi fintanto che un figlio non scrive su un segmento, può usufruire del
   memory lock del padre.}
@@ -777,7 +774,7 @@ ereditati dai processi figli.\footnote{ma siccome Linux usa il \textit{copy on
 Siccome la richiesta di un \textit{memory lock} da parte di un processo riduce
 la memoria fisica disponibile nel sistema, questo ha un evidente impatto su
 tutti gli altri processi, per cui solo un processo con i privilegi di
-amministratore (vedremo in \secref{sec:proc_perms} cosa significa) ha la
+amministratore (vedremo in sez.~\ref{sec:proc_perms} cosa significa) ha la
 capacità di bloccare una pagina.  Ogni processo può però sbloccare le pagine
 relative alla propria memoria.
 
@@ -815,10 +812,10 @@ prototipi sono:
 \end{functions}
 
 Le due funzioni permettono rispettivamente di bloccare e sbloccare la
-paginazione per l'intervallo di memoria specificato dagli argomenti, che ne
-indicano nell'ordine l'indirizzo iniziale e la lunghezza.  Tutte le pagine che
-contengono una parte dell'intervallo bloccato sono mantenute in RAM per tutta
-la durata del blocco.
+paginazione\index{paginazione} per l'intervallo di memoria specificato dagli
+argomenti, che ne indicano nell'ordine l'indirizzo iniziale e la lunghezza.
+Tutte le pagine che contengono una parte dell'intervallo bloccato sono
+mantenute in RAM per tutta la durata del blocco.
 
 Altre due funzioni, \funcd{mlockall} e \funcd{munlockall}, consentono di
 bloccare genericamente la paginazione\index{paginazione} per l'intero spazio
@@ -876,8 +873,8 @@ Tutti i programmi hanno la possibilit
 vengono lanciati. Il passaggio dei parametri è effettuato attraverso gli
 argomenti \param{argc} e \param{argv} della funzione \func{main}, che vengono
 passati al programma dalla shell (o dal processo che esegue la \func{exec},
-secondo le modalità che vedremo in \secref{sec:proc_exec}) quando questo viene
-messo in esecuzione. 
+secondo le modalità che vedremo in sez.~\ref{sec:proc_exec}) quando questo
+viene messo in esecuzione.
 
 Oltre al passaggio dei parametri, un'altra modalità che permette di passare
 delle informazioni che modifichino il comportamento di un programma è quello
@@ -909,7 +906,7 @@ Nella scansione viene costruito il vettore di puntatori \param{argv} inserendo
 in successione il puntatore alla stringa costituente l'$n$-simo parametro; la
 variabile \param{argc} viene inizializzata al numero di parametri trovati, in
 questo modo il primo parametro è sempre il nome del programma; un esempio di
-questo meccanismo è mostrato in \figref{fig:proc_argv_argc}.
+questo meccanismo è mostrato in fig.~\ref{fig:proc_argv_argc}.
 
 
 \subsection{La gestione delle opzioni}
@@ -922,7 +919,7 @@ che non sia un singolo \texttt{'-'} o un \texttt{'--'} viene considerato
 un'opzione.  In genere le opzioni sono costituite da una lettera singola
 (preceduta dal carattere \cmd{'-'}) e possono avere o no un parametro
 associato; un comando tipico può essere quello mostrato in
-\figref{fig:proc_argv_argc}. In quel caso le opzioni sono \cmd{-r} e \cmd{-m}
+fig.~\ref{fig:proc_argv_argc}. In quel caso le opzioni sono \cmd{-r} e \cmd{-m}
 e la prima vuole un parametro mentre la seconda no (\cmd{questofile.txt} è un
 argomento del programma, non un parametro di \cmd{-m}).
 
@@ -948,7 +945,7 @@ trova un'opzione valida.
 La stringa \param{optstring} indica quali sono le opzioni riconosciute ed è
 costituita da tutti i caratteri usati per identificare le singole opzioni, se
 l'opzione ha un parametro al carattere deve essere fatto seguire un segno di
-due punti \texttt{':'}; nel caso di \figref{fig:proc_argv_argc} ad esempio la
+due punti \texttt{':'}; nel caso di fig.~\ref{fig:proc_argv_argc} ad esempio la
 stringa di opzioni avrebbe dovuto contenere \texttt{"r:m"}.
 
 La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
@@ -961,37 +958,11 @@ ritornato il carattere \texttt{':'}, infine se viene incontrato il valore
 elementi di \param{argv} che cominciano con il carattere \texttt{'-'}.
 
 \begin{figure}[htb]
-  \footnotesize
-    \begin{lstlisting}{}
-    opterr = 0;  /* don't want writing to stderr */
-    while ( (i = getopt(argc, argv, "hp:c:e:")) != -1) {
-        switch (i) {
-        /* 
-         * Handling options 
-         */ 
-        case 'h':   /* help option */
-            printf("Wrong -h option use\n");
-            usage();
-            return -1;
-            break;
-        case 'c':   /* take wait time for childen */
-            wait_child = strtol(optarg, NULL, 10);    /* convert input */
-            break;
-        case 'p':   /* take wait time for childen */
-            wait_parent = strtol(optarg, NULL, 10);   /* convert input */
-            break;
-        case 'e':   /* take wait before parent exit */
-            wait_end = strtol(optarg, NULL, 10);      /* convert input */
-            break;
-        case '?':   /* unrecognized options */
-            printf("Unrecognized options -%c\n",optopt);
-            usage();
-        default:    /* should not reached */
-            usage();
-        }
-    }
-    debug("Optind %d, argc %d\n",optind,argc);
-  \end{lstlisting}
+  \footnotesize \centering
+  \begin{minipage}[c]{15.6cm}
+  \includecodesample{listati/option_code.c}
+  \end{minipage}
+  \normalsize
   \caption{Esempio di codice per la gestione delle opzioni.}
   \label{fig:proc_options_code}
 \end{figure}
@@ -1009,7 +980,7 @@ carattere, in questo modo si possono eseguire azioni specifiche usando uno
 \item \var{int optopt} contiene il carattere dell'opzione non riconosciuta.
 \end{itemize*}
 
-In \figref{fig:proc_options_code} è mostrata la sezione del programma
+In fig.~\ref{fig:proc_options_code} è mostrata la sezione del programma
 \file{ForkTest.c} (che useremo nel prossimo capitolo per effettuare dei test
 sulla creazione dei processi) deputata alla decodifica delle opzioni a riga di
 comando. 
@@ -1058,21 +1029,19 @@ sistema un \textsl{ambiente}, nella forma di una lista di variabili (detta
 \textit{environment list}) messa a disposizione dal processo, e costruita
 nella chiamata alla funzione \func{exec} quando questo viene lanciato.
 
-Come per la lista dei parametri anche questa lista è un array di puntatori a
+Come per la lista dei parametri anche questa lista è un vettore di puntatori a
 caratteri, ciascuno dei quali punta ad una stringa, terminata da un
 \val{NULL}. A differenza di \code{argv[]} in questo caso non si ha una
-lunghezza dell'array data da un equivalente di \param{argc}, ma la lista è
+lunghezza del vettore data da un equivalente di \param{argc}, ma la lista è
 terminata da un puntatore nullo.
 
 L'indirizzo della lista delle variabili di ambiente è passato attraverso la
 variabile globale \var{environ}, a cui si può accedere attraverso una semplice
 dichiarazione del tipo:
-\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
-extern char ** environ;
-\end{lstlisting}
+\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
-\figref{fig:proc_envirno_list}.
+fig.~\ref{fig:proc_envirno_list}.
 \begin{figure}[htb]
   \centering
   \includegraphics[width=11cm]{img/environ_var}
@@ -1082,7 +1051,7 @@ pi
 
 Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
 \textsl{\texttt{nome=valore}}.  Inoltre alcune variabili, come quelle elencate
-in \figref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
+in fig.~\ref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
 da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
 usare nomi espressi in caratteri maiuscoli.\footnote{la convenzione vuole che
   si usino dei nomi maiuscoli per le variabili di ambiente di uso generico, i
@@ -1095,19 +1064,19 @@ costituiscono un modo comodo per definire un comportamento specifico senza
 dover ricorrere all'uso di opzioni a linea di comando o di file di
 configurazione. É di norma cura della shell, quando esegue un comando, passare
 queste variabili al programma messo in esecuzione attraverso un uso opportuno
-delle relative chiamate (si veda \secref{sec:proc_exec}).
+delle relative chiamate (si veda sez.~\ref{sec:proc_exec}).
 
-La shell ad esempio ne usa molte per il suo funzionamento (come \var{PATH} per
-la ricerca dei comandi, o \cmd{IFS} per la scansione degli argomenti), e
-alcune di esse (come \var{HOME}, \var{USER}, etc.) sono definite al login (per
-i dettagli si veda \secref{sec:sess_login}). In genere è cura
+La shell ad esempio ne usa molte per il suo funzionamento (come \texttt{PATH}
+per la ricerca dei comandi, o \texttt{IFS} per la scansione degli argomenti),
+e alcune di esse (come \texttt{HOME}, \texttt{USER}, etc.) sono definite al
+login (per i dettagli si veda sez.~\ref{sec:sess_login}). In genere è cura
 dell'amministratore definire le opportune variabili di ambiente in uno script
 di avvio. Alcune servono poi come riferimento generico per molti programmi
-(come \var{EDITOR} che indica l'editor preferito da invocare in caso di
+(come \texttt{EDITOR} che indica l'editor preferito da invocare in caso di
 necessità).
 
 Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
-comuni), come riportato in \tabref{tab:proc_env_var}. GNU/Linux le supporta
+comuni), come riportato in tab.~\ref{tab:proc_env_var}. GNU/Linux le supporta
 tutte e ne definisce anche altre: per una lista più completa si può
 controllare \cmd{man environ}.
 
@@ -1120,22 +1089,22 @@ controllare \cmd{man environ}.
     & \textbf{Linux} & \textbf{Descrizione} \\
     \hline
     \hline
-    \val{USER} & $\bullet$ & $\bullet$ & $\bullet$ & Nome utente\\
-    \val{LOGNAME} & $\bullet$ & $\bullet$ & $\bullet$ & Nome di login\\
-    \val{HOME} & $\bullet$ & $\bullet$ & $\bullet$ & 
-    Directory base dell'utente\\
-    \val{LANG} & $\bullet$ & $\bullet$ & $\bullet$ & Localizzazione\\
-    \val{PATH} & $\bullet$ & $\bullet$ & $\bullet$ & Elenco delle directory
-                                                     dei programmi\\
-    \val{PWD} & $\bullet$ & $\bullet$ & $\bullet$ & Directory corrente\\
-    \val{SHELL} & $\bullet$ & $\bullet$ & $\bullet$ & Shell in uso\\
-    \val{TERM} & $\bullet$ & $\bullet$ & $\bullet$ & Tipo di terminale\\
-    \val{PAGER} & $\bullet$ & $\bullet$ & $\bullet$ & Programma per vedere i
-                                                      testi\\
-    \val{EDITOR} & $\bullet$ & $\bullet$ & $\bullet$ & Editor preferito\\
-    \val{BROWSER} & $\bullet$ & $\bullet$ & $\bullet$ & Browser preferito\\
-    \val{TMPDIR} & $\bullet$ & $\bullet$ & $\bullet$ & Directory dei file
-                                                       temporanei\\
+    \texttt{USER}   &$\bullet$&$\bullet$&$\bullet$& Nome utente\\
+    \texttt{LOGNAME}&$\bullet$&$\bullet$&$\bullet$& Nome di login\\
+    \texttt{HOME}   &$\bullet$&$\bullet$&$\bullet$& Directory base
+                                                    dell'utente\\
+    \texttt{LANG}   &$\bullet$&$\bullet$&$\bullet$& Localizzazione\\
+    \texttt{PATH}   &$\bullet$&$\bullet$&$\bullet$& Elenco delle directory
+                                                    dei programmi\\
+    \texttt{PWD}    &$\bullet$&$\bullet$&$\bullet$& Directory corrente\\
+    \texttt{SHELL}  &$\bullet$&$\bullet$&$\bullet$& Shell in uso\\
+    \texttt{TERM}   &$\bullet$&$\bullet$&$\bullet$& Tipo di terminale\\
+    \texttt{PAGER}  &$\bullet$&$\bullet$&$\bullet$& Programma per vedere i
+                                                    testi\\
+    \texttt{EDITOR} &$\bullet$&$\bullet$&$\bullet$& Editor preferito\\
+    \texttt{BROWSER}&$\bullet$&$\bullet$&$\bullet$& Browser preferito\\
+    \texttt{TMPDIR} &$\bullet$&$\bullet$&$\bullet$& Directory dei file
+                                                    temporanei\\
     \hline
   \end{tabular}
   \caption{Esempi delle variabili di ambiente più comuni definite da vari
@@ -1160,7 +1129,7 @@ Oltre a questa funzione di lettura, che 
 C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
 utilizzare per impostare e per cancellare le variabili di ambiente. Uno schema
 delle funzioni previste nei vari standard e disponibili in Linux è riportato
-in \tabref{tab:proc_env_func}.
+in tab.~\ref{tab:proc_env_func}.
 
 \begin{table}[htb]
   \centering
@@ -1171,16 +1140,16 @@ in \tabref{tab:proc_env_func}.
     \textbf{SVr4} & \textbf{BSD} & \textbf{Linux} \\
     \hline
     \hline
-    \func{getenv} & $\bullet$ &  $\bullet$ & $\bullet$ & 
-      $\bullet$ & $\bullet$ & $\bullet$ \\
-    \func{setenv} &   &   &    & 
-        & $\bullet$ & $\bullet$ \\
-    \func{unsetenv} &  &   &    & 
-        & $\bullet$ & $\bullet$ \\
-    \func{putenv} &  & opz.  & $\bullet$ & 
-        & $\bullet$ & $\bullet$ \\
-    \func{clearenv} &  & opz.  &    & 
-        &  &  $\bullet$ \\
+    \func{getenv}  & $\bullet$ & $\bullet$ & $\bullet$ 
+                   & $\bullet$ & $\bullet$ & $\bullet$ \\
+    \func{setenv}  &    --     &    --     &   --      
+                   &    --     & $\bullet$ & $\bullet$ \\
+    \func{unsetenv}&    --     &    --     &   --       
+                   &    --     & $\bullet$ & $\bullet$ \\
+    \func{putenv}  &    --     & opz.      & $\bullet$ 
+                   &    --     & $\bullet$ & $\bullet$ \\
+    \func{clearenv}&    --     & opz.      &   --
+                   &    --     &    --     & $\bullet$ \\
     \hline
   \end{tabular}
   \caption{Funzioni per la gestione delle variabili di ambiente.}
@@ -1189,7 +1158,7 @@ in \tabref{tab:proc_env_func}.
 
 In Linux\footnote{in realtà nelle libc4 e libc5 sono definite solo le prime
   quattro, \func{clearenv} è stata introdotta con le \acr{glibc} 2.0.} sono
-definite tutte le funzioni elencate in \tabref{tab:proc_env_func}. La prima,
+definite tutte le funzioni elencate in tab.~\ref{tab:proc_env_func}. La prima,
 \func{getenv}, l'abbiamo appena esaminata; delle restanti le prime due,
 \funcd{putenv} e \funcd{setenv}, servono per assegnare nuove variabili di
 ambiente, i loro prototipi sono i seguenti:
@@ -1235,11 +1204,11 @@ invece esiste il suo valore sar
   seguendo il comportamento di BSD4.4; dato che questo può dar luogo a perdite
   di memoria e non rispetta lo standard. Il comportamento è stato modificato a
   partire dalle 2.1.2, eliminando anche, sempre in conformità a SUSv2,
-  l'attributo \ctyp{const} dal prototipo.} \param{string} alla lista delle
+  l'attributo \direct{const} dal prototipo.} \param{string} alla lista delle
 variabili di ambiente; pertanto ogni cambiamento alla stringa in questione si
 riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
 questa funzione una variabile automatica (per evitare i problemi esposti in
-\secref{sec:proc_auto_var}).
+sez.~\ref{sec:proc_auto_var}).
 
 Si tenga infine presente che se si passa a \func{putenv} solo il nome di una
 variabile (cioè \param{string} è nella forma \texttt{NAME} e non contiene un
@@ -1249,8 +1218,8 @@ versione del vettore \var{environ} questo sar
 corrente sarà deallocata solo se anch'essa è risultante da un'allocazione
 fatta in precedenza da un'altra \func{putenv}. Questo perché il vettore delle
 variabili di ambiente iniziale, creato dalla chiamata ad \func{exec} (vedi
-\secref{sec:proc_exec}) è piazzato al di sopra dello stack, (vedi
-\figref{fig:proc_mem_layout}) e non nello heap e non può essere deallocato.
+sez.~\ref{sec:proc_exec}) è piazzato al di sopra dello stack, (vedi
+fig.~\ref{fig:proc_mem_layout}) e non nello heap e non può essere deallocato.
 Inoltre la memoria associata alle variabili di ambiente eliminate non viene
 liberata.
 
@@ -1317,10 +1286,11 @@ nella programmazione normale.
 
 Talvolta però è necessario che la funzione possa restituire indietro alla
 funzione chiamante un valore relativo ad uno dei suoi parametri.  Per far
-questo si usa il cosiddetto \textit{value result argument}, si passa cioè,
-invece di una normale variabile, un puntatore alla stessa; vedremo alcuni
-esempi di questa modalità nelle funzioni che gestiscono i socket (in
-\secref{sec:TCPel_functions}), in cui, per permettere al kernel di restituire
+questo si usa il cosiddetto
+\index{\textit{value~result~argument}}\textit{value result argument}, si passa
+cioè, invece di una normale variabile, un puntatore alla stessa; vedremo
+alcuni esempi di questa modalità nelle funzioni che gestiscono i socket (in
+sez.~\ref{sec:TCP_functions}), in cui, per permettere al kernel di restituire
 informazioni sulle dimensioni delle strutture degli indirizzi utilizzate,
 viene usato questo meccanismo.
 
@@ -1330,11 +1300,11 @@ viene usato questo meccanismo.
 
 Come vedremo nei capitoli successivi, non sempre è possibile specificare un
 numero fisso di parametri per una funzione.  Lo standard ISO C prevede nella
-sua sintassi la possibilità di definire delle \textit{variadic function} che
-abbiano un numero variabile di argomenti, attraverso l'uso della
-\textit{ellipsis} \code{...} nella dichiarazione della funzione; ma non
-provvede a livello di linguaggio alcun meccanismo con cui dette funzioni
-possono accedere ai loro argomenti.
+sua sintassi la possibilità di definire delle \textit{variadic
+  function}\index{variadic} che abbiano un numero variabile di argomenti,
+attraverso l'uso della \textit{ellipsis} \code{...} nella dichiarazione della
+funzione; ma non provvede a livello di linguaggio alcun meccanismo con cui
+dette funzioni possono accedere ai loro argomenti.
 
 L'accesso viene invece realizzato dalle librerie standard che provvedono gli
 strumenti adeguati.  L'uso delle \textit{variadic function} prevede tre punti:
@@ -1348,14 +1318,12 @@ strumenti adeguati.  L'uso delle \textit{variadic function} prevede tre punti:
   a seguire gli addizionali.
 \end{itemize*}
 
-Lo standard ISO C prevede che una \textit{variadic function} abbia sempre
-almeno un argomento fisso; prima di effettuare la dichiarazione deve essere
-incluso l'apposito header file \file{stdarg.h}; un esempio di dichiarazione è
-il prototipo della funzione \func{execl} che vedremo in
-\secref{sec:proc_exec}:
-\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
-  int execl(const char *path, const char *arg, ...);
-\end{lstlisting}
+Lo standard ISO C prevede che una \textit{variadic function}\index{variadic}
+abbia sempre almeno un argomento fisso; prima di effettuare la dichiarazione
+deve essere incluso l'apposito header file \file{stdarg.h}; un esempio di
+dichiarazione è il prototipo della funzione \func{execl} che vedremo in
+sez.~\ref{sec:proc_exec}:
+\includecodesnip{listati/exec_sample.c}
 in questo caso la funzione prende due parametri fissi ed un numero variabile
 di altri parametri (che verranno a costituire gli elementi successivi al primo
 del vettore \param{argv} passato al nuovo processo). Lo standard ISO C richiede
@@ -1365,10 +1333,10 @@ inoltre che l'ultimo degli argomenti fissi sia di tipo
   per compatibilità; ad esempio i tipi \ctyp{float} vengono convertiti
   automaticamente a \ctyp{double} ed i \ctyp{char} e gli \ctyp{short} ad
   \ctyp{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
-  a sé stesso.} il che esclude array, puntatori a funzioni e interi di tipo
+  a sé stesso.} il che esclude vettori, puntatori a funzioni e interi di tipo
 \ctyp{char} o \ctyp{short} (con segno o meno). Una restrizione ulteriore di
 alcuni compilatori è di non dichiarare l'ultimo parametro fisso come
-\ctyp{register}.
+\direct{register}.
 
 Una volta dichiarata la funzione il secondo passo è accedere ai vari parametri
 quando la si va a definire. I parametri fissi infatti hanno un loro nome, ma
@@ -1437,12 +1405,13 @@ stack all'indirizzo dove sono stati salvati i parametri, 
 normale pensare di poter effettuare questa operazione.
 
 In generale però possono esistere anche realizzazioni diverse, per questo
-motivo \macro{va\_list} è definito come \textsl{tipo opaco} e non può essere
-assegnato direttamente ad un'altra variabile dello stesso tipo. Per risolvere
-questo problema lo standard ISO C99\footnote{alcuni sistemi che non hanno
-  questa macro provvedono al suo posto \macro{\_\_va\_copy} che era il nome
-  proposto in una bozza dello standard.} ha previsto una macro ulteriore che
-permette di eseguire la copia di un puntatore alla lista degli argomenti:
+motivo \macro{va\_list} è definito come \textsl{tipo opaco}\index{tipo!opaco}
+e non può essere assegnato direttamente ad un'altra variabile dello stesso
+tipo. Per risolvere questo problema lo standard ISO C99\footnote{alcuni
+  sistemi che non hanno questa macro provvedono al suo posto
+  \macro{\_\_va\_copy} che era il nome proposto in una bozza dello standard.}
+ha previsto una macro ulteriore che permette di eseguire la copia di un
+puntatore alla lista degli argomenti:
 \begin{prototype}{stdarg.h}{void va\_copy(va\_list dest, va\_list src)}
   Copia l'attuale valore \param{src} del puntatore alla lista degli argomenti
   su \param{dest}.
@@ -1538,7 +1507,7 @@ funzione da cui si era partiti, quando serve.  La funzione che permette di
 salvare il contesto dello stack è \funcd{setjmp}, il cui prototipo è:
 \begin{functions}
   \headdecl{setjmp.h}
-  \funcdecl{void setjmp(jmp\_buf env)}
+  \funcdecl{int setjmp(jmp\_buf env)}
   
   Salva il contesto dello stack. 
 
@@ -1548,7 +1517,12 @@ salvare il contesto dello stack 
 \end{functions}
   
 Quando si esegue la funzione il contesto corrente dello stack viene salvato
-nell'argomento \param{env}, una variabile di tipo \type{jmp\_buf} che deve
+nell'argomento \param{env}, una variabile di tipo
+\type{jmp\_buf}\footnote{questo è un classico esempio di variabile di
+  \textsl{tipo opaco}\index{tipo!opaco}. Si definiscono così strutture ed
+  altri oggetti usati da una libreria, la cui struttura interna non deve
+  essere vista dal programma chiamante (da cui il nome) che li devono
+  utilizzare solo attraverso dalle opportune funzioni di gestione.}  che deve
 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.
@@ -1575,7 +1549,7 @@ un punto precedentemente stabilito con \func{setjmp} si usa la funzione
 \end{functions}
 
 La funzione ripristina il contesto dello stack salvato da una chiamata a
-\func{setjmp} nell'argomento \param{env}. Dopo l'esecuzione della funzione
+\func{setjmp} nell'argomento \param{env}. Dopo l'esecuzione della funzione il
 programma prosegue nel codice successivo al ritorno della \func{setjmp} con
 cui si era salvato \param{env}, che restituirà il valore \param{val} invece di
 zero.  Il valore di \param{val} specificato nella chiamata deve essere diverso
@@ -1614,23 +1588,23 @@ e statiche mantengono i valori che avevano al momento della chiamata di
 \func{longjmp}, ma quelli delle variabili automatiche (o di quelle dichiarate
 \direct{register}\footnote{la direttiva \direct{register} del compilatore
   chiede che la variabile dichiarata tale sia mantenuta, nei limiti del
-  possibile, all'interno di un registro del processore. Questa direttiva
-  origina dai primi compilatori, quando stava al programmatore scrivere codice
-  ottimizzato, riservando esplicitamente alle variabili più usate l'uso dei
-  registri del processore. Oggi questa direttiva oggi è in disuso dato che
-  tutti i compilatori sono normalmente in grado di valutare con maggior
-  efficacia degli stessi programmatori quando sia il caso di eseguire questa
-  ottimizzazione.}) sono in genere indeterminati.
+  possibile, all'interno di un registro del processore. Questa direttiva è
+  originaria dell'epoca dai primi compilatori, quando stava al programmatore
+  scrivere codice ottimizzato, riservando esplicitamente alle variabili più
+  usate l'uso dei registri del processore. Oggi questa direttiva è in disuso
+  dato che tutti i compilatori sono normalmente in grado di valutare con
+  maggior efficacia degli stessi programmatori quando sia il caso di eseguire
+  questa ottimizzazione.}) sono in genere indeterminati.
 
 Quello che succede infatti è che i valori delle variabili che sono tenute in
 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 funzioni vengono salvati nel contesto nello stack)
+chiamata ad un'altra funzione vengono salvati nel contesto nello 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 \ctyp{volatile} informa il compilatore
-  che la variabile che è dichiarata può essere modificata, durante
+\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. Per questo motivo occorre dire
   al compilatore che non deve essere mai utilizzata l'ottimizzazione per cui
   quanto opportuno essa viene mantenuta in un registro, poiché in questo modo