X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=othersock.tex;h=de8c3d19cfe452736fb1e04fff7c22fbfb0d2293;hp=24db472c41c4d7f881700c5053c4a2bd18bec1b6;hb=13c9129bd29551048f932743285dd79b5a60c1f7;hpb=fae1b357c38b50ce788f3f06f7153b1ce4ee57df

diff --git a/othersock.tex b/othersock.tex
index 24db472..de8c3d1 100644
--- a/othersock.tex
+++ b/othersock.tex
@@ -1,6 +1,6 @@
 %% othersock.tex
 %%
-%% Copyright (C) 2004-2017 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2004-2018 Simone Piccardi.  Permission is granted to
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
@@ -128,13 +128,13 @@ dati attraverso qualunque tipo di socket. Esse hanno la caratteristica di
 prevedere tre argomenti aggiuntivi attraverso i quali è possibile specificare
 la destinazione dei dati trasmessi o ottenere l'origine dei dati ricevuti. La
 prima di queste funzioni è \funcd{sendto} ed il suo prototipo\footnote{il
-  prototipo illustrato è quello utilizzato dalle \acr{glibc}, che seguono le
+  prototipo illustrato è quello utilizzato dalla \acr{glibc}, che segue le
   \textit{Single Unix Specification}, l'argomento \param{flags} era di tipo
   \ctyp{int} nei vari BSD4.*, mentre nelle \acr{libc4} e \acr{libc5} veniva
   usato un \texttt{unsigned int}; l'argomento \param{len} era \ctyp{int} nei
-  vari BSD4.* e nelle \acr{libc4}, ma \type{size\_t} nelle \acr{libc5};
-  infine l'argomento \param{tolen} era \ctyp{int} nei vari BSD4.* nelle
-  \acr{libc4} e nelle \acr{libc5}.} è:
+  vari BSD4.* e nella \acr{libc4}, ma \type{size\_t} nella \acr{libc5}; infine
+  l'argomento \param{tolen} era \ctyp{int} nei vari BSD4.*, nella \acr{libc4} e
+  nella \acr{libc5}.} è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{sys/socket.h}
@@ -217,12 +217,12 @@ per il momento ci si può limitare ad usare sempre un valore nullo.
 
 La seconda funzione utilizzata nella comunicazione fra socket UDP è
 \funcd{recvfrom}, che serve a ricevere i dati inviati da un altro socket; il
-suo prototipo\footnote{il prototipo è quello delle \acr{glibc} che seguono le
-  \textit{Single Unix Specification}, i vari BSD4.*, le \acr{libc4} e le
+suo prototipo\footnote{il prototipo è quello della \acr{glibc} che segue le
+  \textit{Single Unix Specification}, i vari BSD4.*, le \acr{libc4} e la
   \acr{libc5} usano un \ctyp{int} come valore di ritorno; per gli argomenti
   \param{flags} e \param{len} vale quanto detto a proposito di \func{sendto};
-  infine l'argomento \param{fromlen} è \ctyp{int} per i vari BSD4.*, le
-  \acr{libc4} e le \acr{libc5}.} è:
+  infine l'argomento \param{fromlen} è \ctyp{int} per i vari BSD4.*, la
+  \acr{libc4} e la \acr{libc5}.} è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{sys/socket.h}
@@ -737,8 +737,8 @@ con UDP non esiste una connessione, e fintanto che non si invia un pacchetto
 non c'è traffico sulla rete. In questo caso l'errore sarà rilevato alla
 ricezione del pacchetto ICMP \textit{destination unreachable} emesso dalla
 macchina cui ci si è rivolti, e questa volta, essendo il socket UDP connesso,
-il kernel potrà riportare detto errore in user space in maniera non ambigua,
-ed esso apparirà alla successiva lettura sul socket.
+il kernel potrà riportare detto errore in \textit{user space} in maniera non
+ambigua, ed esso apparirà alla successiva lettura sul socket.
 
 Si tenga presente infine che l'uso dei socket connessi non risolve l'altro
 problema del client, e cioè il fatto che in caso di perdita di un pacchetto