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
+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
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 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 è \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 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