From: Simone Piccardi Date: Tue, 11 Sep 2001 16:17:45 +0000 (+0000) Subject: Altre aggiunte sugli errori. X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=commitdiff_plain;h=fbbc5ab33a3e944b77298ce9019b88a4a01c6c9c Altre aggiunte sugli errori. --- diff --git a/intro.tex b/intro.tex index cdc19e1..043bf47 100644 --- 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