Risistemati i font di tutte le figure, piu qualche aggiunta al resolver

diff --git a/img/IP_AH_packet.dia b/img/IP_AH_packet.dia
index 65c6fbddd0dfb1f00e897d8254bc4a4740815068..f95f16d4475f450cc6eabc4de1d2367e2a6aa5ac 100644 (file)
Binary files a/img/IP_AH_packet.dia and b/img/IP_AH_packet.dia differ

diff --git a/img/dir_links.dia b/img/dir_links.dia
index 7eaf5a31c11c88863615d70214612bddecb509c7..82ac44f90415efc35b77a068814b69248e74b688 100644 (file)
Binary files a/img/dir_links.dia and b/img/dir_links.dia differ

diff --git a/img/dir_struct.dia b/img/dir_struct.dia
index 0c5b0ff87cf38ad7261bf6f4c0c29783a56ef4ff..0c8dd86fdb7d8e7cc1fac85354e19952ea138cb0 100644 (file)
Binary files a/img/dir_struct.dia and b/img/dir_struct.dia differ

diff --git a/img/disk_struct.dia b/img/disk_struct.dia
index c86d957b9f268cd58fd436a6ff9722fd83237f0a..0c248c1505b83589d961a388391fb615eacf91d8 100644 (file)
Binary files a/img/disk_struct.dia and b/img/disk_struct.dia differ

diff --git a/img/environ_var.dia b/img/environ_var.dia
index bd352e85b0bec7de9cb9dde1db996fb3d5cef228..318629baf38ff08dca46af0ba2ce6d28436fb474 100644 (file)
Binary files a/img/environ_var.dia and b/img/environ_var.dia differ

diff --git a/img/esp_option.dia b/img/esp_option.dia
index 5ffbf4799d0e29d27c835597f6061e358b867f7d..39a560b5870c04ec03f04c4515301eaec1f41333 100644 (file)
Binary files a/img/esp_option.dia and b/img/esp_option.dia differ

diff --git a/img/exec_rel.dia b/img/exec_rel.dia
index 7daeb1d337decfc3222738e1585a7d63c64cb063..f06e93409fbdc457aad4dbb8c1db6491f79d1fcb 100644 (file)
Binary files a/img/exec_rel.dia and b/img/exec_rel.dia differ

diff --git a/img/fifoserver.dia b/img/fifoserver.dia
index 4ce7c8b489a1b5cc664ac9420ce4c8a66aa80420..93b3496b4fa9ee8f460e86e8082a86ff869ac20a 100644 (file)
Binary files a/img/fifoserver.dia and b/img/fifoserver.dia differ

diff --git a/img/file_flock.dia b/img/file_flock.dia
index 7c30fd8f7a805266e9158a287731c312b0767ff3..5a10b255320e21530d272513a2009d8aa978a5c3 100644 (file)
Binary files a/img/file_flock.dia and b/img/file_flock.dia differ

diff --git a/img/file_lock_dead.dia b/img/file_lock_dead.dia
index a414a5d33775e3bddfa23500159d27fe26a17d2c..c7d2699dbae88c988992cb8621b64f3ce9eb15ed 100644 (file)
Binary files a/img/file_lock_dead.dia and b/img/file_lock_dead.dia differ

diff --git a/img/file_posix_lock.dia b/img/file_posix_lock.dia
index bb7c248a77f30d9f2c5e02998b2029673cdca5be..89a610aafbf055ab98db8cdd94b026655cb7e06f 100644 (file)
Binary files a/img/file_posix_lock.dia and b/img/file_posix_lock.dia differ

diff --git a/img/filedup.dia b/img/filedup.dia
index 06e0e35997d46945f23f5c23d4521debd92469f0..14771736bb47757c734a092e6a9c69b15f3ca072 100644 (file)
Binary files a/img/filedup.dia and b/img/filedup.dia differ

diff --git a/img/filemultacc.dia b/img/filemultacc.dia
index 587c3c224eaf028056241d0f5c00dfd5d2b015cc..5393ff1af27681f77df448c0038b3a613d777679 100644 (file)
Binary files a/img/filemultacc.dia and b/img/filemultacc.dia differ

diff --git a/img/fileperm.dia b/img/fileperm.dia
index 19474b524dde3c9c4378b3b1f1cdccbfc8b9739e..47b6ee82572fd51d77689888f15e53ee291547ac 100644 (file)
Binary files a/img/fileperm.dia and b/img/fileperm.dia differ

diff --git a/img/fileshar.dia b/img/fileshar.dia
index 97eb2892757d4efad4e0e1fea3ef888dbb3c6c9a..077ceb01c4b0919a5a403b8ed2f364e1ed4704a9 100644 (file)
Binary files a/img/fileshar.dia and b/img/fileshar.dia differ

diff --git a/img/filesys_struct.dia b/img/filesys_struct.dia
index 49ac7738f3a3af7931e7b6fd09e482a00eff3548..f9562562f36fac45e83aa6a4cc7cffa570ee8c25 100644 (file)
Binary files a/img/filesys_struct.dia and b/img/filesys_struct.dia differ

diff --git a/img/ipv6_head.dia b/img/ipv6_head.dia
index 4fe96fb5a4a903e27c8b04490ff88cde8c9b1782..34ce58783f9523192c88d6019105998003f57089 100644 (file)
Binary files a/img/ipv6_head.dia and b/img/ipv6_head.dia differ

diff --git a/img/iso_tcp_comp.dia b/img/iso_tcp_comp.dia
index 501183df4a65ffed910995c2123753d53a3cb266..b7a9b18f8ca12c6bf99f9a4c7e5869a74c05d2ea 100644 (file)
Binary files a/img/iso_tcp_comp.dia and b/img/iso_tcp_comp.dia differ

diff --git a/img/memory_layout.dia b/img/memory_layout.dia
index a2b20df9b69bf46f0bda4083d09b0ce1735c5438..87189aeff8eca33e5f2d89dec5fbc8fdbe641680 100644 (file)
Binary files a/img/memory_layout.dia and b/img/memory_layout.dia differ

diff --git a/img/mmap_boundary.dia b/img/mmap_boundary.dia
index edff5d4f1e6c2da14096a9b5e3be117b1d7965c6..29956d363ec827c0999138f5f22c4d962287f2da 100644 (file)
Binary files a/img/mmap_boundary.dia and b/img/mmap_boundary.dia differ

diff --git a/img/mmap_exceed.dia b/img/mmap_exceed.dia
index 2a77fa3eff705835774e0d75a840f1d90573efd2..8630e39202f33fbcca9c69ef0357e9e12181c477 100644 (file)
Binary files a/img/mmap_exceed.dia and b/img/mmap_exceed.dia differ

diff --git a/img/mmap_layout.dia b/img/mmap_layout.dia
index 7978d5a83aeabb88390ddf4628c95b54c81de99b..bfb34bfa8f014a301e820204320ec8303acb7a86 100644 (file)
Binary files a/img/mmap_layout.dia and b/img/mmap_layout.dia differ

diff --git a/img/mqstruct.dia b/img/mqstruct.dia
index 07c5127e122ef67a0b47fcc02ba1730016dd5a1a..f3ebe0a101c846dc2199b4ea7a14c09bbedb1c5a 100644 (file)
Binary files a/img/mqstruct.dia and b/img/mqstruct.dia differ

diff --git a/img/pipe.dia b/img/pipe.dia
index 349b393cd25a3e63dcb34664a1dca51dd93173eb..8be4c57d318eb0fbcb5b4427b36ce39d05bf3d9c 100644 (file)
Binary files a/img/pipe.dia and b/img/pipe.dia differ

diff --git a/img/pipefork.dia b/img/pipefork.dia
index d8e57dac1558871f3e34427c94b0a387968ed3d7..e64a081fdb65910009d5a3ce58c3df4e18f16410 100644 (file)
Binary files a/img/pipefork.dia and b/img/pipefork.dia differ

diff --git a/img/pipeuse.dia b/img/pipeuse.dia
index 9f4d609ae2a7353bf3d21c232d0edf2d52cce9b2..e3f62ae9976d3577eaf1d8a6826a68236e737067 100644 (file)
Binary files a/img/pipeuse.dia and b/img/pipeuse.dia differ

diff --git a/img/port_alloc.dia b/img/port_alloc.dia
index a116b97ce1a309d11d600fb9a8cf3bb884b0b3ec..90885d23841deb00f9ce52b4ed4ec903c6533354 100644 (file)
Binary files a/img/port_alloc.dia and b/img/port_alloc.dia differ

diff --git a/img/proc_beginend.dia b/img/proc_beginend.dia
index 75a5da13b00cd8a0ce80fd62d39801af4fa522a9..181bf26b6974554abba296fc15d1fa77a8e65019 100644 (file)
Binary files a/img/proc_beginend.dia and b/img/proc_beginend.dia differ

diff --git a/img/proc_exit.dia b/img/proc_exit.dia
index b2f2e820e546f7c00f208b3e9278f3871e3845d3..86c75ca325b8ddfdf63065b7abf1868230cfb444 100644 (file)
Binary files a/img/proc_exit.dia and b/img/proc_exit.dia differ

diff --git a/img/procfile.dia b/img/procfile.dia
index adff9e72a0ee7d7f14028ab5eb9310eaf9429814..d4a21ca23f402b9e8eed897171b58dcb3ad6cf73 100644 (file)
Binary files a/img/procfile.dia and b/img/procfile.dia differ

diff --git a/img/semtruct.dia b/img/semtruct.dia
index 0744183d1a366cb2d7b2b3ddc1b6782e41b7f429..80856c32de833126c497876583e7f302cb26f102 100644 (file)
Binary files a/img/semtruct.dia and b/img/semtruct.dia differ

diff --git a/img/sh_memory_layout.dia b/img/sh_memory_layout.dia
index 5d64ed2c235a96c033de35d44851b709662c702b..9e7f5004d6286e6d90b171793c6d46a01b16ef85 100644 (file)
Binary files a/img/sh_memory_layout.dia and b/img/sh_memory_layout.dia differ

diff --git a/img/struct_sys.dia b/img/struct_sys.dia
index 96ef2d5f306dd3bbf25cc2942db1c0b610f0d5f5..cc9c1a0ad149095f3f826c436d39ccccf04db19c 100644 (file)
Binary files a/img/struct_sys.dia and b/img/struct_sys.dia differ

diff --git a/img/task_struct.dia b/img/task_struct.dia
index 2095decf67de4f2cbf435679b077ef16a435871c..585939016fe6e04fc7d4fd41a53081e0820d87f4 100644 (file)
Binary files a/img/task_struct.dia and b/img/task_struct.dia differ

diff --git a/img/tcp_client_early_abort.dia b/img/tcp_client_early_abort.dia
index 6c0472ba912036bb5c270e758d64488d514f965c..72ca2f8bf94acf2bb00a9221bda7558eba81ac67 100644 (file)
Binary files a/img/tcp_client_early_abort.dia and b/img/tcp_client_early_abort.dia differ

diff --git a/img/tcp_close.dia b/img/tcp_close.dia
index 1be6432343bb136ff36eb00ed1b82f4efd20311e..94b132ebedabd2b047ab0483e93edec502e69369 100644 (file)
Binary files a/img/tcp_close.dia and b/img/tcp_close.dia differ

diff --git a/img/tcp_connection.dia b/img/tcp_connection.dia
index 0605752cd1d478e38fd4c6f489122844b1efe3bf..e827544f14663359c0d9d4b5a2d1d510fe112400 100644 (file)
Binary files a/img/tcp_connection.dia and b/img/tcp_connection.dia differ

diff --git a/img/tcp_data_flux.dia b/img/tcp_data_flux.dia
index f760045c614b7bdccf7cd0b2e172ecf6dc8eb05c..f587f3987bbaeae12746d7ce487621414350c9db 100644 (file)
Binary files a/img/tcp_data_flux.dia and b/img/tcp_data_flux.dia differ

diff --git a/img/tcpip_overview.dia b/img/tcpip_overview.dia
index 26b22546edebe19dce133e543e0a914ace612af5..d82bb4bfbf8f26b6a22da52e906a80f83d83d9f4 100644 (file)
Binary files a/img/tcpip_overview.dia and b/img/tcpip_overview.dia differ

diff --git a/img/term_struct.dia b/img/term_struct.dia
index e3d833af01bbe316516ebf745bdf975474fd5502..0643f346a19ed292111831a76bf274b3f9b73745 100644 (file)
Binary files a/img/term_struct.dia and b/img/term_struct.dia differ

diff --git a/img/three_way_handshake.dia b/img/three_way_handshake.dia
index 2b4cdada6131d322388720f80e238ab9f7f13b9d..03578c5468d7ff804b06a1daa1cf1b7fcd0567e3 100644 (file)
Binary files a/img/three_way_handshake.dia and b/img/three_way_handshake.dia differ

diff --git a/img/tty_login.dia b/img/tty_login.dia
index e6d222fb993ffe210eebef9acd69aab22cb0e684..096e50c32166fc68ca68d22c0a13083c3ebcdd25 100644 (file)
Binary files a/img/tty_login.dia and b/img/tty_login.dia differ

diff --git a/img/udp_connection.dia b/img/udp_connection.dia
index d44c6c38e47957ba1dfec004609f6dde29c48c4e..d19630a55c6409a78d93cab3bc996840289321c7 100644 (file)
Binary files a/img/udp_connection.dia and b/img/udp_connection.dia differ

diff --git a/img/vfs.dia b/img/vfs.dia
index d296836923ecd3d96c8b8e4dc543fd2a892053e5..1052b7995325bf2c2f7706e7202982d56b4a7a29 100644 (file)
Binary files a/img/vfs.dia and b/img/vfs.dia differ

diff --git a/process.tex b/process.tex
index 39e01017ab7dcdb361b59780adb902d6d7e9e435..b21dc6b9c3978b7917ffd3ce920853d5ac93fa40 100644 (file)
--- a/process.tex
+++ b/process.tex
@@ -63,7 +63,7 @@ linea di comando, in sostanza un prototipo che va sempre bene 
 
 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
 
 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.
 
 del programma; questa forma però non è prevista dallo standard POSIX.1 per cui
 se si vogliono scrivere programmi portabili è meglio evitarla.
 


@@ -81,7 +81,7 @@ controllo direttamente alla routine di conclusione dei processi del kernel.
 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 \capref{cha:signals}) o della chiamata alla funzione
 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 \capref{cha:signals}) o della chiamata alla funzione

-\func{abort}; torneremo su questo in \secref{sec:proc_termination}.
+\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
 
 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


@@ -107,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
 
 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
 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


@@ -134,9 +134,9 @@ dallo 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
 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
 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,
 \func{\_exit} e restituendo il valore di \param{status} come stato di uscita.
 
 La system call \funcd{\_exit} restituisce direttamente il controllo al kernel,


@@ -152,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
 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
+sez.~\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
 specificato in \param{status} che può essere raccolto usando la funzione

-\func{wait} (vedi \secref{sec:proc_wait}).
+\func{wait} (vedi sez.~\ref{sec:proc_wait}).

 
 
 \subsection{Le funzioni \func{atexit} e \func{on\_exit}}
 
 
 \subsection{Le funzioni \func{atexit} e \func{on\_exit}}


@@ -220,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
 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
 
 Allo stesso modo l'unico modo in cui un programma può concludere
 volontariamente la sua esecuzione è attraverso una chiamata alla system call


@@ -228,18 +228,18 @@ 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
 \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
 
 \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
   \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
+fig.~\ref{fig:proc_prog_start_stop}); torneremo su questo aspetto in

 \capref{cha:signals}.
 
 
 \capref{cha:signals}.
 
 


@@ -380,7 +380,7 @@ seguenti segmenti:
   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
   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
   al segmento dati) ha una posizione fissa.
   
 \item Il segmento di \textit{stack}, che contiene lo \textit{stack} del


@@ -400,13 +400,13 @@ seguenti segmenti:
 
 \begin{figure}[htb]
   \centering
 
 \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
   \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
 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


@@ -545,7 +545,7 @@ tollerante nei confronti di piccoli errori come quello di chiamate doppie a
 \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}
 \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}
 \item se è posta a 2 viene chiamata \func{abort}, che in genere causa
   l'immediata conclusione del programma.
 \end{itemize}


@@ -634,7 +634,7 @@ Come 
 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
 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 \secref{sec:proc_longjmp}).
+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
 
 Un altro vantaggio è che in Linux la funzione è molto più veloce di
 \func{malloc} e non viene sprecato spazio, infatti non è necessario gestire un


@@ -661,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
 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}}  
 
 
 \subsection{Le funzioni \func{brk} e \func{sbrk}}  


@@ -670,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
 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.
   
 \begin{prototype}{unistd.h}{int brk(void *end\_data\_segment)}
   Sposta la fine del segmento dei dati.
   


@@ -683,7 +683,7 @@ La funzione 
 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
 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
 dimensioni massime dello spazio dati del processo.
 
 La seconda funzione per la manipolazione delle dimensioni del segmento


@@ -713,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}
 
 \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.
 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.


@@ -737,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
   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
   
 \item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro
   in memoria queste possono essere portate su disco dal meccanismo della


@@ -766,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
 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.}
   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.}


@@ -774,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
 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.
 
 capacità di bloccare una pagina.  Ogni processo può però sbloccare le pagine
 relative alla propria memoria.
 


@@ -873,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},
 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
 
 Oltre al passaggio dei parametri, un'altra modalità che permette di passare
 delle informazioni che modifichino il comportamento di un programma è quello


@@ -906,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
 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}
 
 
 \subsection{La gestione delle opzioni}


@@ -919,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
 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}).
 
 e la prima vuole un parametro mentre la seconda no (\cmd{questofile.txt} è un
 argomento del programma, non un parametro di \cmd{-m}).
 


@@ -945,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
 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
 stringa di opzioni avrebbe dovuto contenere \texttt{"r:m"}.
 
 La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la


@@ -980,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*}
 
 \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. 
 \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. 


@@ -1041,7 +1041,7 @@ 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
 \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}
 \begin{figure}[htb]
   \centering
   \includegraphics[width=11cm]{img/environ_var}


@@ -1051,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
 
 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
 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


@@ -1064,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
 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
 
 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
+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
 necessità).
 
 Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
 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
 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}.
 
 tutte e ne definisce anche altre: per una lista più completa si può
 controllare \cmd{man environ}.
 


@@ -1129,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
 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
 
 \begin{table}[htb]
   \centering


@@ -1158,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
 
 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:
 \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:


@@ -1208,7 +1208,7 @@ invece esiste il suo valore sar
 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
 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
 
 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


@@ -1218,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
 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.
 
 Inoltre la memoria associata alle variabili di ambiente eliminate non viene
 liberata.
 


@@ -1289,7 +1289,7 @@ 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
 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:TCP_functions}), in cui, per permettere al kernel di restituire
+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.
 
 informazioni sulle dimensioni delle strutture degli indirizzi utilizzate,
 viene usato questo meccanismo.
 


@@ -1321,7 +1321,7 @@ 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
 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}:
+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
 \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

diff --git a/sockctrl.tex b/sockctrl.tex
index 7a7d12fd6c7ad7e8efb9f6fd6df074f9b259df5b..eec51ecf19485044bac87a036036176cc952e00e 100644 (file)
--- a/sockctrl.tex
+++ b/sockctrl.tex
@@ -170,13 +170,12 @@ carattere ``\texttt{:}'' e  prosegue con la lista dei  \textsl{servizi} su cui
 le  relative informazioni sono  raggiungibili, scritti  nell'ordine in  cui si
 vuole siano interrogati.
 
 le  relative informazioni sono  raggiungibili, scritti  nell'ordine in  cui si
 vuole siano interrogati.
 

-Ciascun servizio è specificato a sua volta da un nome, come \texttt{file},
+Ogni servizio è specificato a sua volta da un nome, come \texttt{file},

 \texttt{dns}, \texttt{db}, ecc. che identifica la libreria dinamica che
 \texttt{dns}, \texttt{db}, ecc. che identifica la libreria dinamica che

-realizza l'interfaccia con esso, che per ciascuno di essi sarà realizzata in
-un file \texttt{libnss\_NAME} dove \texttt{NAME} è appunto il nome 
-
-
-
+realizza l'interfaccia con esso. Per ciascun servizio se \texttt{NAME} è il
+nome utilizzato dentro \file{/etc/nsswitch.conf}, dovrà essere presente
+(usualmente in \file{/lib}) una libreria \texttt{libnss\_NAME} che ne
+implementa le funzioni. 

 
 In ogni caso, qualunque sia la modalità con cui ricevono i dati o il supporto
 su cui vengono mantenuti, e che si usino o meno funzionalità aggiuntive
 
 In ogni caso, qualunque sia la modalità con cui ricevono i dati o il supporto
 su cui vengono mantenuti, e che si usino o meno funzionalità aggiuntive


@@ -188,6 +187,54 @@ disposizione,\footnote{
 quelle che tratteremo nelle sezioni successive.
 
 
 quelle che tratteremo nelle sezioni successive.
 
 

+\subsection{Le funzioni di interrogazione del \textit{resolver}}
+\label{sec:sock_resolver_functions}
+
+Prima di trattare le funzioni usate normalmente nella risoluzione dei nomi a
+dominio conviene trattare in maniera più dettagliata il meccanismo principale
+da esse utilizzato e cioè quello del servizio DNS. Come accennato questo,
+benché in teoria sia solo uno dei possibili supporti su cui mantenere le
+relative informazioni, in pratica costituisce il meccanismo principale
+
+
+Per questo motivo il \textit{resolver} prevede delle funzioni che permettono
+sia di eseguire direttamente delle interrogazione ad un server DNS, che di
+controllare le modalità con cui queste vengono eseguite; diventa così
+possibile modificare da programma buona parte dei parametri controllati da
+\file{/etc/resolv.conf}.
+
+
+
+Per capire meglio il contenuto della struttura \struct{hostent} conviene
+spendere alcune parole sul funzionamento del DNS. Questo in sostanza è un
+database distribuito organizzato in maniera gerarchica, interrogando il quale
+si possono avere una serie di informazioni, la principale delle quali è la
+corrispondenza fra un nome (a dominio) ed indirizzo IP.  Un server DNS
+contiene comunque una serie di altre informazioni; ciascuna voce nel database
+viene chiamata \textit{resource record} e vi è associato un certo
+\textsl{tipo}, identificato da una sigla.  Per quanto ci interessa i tipi di
+\textit{resource record} che vengono utilizzati dal \textit{resolver} sono
+sostanzialmente i seguenti:
+\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
+\item[\texttt{A}] indica la corripondenza fra un nome a dominio ed un
+  indirizzo IPv4, ad esempio la corrispondenza fra \texttt{dodds.truelite.it}
+  e l'indirizzo IP \texttt{62.48.34.25}.
+\item[\texttt{AAAA}] chiamato in questo modo dato che la dimensione è quattro
+  volte quella di un indirizzo IPv4, questo record contiene la corrispondenza
+  fra un nome a dominio ed un indirizzo IPv6.
+\item[\texttt{PTR}] per provvedere la mappatura inversa fra un indirizzo IP ed
+  un nome a dominio si utilizza invece questo tipo di record (il cui nome sta
+  per \textit{pointer}).
+\item[\texttt{CNAME}] qualora si abbiamo più nomi con i quali si voglia
+  indicare lo stesso indirizzo (ad esempio \texttt{www.truelite.it}, o
+  \texttt{sources.truelite.it}, che comunque fanno sempre riferimento alla
+  macchina \texttt{dodds.truelite.it}) si può usare questo tipo di record per
+  creare degli \textit{alias} in modo da associare un qualunque altro nome al
+  \textsl{nome canonico} della macchina (quello associato al record
+  \texttt{A}).
+\end{basedescript}
+
+

 
 \subsection{La risoluzione dei nomi a dominio}
 \label{sec:sock_gethostbyname}
 
 \subsection{La risoluzione dei nomi a dominio}
 \label{sec:sock_gethostbyname}


@@ -246,35 +293,6 @@ ed i valori che pu
   di un server DNS, si può ritentare l'interrogazione in un secondo tempo. 
 \end{basedescript}
 
   di un server DNS, si può ritentare l'interrogazione in un secondo tempo. 
 \end{basedescript}
 

-Per capire meglio il contenuto della struttura \struct{hostent} conviene
-spendere alcune parole sul funzionamento del DNS. Questo in sostanza è un
-database distribuito organizzato in maniera gerarchica, interrogando il quale
-si possono avere una serie di informazioni, la principale delle quali è la
-corrispondenza fra un nome (a dominio) ed indirizzo IP.  Un server DNS
-contiene comunque una serie di altre informazioni; ciascuna voce nel database
-viene chiamata \textit{resource record} e vi è associato un certo
-\textsl{tipo}, identificato da una sigla.  Per quanto ci interessa i tipi di
-\textit{resource record} che vengono utilizzati dal \textit{resolver} sono
-sostanzialmente i seguenti:
-\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\texttt{A}] indica la corripondenza fra un nome a dominio ed un
-  indirizzo IPv4, ad esempio la corrispondenza fra \texttt{dodds.truelite.it}
-  e l'indirizzo IP \texttt{62.48.34.25}.
-\item[\texttt{AAAA}] chiamato in questo modo dato che la dimensione è quattro
-  volte quella di un indirizzo IPv4, questo record contiene la corrispondenza
-  fra un nome a dominio ed un indirizzo IPv6.
-\item[\texttt{PTR}] per provvedere la mappatura inversa fra un indirizzo IP ed
-  un nome a dominio si utilizza invece questo tipo di record (il cui nome sta
-  per \textit{pointer}).
-\item[\texttt{CNAME}] qualora si abbiamo più nomi con i quali si voglia
-  indicare lo stesso indirizzo (ad esempio \texttt{www.truelite.it}, o
-  \texttt{sources.truelite.it}, che comunque fanno sempre riferimento alla
-  macchina \texttt{dodds.truelite.it}) si può usare questo tipo di record per
-  creare degli \textit{alias} in modo da associare un qualunque altro nome al
-  \textsl{nome canonico} della macchina (quello associato al record
-  \texttt{A}).
-\end{basedescript}
-

 Quando un programma chiama \func{gethostbyname} e questa usa il DNS per
 effettuare la risoluzione del nome, è con i valori di questi record che
 vengono riempite le varie parti della struttura \struct{hostent}. Il primo
 Quando un programma chiama \func{gethostbyname} e questa usa il DNS per
 effettuare la risoluzione del nome, è con i valori di questi record che
 vengono riempite le varie parti della struttura \struct{hostent}. Il primo


@@ -289,14 +307,14 @@ DNS vengono inseriti come record di tipo \texttt{CNAME}).
 Il terzo campo della struttura, \var{h\_addrtype}, indica il tipo di indirizzo
 che è stato restituito, e può assumere soltanto i valori \const{AF\_INET} o
 \const{AF\_INET6}, mentre il quarto campo, \var{h\_length}, indica la
 Il terzo campo della struttura, \var{h\_addrtype}, indica il tipo di indirizzo
 che è stato restituito, e può assumere soltanto i valori \const{AF\_INET} o
 \const{AF\_INET6}, mentre il quarto campo, \var{h\_length}, indica la

-lunghezza dell'indirizzo stesso in byte. Infine il campo \var{h\_addr\_list} è
-il puntatore ad un vettore di puntatori ai singoli indirizzi; il vettore è
-terminato da un puntatore nullo.  Inoltre, come illustrato in
-fig.~\ref{fig:sock_hostent_struct}, viene definito il campo \var{h\_addr} come
-sinonimo di \code{h\_addr\_list[0]}, cioè un riferimento diretto al primo
-indirizzo della lista.
-
-
+lunghezza dell'indirizzo stesso in byte. La funzione ritorna sempre una
+struttura 
+
+Infine il campo \var{h\_addr\_list} è il puntatore ad un vettore di puntatori
+ai singoli indirizzi; il vettore è terminato da un puntatore nullo.  Inoltre,
+come illustrato in fig.~\ref{fig:sock_hostent_struct}, viene definito il campo
+\var{h\_addr} come sinonimo di \code{h\_addr\_list[0]}, cioè un riferimento
+diretto al primo indirizzo della lista.

 
 Oltre ai normali nomi a dominio la funzione accetta come argomento
 \param{name} anche indirizzi numerici, in formato dotted decimal per IPv4 o
 
 Oltre ai normali nomi a dominio la funzione accetta come argomento
 \param{name} anche indirizzi numerici, in formato dotted decimal per IPv4 o