Il sistema fa partire qualunque programma chiamando la funzione \func{main};
sta al programmatore chiamare così la funzione principale del programma da cui
si suppone iniziare l'esecuzione; in ogni caso senza questa funzione lo stesso
-\textit{linker} (ci chiama così il programma che effettua i collegamenti di
+\textit{linker} (si chiama così il programma che effettua i collegamenti di
cui sopra) darebbe luogo ad errori. Lo standard ISO C specifica che la
funzione \func{main} può non avere argomenti o prendere due argomenti che
rappresentano gli argomenti passati da linea di comando, in sostanza un
prototipo che va sempre bene è il seguente:
\includecodesnip{listati/main_def.c}
-In realtà nei sistemi Unix esiste un'altro modo per definire la funzione
+In realtà nei sistemi Unix esiste un altro modo per definire la funzione
\func{main}, che prevede la presenza di un terzo argomento, \code{char
*envp[]}, che fornisce (vedi sez.~\ref{sec:proc_environ})
l'\textsl{ambiente} del programma; questa forma però non è prevista dallo
tollerante nei confronti di piccoli errori come quello di chiamate doppie a
\func{free}. In particolare:
\begin{itemize}
-\item se la variabile è posta a zero gli errori vengono ignorati.
+\item se la variabile è posta a zero gli errori vengono ignorati;
\item se è posta ad 1 viene stampato un avviso sullo \textit{standard error}
- (vedi sez.~\ref{sec:file_std_stream}).
+ (vedi sez.~\ref{sec:file_std_stream});
\item se è posta a 2 viene chiamata \func{abort}, che in genere causa
l'immediata conclusione del programma.
\end{itemize}
In altri linguaggi come il java e recentemente il C\# il problema non si pone
nemmeno perché la gestione della memoria viene fatta totalmente in maniera
automatica, ovvero il programmatore non deve minimamente preoccuparsi di
-liberare la memoria allocata precedentemente quando non serve più, poiché il
-framework gestisce automaticamente la cosiddetta \textit{garbage collection}.
-In tal caso, attraverso meccanismi simili a quelli del \textit{reference
- counting}, quando una zona di memoria precedentemente allocata non è più
-riferita da nessuna parte del codice in esecuzione, può essere deallocata
-automaticamente in qualunque momento dall'infrastruttura.
+liberare la memoria allocata precedentemente quando non serve più, poiché
+l'infrastruttura del linguaggio gestisce automaticamente la cosiddetta
+\index{\textit{garbage~collection}}\textit{garbage collection}. In tal caso,
+attraverso meccanismi simili a quelli del \textit{reference counting}, quando
+una zona di memoria precedentemente allocata non è più riferita da nessuna
+parte del codice in esecuzione, può essere deallocata automaticamente in
+qualunque momento dall'infrastruttura.
Anche questo va a scapito delle prestazioni dell'applicazione in esecuzione
(inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
Per limitare l'impatto di questi problemi, e semplificare la ricerca di
eventuali errori, l'implementazione delle routine di allocazione delle
\acr{glibc} mette a disposizione una serie di funzionalità che permettono di
-tracciare le allocazioni e le disallocazione, e definisce anche una serie di
+tracciare le allocazioni e le disallocazioni, e definisce anche una serie di
possibili \textit{hook} (\textsl{ganci}) che permettono di sostituire alle
funzioni di libreria una propria versione (che può essere più o meno
specializzata per il debugging). Esistono varie librerie che forniscono dei
cui torneremo in sez.~\ref{sec:proc_auto_var}.
-Queste due funzioni vengono utilizzate soltanto quando è necessario effettuare
-direttamente la gestione della memoria associata allo spazio dati di un
-processo, ad esempio qualora si debba implementare la propria versione delle
-routine di allocazione della memoria viste in sez.~\ref{sec:proc_mem_malloc}.
-La prima funzione è \funcd{brk}, ed il suo prototipo è:
+Le due funzioni seguenti vengono utilizzate soltanto quando è necessario
+effettuare direttamente la gestione della memoria associata allo spazio dati
+di un processo, ad esempio qualora si debba implementare la propria versione
+delle routine di allocazione della memoria viste in
+sez.~\ref{sec:proc_mem_malloc}. La prima funzione è \funcd{brk}, ed il suo
+prototipo è:
\begin{prototype}{unistd.h}{int brk(void *end\_data\_segment)}
Sposta la fine del segmento dei dati.
Il \textit{memory lock} persiste fintanto che il processo che detiene la
memoria bloccata non la sblocca. Chiaramente la terminazione del processo
comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
-tutti i suoi \textit{memory lock}. Infine \textit{memory lock} non sono
+tutti i suoi \textit{memory lock}. Infine i \textit{memory lock} non sono
ereditati dai processi figli.\footnote{ma siccome Linux usa il \textit{copy on
write} (vedi sez.~\ref{sec:proc_fork}) gli indirizzi virtuali del figlio
sono mantenuti sullo stesso segmento di RAM del padre, quindi fintanto che
\subsection{Il formato degli argomenti}
\label{sec:proc_par_format}
-In genere passaggio degli argomenti al programma viene effettuato dalla shell,
-che si incarica di leggere la linea di comando e di effettuarne la scansione
-(il cosiddetto \textit{parsing}) per individuare le parole che la compongono,
-ciascuna delle quali viene considerata un argomento. Di norma per individuare
-le parole viene usato come carattere di separazione lo spazio o il tabulatore,
-ma il comportamento è modificabile attraverso l'impostazione della variabile
-di ambiente \cmd{IFS}.
+In genere il passaggio degli argomenti al programma viene effettuato dalla
+shell, che si incarica di leggere la linea di comando e di effettuarne la
+scansione (il cosiddetto \textit{parsing}) per individuare le parole che la
+compongono, ciascuna delle quali viene considerata un argomento. Di norma per
+individuare le parole viene usato come carattere di separazione lo spazio o il
+tabulatore, ma il comportamento è modificabile attraverso l'impostazione della
+variabile di ambiente \cmd{IFS}.
\begin{figure}[htb]
\centering
funzione all'interno di un ciclo, fintanto che essa non ritorna il valore -1
che indica che non ci sono più opzioni. Nel caso si incontri un'opzione non
dichiarata in \param{optstring} viene ritornato il carattere \texttt{'?'}
-mentre se un opzione che lo richiede non è seguita da un parametro viene
+mentre se un'opzione che lo richiede non è seguita da un parametro viene
ritornato il carattere \texttt{':'}, infine se viene incontrato il valore
\texttt{'-{}-'} la scansione viene considerata conclusa, anche se vi sono altri
elementi di \param{argv} che cominciano con il carattere \texttt{'-'}.
\subsection{Opzioni in formato esteso}
\label{sec:proc_opt_extended}
-Un'estensione di questo schema è costituito dalle cosiddette
+Un'estensione di questo schema è costituita dalle cosiddette
\textit{long-options} espresse nella forma \cmd{-{}-option=parameter}, anche
la gestione di queste ultime è stata standardizzata attraverso l'uso di una
versione estesa di \func{getopt}.
Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
comuni), come riportato in tab.~\ref{tab:proc_env_var}. GNU/Linux le supporta
tutte e ne definisce anche altre: per una lista più completa si può
-controllare \cmd{man environ}.
+controllare \cmd{man 5 environ}.
\begin{table}[htb]
\centering
variabile esista già, sovrascrivendola se diverso da zero, lasciandola
immutata se uguale a zero.
-La seconda funzione prende come argomento una stringa analoga quella
+La seconda funzione prende come argomento una stringa analoga a quella
restituita da \func{getenv}, e sempre nella forma \code{NOME=valore}. Se la
variabile specificata non esiste la stringa sarà aggiunta all'ambiente, se
invece esiste il suo valore sarà impostato a quello specificato da
sua sintassi la possibilità di definire delle \textit{variadic
function}\index{variadic} che abbiano un numero variabile di argomenti,
attraverso l'uso nella dichiarazione della funzione dello speciale costrutto
-``\texttt{...}'', che viene chiamato \textit{ellipsis}.
+``\texttt{\textellipsis}'', che viene chiamato \textit{ellipsis}.
Lo standard però non provvede a livello di linguaggio alcun meccanismo con cui
dette funzioni possono accedere ai loro argomenti. L'accesso viene pertanto
\item Dichiarare la conclusione dell'estrazione degli argomenti invocando la
macro \macro{va\_end}.
\end{enumerate}
-in generale è perfettamente legittimo richiedere meno argomenti di quelli che
+In generale è perfettamente legittimo richiedere meno argomenti di quelli che
potrebbero essere stati effettivamente forniti, e nella esecuzione delle
\macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
saranno ignorati; se invece si richiedono più argomenti di quelli forniti si
espressione di controllo di un comando condizionale, di selezione o di
iterazione;
\item come operando per l'operatore di negazione (\code{!}) in una espressione
- di controllo di un comando condizionale, di selezione o di iterazione.
+ di controllo di un comando condizionale, di selezione o di iterazione;
\item come espressione a sé stante.
\end{itemize}
In generale, dato che l'unica differenza fra la chiamata diretta e quella
-ottenuta da un \func{longjmp}, è il valore di ritorno di \func{setjmp}, essa è
-usualmente chiamata all'interno di un comando \code{if}.
+ottenuta da un \func{longjmp} è costituita dal valore di ritorno di
+\func{setjmp}, essa è usualmente chiamata all'interno di un comando \code{if}.
Uno dei punti critici dei salti non-locali è quello del valore delle
variabili, ed in particolare quello delle variabili automatiche della funzione