Altre aggiunte sugli errori.

diff --git a/intro.tex b/intro.tex
index cdc19e16842236569f6023dd7d61281dcc903a98..043bf47cc7938aefce50c242ca50782e319f90c6 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -9,14 +9,14 @@ per quello che riguarda la programmazione.
 Dopo un introduzione sulle caratteristiche principali di un sistema di tipo
 unix passeremo ad illustrare alcuni dei concetti basi dell'architettura di
 Linux (che sono comunque comuni a tutti i sistemi \textit{unix-like}) ed
-introdurremo alcunoi degli standard princincipali a cui si fa riferimento.
+introdurremo alcuni degli standard princincipali a cui si fa riferimento.
 
 
 \section{Una panoramica sulla struttura}
 \label{sec:intro_unix_struct}
 
 In questa prima sezione faremo una panoramica sulla struttura di un sistema
-\textit{unix-like} come Linux.  Chi avesse già una conoscenza di questa
+\textit{unix-like} come GNU/Linux.  Chi avesse già una conoscenza di questa
 materia può tranquillamente saltare questa sezione.
 
 Il concetto base di un sistema unix-like é quello di un nucleo del sistema (il
@@ -347,13 +347,15 @@ codice relativo ad un valore numerico con l'opzione \cmd{-l}.
 
 Il valore di \var{errno} viene sempre settato a zero all'avvio di un
 programma, gran parte delle funzioni di libreria settano \var{errno} ad un
-valore diverso da zero in caso di errore. Si tenga presente che le funzioni
-non cambiano il valore di \var{errno} quando hanno successo, pertanto un
-valore non nullo non è sintomo di errore (potrebbe essere il risultato di un
-errore precedente) e non si può usare \var{errno} per determinare
-\textsl{quando} una chiamata a funzione è fallita.  Pertanto la procedura da
-seguire è quella di controllare \var{errno} immediatamente dopo il fallimento
-della chiamata.
+valore diverso da zero in caso di errore. Il valore è invece indefinito in
+caso di successo, perché anche se una funzione ha successo, può chiamarne
+altre al suo interno che falliscono, modificando così \var{errno}.
+
+Pertanto un valore non nullo di \var{errno} non è sintomo di errore (potrebbe
+essere il risultato di un errore precedente) e non lo si può usare per
+determinare \textsl{quando} una chiamata a funzione è fallita.  La procedura
+da seguire è sempre quella di controllare \var{errno} immediatamente dopo aver
+verificato il fallimento della funzione dal suo codice di ritorno.
 
 
 \subsection{Le funzioni \func{strerror} e \func{perror}}
@@ -390,15 +392,27 @@ la caratterizzazione dell'errore, si pu
 \var{program_invocation_short_name} che riporta il nome del programma
 attualmente in esecuzione.
 
-
-Una seconda funzione usata per riportare i codici di errore è \func{perror} il
-cui prototipo è:
+Una seconda funzione usata per riportare i codici di errore in maniera
+automatizzata sullo standard error (vedi \secref{sec:file_stdfiles}) è
+\func{perror}, il cui prototipo è:
 \begin{prototype}{stdio.h}{void perror (const char *message)} 
   La funzione stampa il messaggio di errore relativo al valore corrente di
   \var{errno} sullo standard error; preceduto dalla stringa \var{message}.
 \end{prototype}
-i messaggi di errore sono gli stessi di \func{strerror}, riportati in
-\capref{cha:errors},
+i messaggi di errore stampati sono gli stessi di \func{strerror}, (riportati
+in \capref{cha:errors}), e, usando il valore corrente di \var{errno}, si
+riferiscono all'ultimo errore avvenuto. La stringa specificata con
+\var{message} viene stampato prime del messaggio d'errore, seguita dai due
+punti e da uno spazio, il messaggio è terminato con un a capo.
+
+Il messaggio può essere riportato anche usando altre variabili globali
+dichiarate in \file{errno.h}:
+\begin{verbatim}
+   const char *sys_errlist[];
+   int sys_nerr;
+\end{verbatim}
+la prima contiene i puntatori alle stringhe di errore indicizzati da
+\var{errno}; la seconda esprime il valore più alto della lista. 
 
 
 Il codice del programma \cmd{errcode} è riportato in \nfig, le sezioni che