Correzioni varie di poco conto

diff --git a/elemtcp.tex b/elemtcp.tex
index 1678559a0c6ab31a1347fba1550b2a088d767f60..964dd4f16f5cc1c0539b9338093392ae75c5905a 100644 (file)
--- a/elemtcp.tex
+++ b/elemtcp.tex
@@ -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
 \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
 \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.
 
 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.

 
 
 
 
 
 

diff --git a/errors.tex b/errors.tex
index 547bb1caffd1f28143dbbe7ef05be2c31cceb50b..a75e0e1d300e6656ee0cfb52e7c8945f1c55f812 100644 (file)
--- a/errors.tex
+++ b/errors.tex
@@ -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 è
 \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
 \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

diff --git a/filedir.tex b/filedir.tex
index d1d8606e0b6daa1513fd28cda53ddafa996b6c99..b734c44eec99cae678ec68e85e40bae7660794d8 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -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
 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}
 \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
 
 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
 
 \begin{figure}[!htb]
   \footnotesize

diff --git a/filestd.tex b/filestd.tex
index 921f082eadda4dcecd37572c7a20baf2b8cd2355..a3e719f691f9224f56cbf243b1d69dda3d1d2c07 100644 (file)
--- a/filestd.tex
+++ b/filestd.tex
@@ -1056,8 +1056,8 @@ questo ordine:
 \end{itemize*}
 
 
 \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
 
 \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
 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
 
 Le funzioni eseguono la lettura dall'input, scartano i separatori (e gli
 eventuali caratteri diversi indicati dalla stringa di formato) effettuando le

diff --git a/fileunix.tex b/fileunix.tex
index d43019977c905f3e4a6816a6e96c79e5df91f245..c83cc737d81eff06f46650d022bd7d292d6af99b 100644 (file)
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -292,10 +292,10 @@ sempre il file descriptor con il valore pi
   \label{tab:file_open_flags}
 \end{table}
 
   \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
   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
   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
 \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

diff --git a/gapil.tex b/gapil.tex
index 639201220867098885e57f963e48ed41c91faebe..be7b703c5150a9fadc2320f275ccb47f18c0f568 100644 (file)
--- a/gapil.tex
+++ b/gapil.tex
@@ -21,8 +21,8 @@
 \usepackage{listings}
 \lstloadlanguages{C++}
 \usepackage{color} 
 \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} 
 %
 %\usepackage{footnote} 
 %\usepackage{mdwtab} 
 %


@@ -73,7 +73,7 @@
 \tableofcontents
 \clearemptydoublepage
 
 \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}
 \include{macro}
 \setcounter{secnumdepth}{-2}
 \include{pref}

diff --git a/img/ipv6_head.dia b/img/ipv6_head.dia
index 47bc364bb5ce6f425669c29a0eb8375f1c9d8dc9..2d2e75f9ab371dd0c484262554340d7c1dfbda91 100644 (file)
Binary files a/img/ipv6_head.dia and b/img/ipv6_head.dia differ

diff --git a/ipprot.tex b/ipprot.tex
index b1362a364f085a30360b0d2c292669f1fb9edcf9..6faf9eb2ac67a3f78f375daa554fec3c9f2c8317 100644 (file)
--- a/ipprot.tex
+++ b/ipprot.tex
@@ -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
 
 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})
 
 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
 
 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
 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}
 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
 \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}
 
   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
   \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
 
 \begin{table}[htb]
   \footnotesize

diff --git a/pref.tex b/pref.tex
index db5ca4a89a025d497d9efe07d8fd9b6b30b478bf..2fd679208be9093d5f011230222dfab3163cb33b 100644 (file)
--- a/pref.tex
+++ b/pref.tex
@@ -51,12 +51,13 @@ sistema della stessa qualit
 progetto molto ambizioso ...).
 
 
 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
 
 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

diff --git a/process.tex b/process.tex
index 00e75a933cbded5c6115146782db93a9c75c969c..9f61d88cc9262ae9705916a33256f9895d839219 100644 (file)
--- a/process.tex
+++ b/process.tex
@@ -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.
 
 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
 % traccia di tutto ciò
 %
 %Inoltre se si

diff --git a/signal.tex b/signal.tex
index 0026cda568e002f288163801d014a5b3adae889f..c737f5715b53256b1b0ed54b239094c9e7ea48ea 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -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
 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
 
 \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}
 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.
 \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
 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
 
 Il resto della struttura è definito come \ctyp{union} ed i valori
 eventualmente presenti dipendono dal segnale, così \macro{SIGCHLD} ed i

diff --git a/socket.tex b/socket.tex
index 11e19a69350505a74075a3e17790b834593d300e..8511778d1ea9911f85cec266988358165177e01d 100644 (file)
--- a/socket.tex
+++ b/socket.tex
@@ -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
   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
 
 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
 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
 
 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
 
 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
 
 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
 
 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
 
 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
 
 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
 
 \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\_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)     \\
        \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
 
 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}
 
 
 \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
 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
 
 \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}
 
 \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
 
 \begin{table}[htb]
   \footnotesize


@@ -266,9 +270,11 @@ tabella che mostra le combinazioni valide 
   \label{tab:sock_sock_valid_combinations}
 \end{table}
 
   \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
 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
 
 \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
 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
 
 \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 
     \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}
 
   \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
 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
 
 \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.
 
 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
 
 \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 è
 
 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}.
 
 (\file{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file nella
 directory \file{sources}.
 

diff --git a/system.tex b/system.tex
index c68686fcc5d9cfdd3d4e517f516bc04780ddd8fc..bc7cac588c8c102a0ca6d5cc6148a58a250c01cb 100644 (file)
--- a/system.tex
+++ b/system.tex
@@ -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
 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}}
 
 
 \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
 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
 \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}
   restituisce \code{int} al posto di \code{char *}, e che tronca la stringa
   restituita a \param{size}.} una versione apposita:
 \begin{prototype}{string.h}