Correzioni varie di poco conto
authorSimone Piccardi <piccardi@gnulinux.it>
Sat, 10 Aug 2002 15:54:36 +0000 (15:54 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sat, 10 Aug 2002 15:54:36 +0000 (15:54 +0000)
13 files changed:
elemtcp.tex
errors.tex
filedir.tex
filestd.tex
fileunix.tex
gapil.tex
img/ipv6_head.dia
ipprot.tex
pref.tex
process.tex
signal.tex
socket.tex
system.tex

index 1678559..964dd4f 100644 (file)
@@ -823,7 +823,7 @@ sostanza l'effetto della funzione 
 \texttt{CLOSED} a quello \texttt{LISTEN}. In genere si chiama la funzione in
 un server dopo le chiamate a \func{socket} e \func{bind} e prima della
 chiamata ad \func{accept}. Il prototipo della funzione come definito dalla
-man page è:
+pagina di manuale è:
 \begin{prototype}{sys/socket.h}{int listen(int sockfd, int backlog)}
   La funzione pone il socket specificato da \var{sockfd} in modalità
   passiva e predispone una coda per le connessioni in arrivo di lunghezza pari
@@ -1262,11 +1262,11 @@ connesso (\cmd{inetd} ad esempio fa sempre in modo che i file descriptor 0,
 1 e 2 corrispondano al socket connesso) quest'ultimo potrà usare la funzione
 \func{getpeername} per determinare l'indirizzo remoto del client.
 
-Infine è da chiarire (si legga la man page) che come per \func{accept} il
-terzo parametro che è specificato dallo standard POSIX 1003.1g come di tipo
-\code{socklen\_t *} in realtà deve sempre corrispondere ad un \ctyp{int *}
-come prima dello standard perché tutte le implementazioni dei socket BSD fanno
-questa assunzione.
+Infine è da chiarire (si legga la pagina di manuale) che, come per
+\func{accept}, il terzo parametro, che è specificato dallo standard POSIX.1g
+come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un
+\ctyp{int *} come prima dello standard perché tutte le implementazioni dei
+socket BSD fanno questa assunzione.
 
 
 
index 547bb1c..a75e0e1 100644 (file)
@@ -73,7 +73,8 @@ gestione dei file.
 \item \macro{EMFILE} \textit{Too many open files}. Il processo corrente ha
   troppi file aperti e non può aprirne altri. Anche i descrittori duplicati
   vengono tenuti in conto\footnote{Il numero massimo di file aperti è
-    controllabile dal sistema, in Linux si può usare il comando \cmd{ulimit}}.
+    controllabile dal sistema, in Linux si può usare il comando
+    \cmd{ulimit}.}.
 \item \macro{ENFILE} \textit{File table overflow}. Ci sono troppi file aperti
   nel sistema. 
 \item \macro{ENOTTY} \textit{Not a terminal}. Si è tentata una operazione di
index d1d8606..b734c44 100644 (file)
@@ -53,7 +53,7 @@ rispetto agli altri.
 Per aggiungere un nome ad un inode si utilizza la funzione \func{link}; si
 suole chiamare questo tipo di associazione un collegamento diretto (o
 \textit{hard link}).  Il prototipo della funzione e le sue caratteristiche
-principali, come risultano dalla man page, sono le seguenti:
+principali, come risultano dalla pagina di manuale, sono le seguenti:
 \begin{prototype}{unistd.h}
 {int link(const char *oldpath, const char *newpath)}
   Crea un nuovo collegamento diretto al file indicato da \var{oldpath}
@@ -920,10 +920,10 @@ su un file, su un link simbolico e su un file descriptor.
 
 La struttura \var{stat} usata da queste funzioni è definita nell'header
 \file{sys/stat.h} e in generale dipende dall'implementazione, la versione
-usata da Linux è mostrata in \nfig, così come riportata dalla man page di
-\func{stat} (in realtà la definizione effettivamente usata nel kernel dipende
-dall'architettura e ha altri campi riservati per estensioni come tempi più
-precisi, o per il padding dei campi).
+usata da Linux è mostrata in \nfig, così come riportata dalla pagina di
+manuale di \func{stat} (in realtà la definizione effettivamente usata nel
+kernel dipende dall'architettura e ha altri campi riservati per estensioni
+come tempi più precisi, o per il padding dei campi).
 
 \begin{figure}[!htb]
   \footnotesize
index 921f082..a3e719f 100644 (file)
@@ -1056,8 +1056,8 @@ questo ordine:
 \end{itemize*}
 
 
-Dettagli ulteriori sulle varie opzioni possono essere trovati nella man page
-di \func{printf} e nella documentazione delle \acr{glibc}.
+Dettagli ulteriori sulle varie opzioni possono essere trovati nella pagina di
+manuale di \func{printf} e nella documentazione delle \acr{glibc}.
 
 \begin{table}[htb]
   \centering
@@ -1204,7 +1204,7 @@ spazio in \param{format} corrisponde con un numero qualunque di caratteri di
 separazione (che possono essere spazi, tabulatori, virgole etc.), mentre
 caratteri diversi richiedono una corrispondenza esatta. Le direttive di
 conversione sono analoghe a quelle di \func{printf} e si trovano descritte in
-dettaglio nelle man page e nel manuale delle \acr{glibc}.
+dettaglio nelle pagine di manuale e nel manuale delle \acr{glibc}.
 
 Le funzioni eseguono la lettura dall'input, scartano i separatori (e gli
 eventuali caratteri diversi indicati dalla stringa di formato) effettuando le
index d430199..c83cc73 100644 (file)
@@ -292,10 +292,10 @@ sempre il file descriptor con il valore pi
   \label{tab:file_open_flags}
 \end{table}
 
-\footnotetext[2]{la man page di \func{open} segnala che questa opzione è
-  difettosa su NFS, e che i programmi che la usano per stabilire un file di
-  lock possono incorrere in una race condition\index{race condition}.  Si
-  consiglia come alternativa di usare un file con un nome univoco e la
+\footnotetext[2]{la pagina di manuale di \func{open} segnala che questa
+  opzione è difettosa su NFS, e che i programmi che la usano per stabilire un
+  file di lock possono incorrere in una race condition\index{race condition}.
+  Si consiglia come alternativa di usare un file con un nome univoco e la
   funzione \func{link} per verificarne l'esistenza.}
 
 \footnotetext[3]{\textit{Denial of Service}, si chiamano così attacchi miranti
@@ -1002,9 +1002,9 @@ valori 
   di \tabref{tab:file_open_flags}). 
 \item[\macro{F\_SETFL}] imposta il \textit{file status flag} al valore
   specificato da \param{arg}, possono essere impostati solo i bit riportati
-  nella terza sezione di \tabref{tab:file_open_flags}.\footnote{la man page
-    riporta come impostabili solo \macro{O\_APPEND}, \macro{O\_NONBLOCK} e
-    \macro{O\_ASYNC}.}
+  nella terza sezione di \tabref{tab:file_open_flags}.\footnote{la pagina di
+    manuale riporta come impostabili solo \macro{O\_APPEND},
+    \macro{O\_NONBLOCK} e \macro{O\_ASYNC}.}
 \item[\macro{F\_GETLK}] se un file lock è attivo restituisce nella struttura
   \param{lock} la struttura \type{flock} che impedisce l'acquisizione del
   blocco, altrimenti imposta il campo \var{l\_type} a \macro{F\_UNLCK} (per i
index 6392012..be7b703 100644 (file)
--- a/gapil.tex
+++ b/gapil.tex
@@ -21,8 +21,8 @@
 \usepackage{listings}
 \lstloadlanguages{C++}
 \usepackage{color} 
-%\usepackage{mdwlist}              % scommentare per la stampa (PS e PDF)
-%\usepackage{boxedminipage}        % scommentare per la stampa (PS e PDF)
+\usepackage{mdwlist}              % scommentare per la stampa (PS e PDF)
+\usepackage{boxedminipage}        % scommentare per la stampa (PS e PDF)
 %\usepackage{footnote} 
 %\usepackage{mdwtab} 
 %
@@ -73,7 +73,7 @@
 \tableofcontents
 \clearemptydoublepage
 
-\include{compatib}    % commentare per la stampa PS e PDF
+%\include{compatib}    % commentare per la stampa PS e PDF
 \include{macro}
 \setcounter{secnumdepth}{-2}
 \include{pref}
index 47bc364..2d2e75f 100644 (file)
Binary files a/img/ipv6_head.dia and b/img/ipv6_head.dia differ
index b1362a3..6faf9eb 100644 (file)
@@ -241,45 +241,53 @@ grandi linee nei seguenti punti:
 
 Per capire le caratteristiche di IPv6 partiamo dall'intestazione usata dal
 protocollo per gestire la trasmissione dei pacchetti; in
-\tabref{tab:IP_ipv6head} è riportato il formato dell'intestazione di IPv6 da
-confrontare con quella di IPv4 in \tabref{tab:IP_ipv4head}. La spiegazione del
+\figref{fig:IP_ipv6head} è riportato il formato dell'intestazione di IPv6 da
+confrontare con quella di IPv4 in \figref{fig:IP_ipv4head}. La spiegazione del
 significato dei vari campi delle due intestazioni è riportato rispettivamente
 in \tabref{tab:IP_ipv6field} e \tabref{tab:IP_ipv4field})
 
-\begin{table}[htb]
-  \footnotesize
-  \begin{center}
-    \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
-        @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
-        @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} }
-    \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
-    \hline
-    \centering version&\centering priority& 
-    \multicolumn{6}{@{}p{96mm}@{\vrule}}{\centering flow label} \\
-    \hline
-    \multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering payload length} & 
-    \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering next header} & 
-    \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering hop limit}\\
-    \hline
-    \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
-    \multicolumn{8}{@{\vrule}c@{\vrule}}{
-      source} \\
-    \multicolumn{8}{@{\vrule}c@{\vrule}}{
-      IP address} \\
-    \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
-    \hline
-    \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
-    \multicolumn{8}{@{\vrule}c@{\vrule}}{
-      destination} \\
-    \multicolumn{8}{@{\vrule}c@{\vrule}}{
-     IP address} \\
-    \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
-    \hline
-    \end{tabular}
-    \caption{L'intestazione o \textit{header} di IPv6}
-    \label{tab:IP_ipv6head}
-  \end{center}
-\end{table}
+% \begin{table}[htb]
+%   \footnotesize
+%   \begin{center}
+%     \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
+%         @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
+%         @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} }
+%     \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
+%     \hline
+%     \centering version&\centering priority& 
+%     \multicolumn{6}{@{}p{96mm}@{\vrule}}{\centering flow label} \\
+%     \hline
+%     \multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering payload length} & 
+%     \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering next header} & 
+%     \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering hop limit}\\
+%     \hline
+%     \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
+%     \multicolumn{8}{@{\vrule}c@{\vrule}}{
+%       source} \\
+%     \multicolumn{8}{@{\vrule}c@{\vrule}}{
+%       IP address} \\
+%     \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
+%     \hline
+%     \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
+%     \multicolumn{8}{@{\vrule}c@{\vrule}}{
+%       destination} \\
+%     \multicolumn{8}{@{\vrule}c@{\vrule}}{
+%      IP address} \\
+%     \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
+%     \hline
+%     \end{tabular}
+%     \caption{L'intestazione o \textit{header} di IPv6}
+%     \label{tab:IP_ipv6head}
+%   \end{center}
+% \end{table}
+
+\begin{figure}[htb]
+  \centering
+  \includegraphics[width=10cm]{img/ipv6_head}
+  \caption{L'intestazione o \textit{header} di IPv6.}
+  \label{fig:IP_ipv6head}
+\end{figure}
+
 
 Come si può notare l'intestazione di IPv6 diventa di dimensione fissa, pari a
 40 byte, contro una dimensione (minima, in assenza di opzioni) di 20 byte per
@@ -323,7 +331,7 @@ numero dei campi da 12 a 8.
 Abbiamo già anticipato in \secref{sec:IP_ipv6over} uno dei criteri principali
 nella progettazione di IPv6 è stato quello di ridurre al minimo il tempo di
 processamento dei pacchetti da parte dei router, un confronto con
-l'intestazione di IPv4 (vedi \secref{tab:IP_ipv4head}) mostra le seguenti
+l'intestazione di IPv4 (vedi \figref{fig:IP_ipv4head}) mostra le seguenti
 differenze:
 
 \begin{itemize}
@@ -355,47 +363,18 @@ differenze:
 \item è stato introdotto un nuovo campo \textit{flow label}, che viene usato,
   insieme al campo \textit{priority} (che recupera i bit di precedenza del
   campo \textit{type of service}) per implementare la gestione di una
-  ``qualità di servizio'' (vedi Sez.~\ref{sec:IP_ipv6_qos}) che permette di
+  ``qualità di servizio'' (vedi \secref{sec:IP_ipv6_qos}) che permette di
   identificare i pacchetti appartenenti a un ``flusso'' di dati per i quali si
   può provvedere un trattamento speciale.
 \end{itemize}
 
-\begin{table}[htb]
-  \footnotesize
+
+\begin{figure}[htb]
   \centering
-  \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
-        @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
-        @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} }
-    \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
-    \hline
-    \centering version&
-    \centering head length&
-    \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering type of service} &  
-    \multicolumn{4}{@{}p{64mm}@{\vrule}}{\centering total length} \\
-    \hline
-    \multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering identification} &
-    \multicolumn{4}{@{}p{64mm}@{\vrule}}{\parbox{11mm}{\centering flag} \vrule
-        \parbox{52mm}{\centering fragment offset}}\\
-    \hline
-    \multicolumn{2}{@{\vrule}p{32mm}@{\vrule}}{\centering TTL}& 
-    \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering protocol}&    
-    \multicolumn{4}{@{}p{64mm}@{\vrule}}{\centering header checksum} \\
-    \hline
-    \multicolumn{8}{@{\vrule}c@{\vrule}}{
-      source IP address} \\
-    \hline
-    \multicolumn{8}{@{\vrule}c@{\vrule}}{
-      destination IP address} \\
-    \hline
-    \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\    
-    \multicolumn{8}{@{}p{128mm}@{}}{
-      \centering options (if any)} \\
-    \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\    
-    \hline
-  \end{tabular}
-  \caption{L'intestazione o \textit{header} di IPv4}
-\label{tab:IP_ipv4head}
-\end{table}
+  \includegraphics[width=10cm]{img/ipv4_head}
+  \caption{L'intestazione o \textit{header} di IPv4.}
+  \label{fig:IP_ipv4head}
+\end{figure}
 
 \begin{table}[htb]
   \footnotesize
index db5ca4a..2fd6792 100644 (file)
--- a/pref.tex
+++ b/pref.tex
@@ -51,12 +51,13 @@ sistema della stessa qualit
 progetto molto ambizioso ...).
 
 
-Infatti benché le man pages e il manuale delle librerie del C GNU siano una
-fonte inesauribile di informazioni (da cui si è costantemente attinto nella
-stesura di tutto il testo) la loro struttura li rende totalmente inadatti ad
-una trattazione che vada oltre la descrizione delle caratteristiche
-particolari dello specifico argomento in esame (ed in particolare lo
-\textit{GNU C Library Reference Manual} non brilla per chiarezza espositiva).
+Infatti benché le pagine di manuale del sistema (quelle che si accedono con il
+comando \cmd{man}) e il manuale delle librerie del C GNU siano una fonte
+inesauribile di informazioni (da cui si è costantemente attinto nella stesura
+di tutto il testo) la loro struttura li rende totalmente inadatti ad una
+trattazione che vada oltre la descrizione delle caratteristiche particolari
+dello specifico argomento in esame (ed in particolare lo \textit{GNU C Library
+  Reference Manual} non brilla per chiarezza espositiva).
 
 Per questo motivo si è cercato di fare tesoro di quanto appreso dai testi di
 R. Stevens (in particolare \cite{APUE} e \cite{UNP1}) per rendere la
index 00e75a9..9f61d88 100644 (file)
@@ -603,7 +603,7 @@ suo utilizzo quindi limita la portabilit
 non può essere usata nella lista degli argomenti di una funzione, perché lo
 spazio verrebbe allocato nel mezzo degli stessi.
 
-% Questo è riportato solo dal manuale delle glibc, nelle man page non c'è 
+% Questo è riportato solo dal manuale delle glibc, nelle pagine di manuale non c'è 
 % traccia di tutto ciò
 %
 %Inoltre se si
index 0026cda..c737f57 100644 (file)
@@ -289,8 +289,8 @@ Il numero totale di segnali presenti 
 che i numeri dei segnali sono allocati progressivamente, essa corrisponde
 anche al successivo del valore numerico assegnato all'ultimo segnale definito.
 In \tabref{tab:sig_signal_list} si è riportato l'elenco completo dei segnali
-definiti in Linux (estratto dalle man page), comparati con quelli definiti in
-vari standard.
+definiti in Linux (estratto dalle pagine di manuale), comparati con quelli
+definiti in vari standard.
 
 \begin{table}[htb]
   \footnotesize
@@ -1298,8 +1298,8 @@ La granularit
 questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione
 \func{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due
 standard hanno delle definizioni diverse, ma le \acr{glibc}
-seguono\footnote{secondo la man page almeno dalla versione 2.2.2.} seguono
-quella di SUSv2 che prevede il seguente prototipo:
+seguono\footnote{secondo la pagina di manuale almeno dalla versione 2.2.2.}
+seguono quella di SUSv2 che prevede il seguente prototipo:
 \begin{prototype}{unistd.h}{int usleep(unsigned long usec)}
   
   Pone il processo in stato di sleep per \param{usec} microsecondi.
@@ -1915,8 +1915,8 @@ istruzione illecita o di violazione di memoria) mentre alcuni segnali di
 controllo (\macro{SIGCHLD}, \macro{SIGTRAP} e \macro{SIGPOLL}) forniscono
 altre informazioni speecifiche.  In tutti i casi il valore del campo è
 riportato attraverso delle costanti (le cui definizioni si trovano
-\file{bits/siginfo.h}) il cui elenco dettagliato è disponibile nella man page
-di \func{sigaction}.
+\file{bits/siginfo.h}) il cui elenco dettagliato è disponibile nella pagina di
+manuale di di \func{sigaction}.
 
 Il resto della struttura è definito come \ctyp{union} ed i valori
 eventualmente presenti dipendono dal segnale, così \macro{SIGCHLD} ed i
index 11e19a6..8511778 100644 (file)
@@ -26,10 +26,11 @@ Il \textit{socket}\footnote{una traduzione letterale potrebbe essere
   sempre la parola inglese.} è uno dei principali meccanismi di comunicazione
 fra programmi utilizzato in ambito Unix. Il socket costituisce in sostanza un
 canale di comunicazione fra due processi su cui si possono leggere e scrivere
-dati analogo a quello di una pipe ma a differenza di questa e degli altri
-meccanismi esaminati nel capitolo \capref{cha:IPC} i socket non sono limitati
-alla comunicazione fra processi che girano sulla stessa macchina ma possono
-effettuare la comunicazione anche attraverso la rete.
+dati analogo a quello di una pipe (vedi \secref{sec:ipc_pipes}) ma a
+differenza di questa e degli altri meccanismi esaminati nel capitolo
+\capref{cha:IPC} i socket non sono limitati alla comunicazione fra processi
+che girano sulla stessa macchina ma possono effettuare la comunicazione anche
+attraverso la rete.
 
 Quella dei socket costituisce infatti la principale API (\textit{Application
   Program Interface}) usata nella programmazione di rete.  La loro origine
@@ -37,8 +38,8 @@ risale al 1983, quando furono introdotti nel BSD 4.2; l'interfaccia 
 sostanzialmente la stessa con piccole modifiche negli anni successivi. Benché
 siano state sviluppate interfacce alternative, originate dai sistemi SVr4,
 come la XTI (\textit{X/Open Transport Interface}) nessuna ha mai raggiunto la
-diffusione e la popolarità di quella dei socket (né tantomeno usabilità e
-flessibilità).
+diffusione e la popolarità di quella dei socket (né tantomeno la stessa
+usabilità e flessibilità).
 
 La flessibilità e la genericità dell'interfaccia inoltre ha consentito di
 utilizzare i socket con i più disparati meccanismi di comunicazione, e non
@@ -57,11 +58,11 @@ usato, le funzioni da usare restano le stesse.
 
 Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
 inutile, in quanto il comportamento di quest'ultima e le problematiche da
-affrontare cambiano radicalmente a seconda dello ``stile'' di comunicazione
-usato.  La scelta di questo stile va infatti ad incidere sulla semantica che
-verrà utilizzata a livello utente per gestire la comunicazione (su come
-inviare e ricevere i dati) e sul comportamento effettivo delle funzioni
-utilizzate.
+affrontare cambiano radicalmente a seconda dello \textsl{stile} di
+comunicazione usato.  La scelta di questo stile va infatti ad incidere sulla
+semantica che verrà utilizzata a livello utente per gestire la comunicazione
+(su come inviare e ricevere i dati) e sul comportamento effettivo delle
+funzioni utilizzate.
 
 La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
 comunicazione che si vuole effettuare. Ad esempio alcuni stili di
@@ -148,9 +149,10 @@ altro nome con cui si indicano i domini.
 
 A ciascun tipo di dominio corrisponde un analogo nome simbolico che inizia per
 \texttt{AF\_} da \textit{address family}, e che identifica il formato degli
-indirizzi usati in quel dominio; le man pages di Linux si riferiscono a questi
-anche come \textit{name space}, (nome che però il manuale della glibc riserva
-ai domini) e che identifica il formato degli indirizzi usati in quel dominio.
+indirizzi usati in quel dominio; le pagine di manuale di Linux si riferiscono
+a questi anche come \textit{name space}, (nome che però il manuale delle
+\acr{glibc} riserva ai domini) e che identifica il formato degli indirizzi
+usati in quel dominio.
 
 L'idea alla base della distinzione era che una famiglia di protocolli potesse
 supportare vari tipi di indirizzi, per cui il prefisso \texttt{PF\_} si
@@ -162,7 +164,7 @@ nomi sono equivalenti e corrispondono agli stessi valori.
 
 I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
 indirizzi sono definiti dall'header \textit{socket.h}. In Linux le famiglie di
-protocolli disponibili sono riportate in \ntab.
+protocolli disponibili sono riportate in \tabref{tab:net_pf_names}.
 
 \begin{table}[htb]
   \footnotesize
@@ -175,7 +177,7 @@ protocolli disponibili sono riportate in \ntab.
        \macro{PF\_UNIX},
        \macro{PF\_LOCAL}  & Local communication            & unix(7)    \\
        \macro{PF\_INET}   & IPv4 Internet protocols        & ip(7)      \\
-       \macro{PF\_INET6}  & IPv6 Internet protocols        &            \\
+       \macro{PF\_INET6}  & IPv6 Internet protocols        & ipv6(7)    \\
        \macro{PF\_IPX}    & IPX - Novell protocols         &            \\
        \macro{PF\_NETLINK}& Kernel user interface device   & netlink(7) \\
        \macro{PF\_X25}    & ITU-T X.25 / ISO-8208 protocol & x25(7)     \\
@@ -191,8 +193,9 @@ protocolli disponibili sono riportate in \ntab.
 
 Non tutte le famiglie di protocolli sono accessibili dall'utente generico, ad
 esempio in generale tutti i socket di tipo \macro{SOCK\_RAW} possono essere
-creati solo da processi che hanno i privilegi di root (cioè effective uid
-uguale a zero) o la capability \macro{CAP\_NET\_RAW}.
+creati solo da processi che hanno i privilegi di root (cioè con
+\textit{effective user id} uguale a zero) o con la capability
+\macro{CAP\_NET\_RAW}.
 
 
 \subsection{Il tipo, o stile}
@@ -202,8 +205,9 @@ La scelta di un dominio non comporta per
 comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
 utilizzare fra quelli disponibili nella famiglia scelta. Le API permettono di
 scegliere lo stile di comunicazione indicando il tipo di socket; Linux e le
-glibc mettono a disposizione i seguenti tipi di socket (che il manuale della
-glibc chiama \textit{styles}) definiti come \ctyp{int} in \file{socket.h}:
+\acr{glibc} mettono a disposizione i seguenti tipi di socket (che il manuale
+della \acr{glibc} chiama \textit{styles}) definiti come \ctyp{int} in
+\file{socket.h}:
 
 \begin{list}{}{}
 \item \macro{SOCK\_STREAM} Provvede un canale di trasmissione dati
@@ -225,10 +229,10 @@ glibc chiama \textit{styles}) definiti come \ctyp{int} in \file{socket.h}:
 \item \macro{SOCK\_PACKET} Obsoleto, non deve essere usato.
 \end{list}
 
-Si tenga presente che non tutte le combinazioni di famiglia di protocolli e
-tipo di socket sono valide, in quanto non è detto che nella famiglia esista un
-protocollo per tutti gli stili di comunicazione indicati qui sopra. Una
-tabella che mostra le combinazioni valide è la seguente:
+Si tenga presente che non tutte le combinazioni fra una famiglia di protocolli
+e un tipo di socket sono valide, in quanto non è detto che in una famiglia
+esista un protocollo per ciascuno dei diversi stili di comunicazione appena
+elencati.
 
 \begin{table}[htb]
   \footnotesize
@@ -266,9 +270,11 @@ tabella che mostra le combinazioni valide 
   \label{tab:sock_sock_valid_combinations}
 \end{table}
 
-Dove per ogni combinazione valida si è indicato il tipo di protocollo, o la
-parola \textsl{si} qualora non il protocollo non abbia un nome definito,
-mentre si sono lasciate vuote le caselle per le combinazioni non supportate.
+In \secref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni
+valide possibili per le varie famiglie di protocolli. Per ogni combinazione
+valida si è indicato il tipo di protocollo, o la parola \textsl{si} qualora
+non il protocollo non abbia un nome definito, mentre si sono lasciate vuote le
+caselle per le combinazioni non supportate.
 
 
 
@@ -300,10 +306,10 @@ attraverso puntatori (cio
 maneggiare puntatori a strutture relative a tutti gli indirizzi possibili
 nelle varie famiglie di protocolli; questo pone il problema di come passare
 questi puntatori, il C ANSI risolve questo problema coi i puntatori generici
-(i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla
-definizione dello standard ANSI, e per questo nel 1982 fu scelto di definire
-una struttura generica \type{sockaddr} per gli indirizzi dei socket mostrata
-in \nfig:
+(i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla definizione
+dello standard ANSI, e per questo nel 1982 fu scelto di definire una struttura
+generica per gli indirizzi dei socket, \type{sockaddr}, che si è riportata in
+\figref{fig:sock_sa_gen_struct}.
 
 \begin{figure}[!htb]
   \footnotesize
@@ -323,9 +329,9 @@ invocano dette funzioni passando l'indirizzo di un protocollo specifico
 occorrerà eseguire un casting del relativo puntatore.
 
 I tipi di dati che compongono la struttura sono stabiliti dallo standard
-POSIX.1g, riassunti in \ntab\ con i rispettivi file di include in cui sono
-definiti; la struttura è invece definita nell'include file
-\file{sys/socket.h}
+POSIX.1g, riassunti in \tabref{tab:sock_data_types} con i rispettivi file di
+include in cui sono definiti; la struttura è invece definita nell'include file
+\file{sys/socket.h}.
 
 \begin{table}[!htb]
   \centering
@@ -354,7 +360,7 @@ definiti; la struttura 
     \hline
   \end{tabular}
   \caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto 
-    stabilito dallo standard POSIX.1g}
+    stabilito dallo standard POSIX.1g.}
   \label{tab:sock_data_types}
 \end{table}
 
@@ -379,8 +385,8 @@ l'uso di questa struttura.
 I socket di tipo \macro{PF\_INET} vengono usati per la comunicazione
 attraverso internet; la struttura per gli indirizzi per un socket internet
 (IPv4) è definita come \type{sockaddr\_in} nell'header file
-\file{netinet/in.h} e secondo le man page ha la forma mostrata in \nfig,
-conforme allo standard POSIX.1g.
+\file{netinet/in.h} e secondo le pagine di manuale ha la forma mostrata in
+\figref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
 
 \begin{figure}[!htb]
   \footnotesize
@@ -835,9 +841,10 @@ successivo; qui ci limiteremo a introdurre la nomenclatura senza fornire
 definizioni precise e dettagli di funzionamento che saranno trattati
 estensivamente più avanti.
 
-In \nfig\ è riportata la sezione principale del codice del nostro client
-elementare per il servizio \textit{daytime}, un servizio standard che
-restituisce l'ora locale della macchina a cui si effettua la richiesta.
+In \figref{fig:net_cli_code} è riportata la sezione principale del codice del
+nostro client elementare per il servizio \textit{daytime}, un servizio
+standard che restituisce l'ora locale della macchina a cui si effettua la
+richiesta.
 
 \begin{figure}[!htb]
   \footnotesize
@@ -957,7 +964,7 @@ necessario deve provvedere il programma stesso.
 
 Dopo aver illustrato il client daremo anche un esempio di un server
 elementare, in grado di rispondere al precedente client. Il listato è
-nuovamente mostrato in \nfig, il sorgente completo
+nuovamente mostrato in \figref{fig:net_serv_code}, il sorgente completo
 (\file{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file nella
 directory \file{sources}.
 
index c68686f..bc7cac5 100644 (file)
@@ -270,8 +270,8 @@ altre costanti. Siccome queste sono principalmente attinenti a limiti relativi
 alle applicazioni di sistema presenti (come quelli su alcuni parametri delle
 espressioni regolari o del comando \cmd{bc}), non li tratteremo
 esplicitamente, se ne trova una menzione completa nell'header file
-\file{bits/posix2\_lim.h}, e alcuni di loro sono descritti nella man page di
-\func{sysconf} e nel manuale delle \acr{glibc}.
+\file{bits/posix2\_lim.h}, e alcuni di loro sono descritti nella pagina di
+manuale di \func{sysconf} e nel manuale delle \acr{glibc}.
 
 
 \subsection{La funzione \func{sysconf}}
@@ -1122,7 +1122,8 @@ capacit
 completa. Per questo motivo l'uso di queste funzioni è deprecato in favore
 dell'uso di PAM, ci limiteremo pertanto ad elencarle in
 \tabref{tab:sys_passwd_func}, rimandando chi fosse interessato alle rispettive
-man page e al manuale delle \acr{glibc} per i dettagli del loro funzionamento.
+pagine di manuale e al manuale delle \acr{glibc} per i dettagli del loro
+funzionamento.
 
 
 
@@ -2388,7 +2389,7 @@ programma e che 
 \func{strerror}; per questo motivo non è rientrante e nel caso si usino i
 thread è provvista\footnote{questa funzione è la versione prevista dalle
   \acr{glibc}, ed effettivamente definita in \file{string.h}, ne esiste una
-  analoga nello standard SUSv3 (quella riportata dalla man page), che
+  analoga nello standard SUSv3 (quella riportata dalla pagina di manuale), che
   restituisce \code{int} al posto di \code{char *}, e che tronca la stringa
   restituita a \param{size}.} una versione apposita:
 \begin{prototype}{string.h}