\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
+Il concetto base di un sistema unix-like è quello di un nucleo del sistema (il
cosiddetto \textit{kernel}) a cui si demanda la gestione delle risorse
essenziali (la CPU, la memoria, le periferiche) mentre tutto il resto, quindi
anche la parte che prevede l'interazione con l'utente, deve venire realizzato
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.
+determinare quando o se una chiamata a funzione è fallita. La procedura da
+seguire è sempre quella di controllare \var{errno} immediatamente dopo aver
+verificato il fallimento della funzione attraverso il suo codice di ritorno.
\subsection{Le funzioni \func{strerror} e \func{perror}}
\end{prototype}
In generale \func{strerror} viene usata passando \var{errno} come parametro;
-nel caso si specifichi un codice sbagliato verrà restituita un messaggio di
-errore sconosciuto.
-
-Il problema con \func{strerror} è che la funzione utilizza una stringa statica
-che non deve essere modificata dal programma e che è utilizzabile solo fino ad
-una chiamata successiva a \func{strerror}; nel caso si usino i thread è
+nel caso si specifichi un codice sbagliato verrà restituito un messaggio di
+errore sconosciuto. La funzione utilizza una stringa statica che non deve
+essere modificata dal programma e che è utilizzabile solo fino ad una chiamata
+successiva a \func{strerror}; nel caso si usino i thread è
provvista\footnote{questa funzione è una estensione GNU, non fa parte dello
standard POSIX} una versione apposita:
\begin{prototype}{string.h}
-{char * strerror_r(int errnum, char * buff, size\_t size)}
+{char * strerror\_r(int errnum, char * buff, size\_t size)}
La funzione è analoga a \func{strerror} ma ritorna il messaggio in un buffer
specificato da \var{buff} di lunghezza massima (compreso il terminatore)
\var{size}.
\end{prototype}
che utilizza un buffer che il singolo thread deve allocare, per evitare i
problemi connessi alla condivisione del buffer statico. Infine, per completare
-la caratterizzazione dell'errore, si può usare anche la variabile globale
-\var{program_invocation_short_name} che riporta il nome del programma
+la caratterizzazione dell'errore, si può usare anche la variabile
+globale\footnote{anche questa è una estensione GNU}
+\var{program\_invocation\_short\_name} che riporta il nome del programma
attualmente in esecuzione.
Una seconda funzione usata per riportare i codici di errore in maniera
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.
+\var{errno}; la seconda esprime il valore più alto per un codice di errore,
+l'utilizzo di questa stringa è sostanzialmente equivalente a quello di
+\func{strerror}.
+
-Il codice del programma \cmd{errcode} è riportato in \nfig, le sezioni che
-illustrano l'utilizzo delle due funzioni suddette s
+
+In \nfig\ si sono riportate le sezioni attinenti del codice del programma
+\cmd{errcode}, che può essere usato per stampare i messaggi di errore e le
+costanti usate per identificare i singoli errori; il sorgente completo del
+programma è allegato nel file \file{ErrCode.c} e contiene pure la gestione
+delle opzioni e tutte le definizioni necessarie ad associare il valore
+numerico alla costante simbolica. In particolare si è riportata
\begin{figure}[!htb]
\footnotesize
\end{lstlisting}
\caption{Codice per la stampa del messaggio di errore standard.}
- \label{fig:proc_fork_code}
+ \label{fig:intro_err_mess}
\end{figure}
+
projects / gapil.git / blobdiff