+\itindbeg{link-loader}
+\itindbeg{shared~objects}
+Quando un programma viene messo in esecuzione, cosa che può essere fatta solo
+con una funzione della famiglia \func{exec} (vedi sez.~\ref{sec:proc_exec}),
+il kernel esegue un opportuno codice di avvio, il cosiddetto
+\textit{link-loader}, costituito dal programma \cmd{ld-linux.so}. Questo
+programma è una parte fondamentale del sistema il cui compito è quello della
+gestione delle cosiddette \textsl{librerie condivise}, quelle che nel mondo
+Windows sono chiamate DLL (\textit{Dinamic Link Library}), e che invece in un
+sistema unix-like vengono chiamate \textit{shared objects}.
+
+Infatti, a meno di non aver specificato il flag \texttt{-static} durante la
+compilazione, tutti i programmi in Linux sono compilati facendo riferimento a
+librerie condivise, in modo da evitare di duplicare lo stesso codice nei
+relativi eseguibili e consentire un uso più efficiente della memoria, dato che
+il codice di uno \textit{shared objects} viene caricato in memoria dal kernel
+una sola volta per tutti i programmi che lo usano.
+\itindend{shared~objects}
+
+Questo significa però che normalmente il codice di un programma è incompleto,
+contenendo solo i riferimenti alle funzioni di libreria che vuole utilizzare e
+non il relativo codice. Per questo motivo all'avvio del programma è necessario
+l'intervento del \textit{link-loader} il cui compito è caricare in memoria le
+librerie condivise eventualmente assenti, ed effettuare poi il collegamento
+dinamico del codice del programma alle funzioni di libreria da esso utilizzate
+prima di metterlo in esecuzione.
+
+Il funzionamento di \cmd{ld-linux.so} è controllato da alcune variabili di
+ambiente e dal contenuto del file \conffile{/etc/ld.so.conf} che consentono di
+elencare le directory un cui cercare le librerie e determinare quali verranno
+utilizzate. In particolare con la variabile di ambiente
+\envvar{LD\_LIBRARY\_PATH} si possono indicare ulteriori directory rispetto a
+quelle di sistema in cui inserire versioni personali delle librerie che hanno
+la precedenza su quelle di sistema, mentre con la variabile di ambiente
+\envvar{LD\_PRELOAD} si può passare direttamente una lista di file di librerie
+condivise da usare al posto di quelli di sistema. In questo modo è possibile
+effettuare lo sviluppo o il test di nuove librerie senza dover sostituire
+quelle di sistema. Ulteriori dettagli sono riportati nella pagina di manuale
+di \cmd{ld.so} e per un approfondimento dell'argomento si può consultare
+sez.~3.1.2 di \cite{AGL}.
+
+Una volta completate le operazioni di inizializzazione di \cmd{ld-linux.so}, il
+sistema fa partire qualunque programma chiamando la funzione \code{main}. Sta
+al programmatore chiamare così la funzione principale del programma da cui si
+suppone che inizi l'esecuzione. In ogni caso senza questa funzione lo stesso
+\textit{link-loader} darebbe luogo ad errori. Lo standard ISO C specifica che
+la funzione \code{main} può non avere argomenti o prendere due argomenti che
+rappresentano gli argomenti passati da linea di comando (su cui torneremo in
+sez.~\ref{sec:proc_par_format}), in sostanza un prototipo che va sempre bene è
+il seguente:
+\includecodesnip{listati/main_def.c}
+
+\itindend{link-loader}
+
+In realtà nei sistemi Unix esiste un altro modo per definire la funzione
+\code{main}, che prevede la presenza di un terzo argomento, \code{char
+ *envp[]}, che fornisce l'\textsl{ambiente} del programma; questa forma però
+non è prevista dallo standard POSIX.1 per cui se si vogliono scrivere
+programmi portabili è meglio evitarla. Per accedere all'ambiente, come vedremo
+in sez.~\ref{sec:proc_environ} si usa in genere una variabile globale che
+viene sempre definita automaticamente.
+
+Ogni programma viene fatto partire mettendo in esecuzione il codice contenuto
+nella funzione \code{main}, ogni altra funzione usata dal programma, che sia
+ottenuta da una libreria condivisa, o che sia direttamente definita nel
+codice, dovrà essere invocata a partire dal codice di \code{main}. Nel caso di
+funzioni definite nel programma occorre tenere conto che, nel momento stesso
+in cui si usano le librerie di sistema (vale a dire la \acr{glibc}) alcuni
+nomi sono riservati e non possono essere utilizzati.
+
+In particolare sono riservati a priori e non possono essere mai ridefiniti in
+nessun caso i nomi di tutte le funzioni, le variabili, le macro di
+preprocessore, ed i tipi di dati previsti dallo standard ISO C. Lo stesso
+varrà per tutti i nomi definiti negli \textit{header file} che si sono
+esplicitamente inclusi nel programma (vedi sez.~\ref{sec:proc_syscall}), ma
+anche se è possibile riutilizzare nomi definiti in altri \textit{header file}
+la pratica è da evitare nella maniera più assoluta per non generare ambiguità.
+
+Oltre ai nomi delle funzioni di libreria sono poi riservati in maniera
+generica tutti i nomi di variabili o funzioni globali che iniziano con il
+carattere di sottolineato (``\texttt{\_}''), e qualunque nome che inizi con il
+doppio sottolineato (``\texttt{\_\_}'') o con il sottolineato seguito da
+lettera maiuscola. Questi identificativi infatti sono utilizzati per i nomi
+usati internamente in forma privata dalle librerie, ed evitandone l'uso si
+elimina il rischio di conflitti.
+
+Infine esiste una serie di classi di nomi che sono riservati per un loro
+eventuale uso futuro da parte degli standard ISO C e POSIX.1, questi in teoria
+possono essere usati senza problemi oggi, ma potrebbero dare un conflitto con
+una revisione futura di questi standard, per cui è comunque opportuno
+evitarli, in particolare questi sono:
+\begin{itemize*}
+\item i nomi che iniziano per ``\texttt{E}'' costituiti da lettere maiuscole e
+ numeri, che potrebbero essere utilizzati per nuovi codici di errore (vedi
+ sez.~\ref{sec:sys_errors}),
+\item i nomi che iniziano con ``\texttt{is}'' o ``\texttt{to}'' e costituiti
+ da lettere minuscole che potrebbero essere utilizzati da nuove funzioni per
+ il controllo e la conversione del tipo di caratteri,
+\item i nomi che iniziano con ``\texttt{LC\_}'' e costituiti
+ da lettere maiuscole che possono essere usato per macro attinenti la
+ localizzazione,% mettere in seguito (vedi sez.~\ref{sec:proc_localization}),
+\item nomi che iniziano con ``\texttt{SIG}'' o ``\texttt{SIG\_}'' e costituiti
+ da lettere maiuscole che potrebbero essere usati per nuovi nomi di segnale
+ (vedi sez.~\ref{sec:sig_classification}),
+\item nomi che iniziano con ``\texttt{str}'', ``\texttt{mem}'', o
+ ``\texttt{wcs}'' e costituiti da lettere minuscole che possono essere
+ utilizzati per funzioni attinenti la manipolazione delle stringhe e delle
+ aree di memoria,
+\item nomi che terminano in ``\texttt{\_t}'' che potrebbero essere utilizzati
+ per la definizione di nuovi tipi di dati di sistema oltre quelli di
+ tab.~\ref{tab:intro_primitive_types}).
+\end{itemize*}
+
+
+\subsection{Chiamate a funzioni e \textit{system call}}
+\label{sec:proc_syscall}
+
+Come accennato in sez.~\ref{sec:intro_syscall} un programma può utilizzare le
+risorse che il sistema gli mette a disposizione attraverso l'uso delle
+opportune \textit{system call}. Abbiamo inoltre appena visto come all'avvio un
+programma venga messo in grado di chiamare le funzioni fornite da eventuali
+librerie condivise da esso utilizzate.
+
+Vedremo nel resto della guida quali sono le risorse del sistema accessibili
+attraverso le \textit{system call} e tratteremo buona parte delle funzioni
+messe a disposizione dalla libreria standard del C, in questa sezione però si
+forniranno alcune indicazioni generali sul come fare perché un programma possa
+utilizzare queste funzioni.
+
+\itindbeg{header~file}
+
+In sez.~\ref{sec:intro_standard} abbiamo accennato come le funzioni definite
+nei vari standard siano definite in una serie di \textit{header file} (in
+italiano \textsl{file di intestazione}). Vengono chiamati in questo modo quei
+file, forniti insieme al codice delle librerie, che contengono le
+dichiarazioni delle variabili, dei tipi di dati, delle macro di preprocessore
+e soprattutto delle funzioni che fanno parte di una libreria.
+
+Questi file sono necessari al compilatore del linguaggio C per ottenere i
+riferimenti ai nomi delle funzioni (e alle altre risorse) definite in una
+libreria, per questo quando si vogliono usare le funzioni di una libreria
+occorre includere nel proprio codice gli \textit{header file} che le
+definiscono con la direttiva \code{\#include}. Dato che le funzioni devono
+essere definite prima di poterle usare in genere gli \textit{header file}
+vengono inclusi all'inizio del programma. Se inoltre si vogliono utilizzare le
+macro di controllo delle funzionalità fornite dai vari standard illustrate in
+sez.~\ref{sec:intro_gcc_glibc_std} queste, come accennato, dovranno a loro
+volta essere definite prima delle varie inclusioni.
+
+Ogni libreria fornisce i propri file di intestazione per i quali si deve
+consultare la documentazione, ma in tab.~\ref{tab:intro_posix_header} si sono
+riportati i principali \textit{header file} definiti nella libreria standard
+del C (nel caso la \acr{glibc}) che contengono le varie funzioni previste
+negli standard POSIX ed ANSI C, e che prevedono la definizione sia delle
+funzioni di utilità generica che delle interfacce alle \textit{system call}. In
+seguito per ciascuna funzione o \textit{system call} che tratteremo
+indicheremo anche quali sono gli \textit{header file} contenenti le necessarie
+definizioni.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|c|c|l|}
+ \hline
+ \multirow{2}{*}{\textbf{Header}}&
+ \multicolumn{2}{|c|}{\textbf{Standard}}&
+ \multirow{2}{*}{\textbf{Contenuto}} \\
+ \cline{2-3}
+ & ANSI C& POSIX& \\
+ \hline
+ \hline
+ \headfiled{assert.h}&$\bullet$& -- & Verifica le asserzioni fatte in un
+ programma.\\
+ \headfiled{ctype.h} &$\bullet$& -- & Tipi standard.\\
+ \headfiled{dirent.h}& -- &$\bullet$& Manipolazione delle directory.\\
+ \headfiled{errno.h} & -- &$\bullet$& Errori di sistema.\\
+ \headfiled{fcntl.h} & -- &$\bullet$& Controllo sulle opzioni dei
+ file.\\
+ \headfiled{limits.h}& -- &$\bullet$& Limiti e parametri del sistema.\\
+ \headfiled{malloc.h}&$\bullet$& -- & Allocazione della memoria.\\
+ \headfiled{setjmp.h}&$\bullet$& -- & Salti non locali.\\
+ \headfiled{signal.h}& -- &$\bullet$& Gestione dei segnali.\\
+ \headfiled{stdarg.h}&$\bullet$& -- & Gestione di funzioni a argomenti
+ variabili.\\
+ \headfiled{stdio.h} &$\bullet$& -- & I/O bufferizzato in standard ANSI
+ C.\\
+ \headfiled{stdlib.h}&$\bullet$& -- & Definizioni della libreria
+ standard.\\
+ \headfiled{string.h}&$\bullet$& -- & Manipolazione delle stringhe.\\
+ \headfiled{time.h} & -- &$\bullet$& Gestione dei tempi.\\
+ \headfiled{times.h} &$\bullet$& -- & Gestione dei tempi.\\
+ \headfiled{unistd.h}& -- &$\bullet$& Unix standard library.\\
+ \headfiled{utmp.h} & -- &$\bullet$& Registro connessioni utenti.\\
+ \hline
+ \end{tabular}
+ \caption{Elenco dei principali \textit{header file} definiti dagli standard
+ POSIX e ANSI C.}
+ \label{tab:intro_posix_header}
+\end{table}
+
+Un esempio di inclusione di questi file, preso da uno dei programmi di
+esempio, è il seguente, e si noti come gli \textit{header file} possano essere
+referenziati con il nome fra parentesi angolari, nel qual caso si indica l'uso
+di quelli installati con il sistema,\footnote{in un sistema GNU/Linux che
+ segue le specifiche del \textit{Filesystem Hierarchy Standard} (per maggiori
+ informazioni si consulti sez.~1.2.3 di \cite{AGL}) si trovano sotto
+ \texttt{/usr/include}.} o fra virgolette, nel qual caso si fa riferimento
+ad una versione locale, da indicare con un \textit{pathname} relativo:
+\includecodesnip{listati/main_include.c}
+
+Si tenga presente che oltre ai nomi riservati a livello generale di cui si è
+parlato in sez.~\ref{sec:proc_main}, alcuni di questi \textit{header file}
+riservano degli ulteriori identificativi, il cui uso sarà da evitare, ad
+esempio si avrà che:
+\begin{itemize*}
+\item in \headfile{dirent.h} vengono riservati i nomi che iniziano con
+ ``\texttt{d\_}'' e costituiti da lettere minuscole,
+\item in \headfile{fcntl.h} vengono riservati i nomi che iniziano con
+ ``\texttt{l\_}'', ``\texttt{F\_}'',``\texttt{O\_}'' e ``\texttt{S\_}'',
+\item in \headfile{limits.h} vengono riservati i nomi che finiscono in
+ ``\texttt{\_MAX}'',
+\item in \headfile{signal.h} vengono riservati i nomi che iniziano con
+ ``\texttt{sa\_}'' e ``\texttt{SA\_}'',
+\item in \headfile{sys/stat.h} vengono riservati i nomi che iniziano con
+ ``\texttt{st\_}'' e ``\texttt{S\_}'',
+\item in \headfile{sys/times.h} vengono riservati i nomi che iniziano con
+ ``\texttt{tms\_}'',
+\item in \headfile{termios.h} vengono riservati i nomi che iniziano con
+ ``\texttt{c\_}'', ``\texttt{V}'', ``\texttt{I}'', ``\texttt{O}'' e
+ ``\texttt{TC}'' e con ``\texttt{B}'' seguito da un numero,
+\item in \headfile{grp.h} vengono riservati i nomi che iniziano con
+ ``\texttt{gr\_}'',
+\item in \headfile{pwd.h} vengono riservati i nomi che iniziano con
+ ``\texttt{pw\_}'',
+\end{itemize*}
+
+\itindend{header~file}
+
+Una volta inclusi gli \textit{header file} necessari un programma potrà
+richiamare le funzioni di libreria direttamente nel proprio codice ed accedere
+ai servizi del kernel; come accennato infatti normalmente ogni \textit{system
+ call} è associata ad una omonima funzione di libreria, che è quella che si
+usa normalmente per invocarla.
+
+Occorre però tenere presente che anche se dal punto di vista della scrittura
+del codice la chiamata di una \textit{system call} non è diversa da quella di
+una qualunque funzione ordinaria, la situazione è totalmente diversa
+nell'esecuzione del programma. Una funzione ordinaria infatti viene eseguita,
+esattamente come il codice che si è scritto nel corpo del programma, in
+\textit{user space}. Quando invece si esegue una \textit{system call}
+l'esecuzione ordinaria del programma viene interrotta con quello che viene
+usualmente chiamato un \itindex{context~switch} \textit{context
+ switch};\footnote{in realtà si parla più comunemente di \textit{context
+ switch} quando l'esecuzione di un processo viene interrotta dal kernel
+ (tramite lo \textit{scheduler}) per metterne in esecuzione un altro, ma il
+ concetto generale resta lo stesso: l'esecuzione del proprio codice in
+ \textit{user space} viene interrotta e lo stato del processo deve essere
+ salvato per poterne riprendere l'esecuzione in un secondo tempo.} il
+contesto di esecuzione del processo viene salvato in modo da poterne
+riprendere in seguito l'esecuzione ed i dati forniti (come argomenti della
+chiamata) vengono trasferiti al kernel che esegue il codice della
+\textit{system call} (che è codice del kernel) in \textit{kernel space}; al
+completamento della \textit{system call} i dati salvati nel \textit{context
+ switch} saranno usati per riprendere l'esecuzione ordinaria del programma.
+
+Dato che il passaggio dei dati ed il salvataggio del contesto di esecuzione
+sono operazioni critiche per le prestazioni del sistema, per rendere il più
+veloce possibile questa operazione sono state sviluppate una serie di
+ottimizzazioni che richiedono alcune preparazioni abbastanza complesse dei
+dati, che in genere dipendono dall'architettura del processore e sono scritte
+direttamente in \textit{assembler}.
+
+
+%
+% TODO:trattare qui, quando sarà il momento vsyscall e vDSO, vedi:
+% http://davisdoesdownunder.blogspot.com/2011/02/linux-syscall-vsyscall-and-vdso-oh-my.html
+% http://www.win.tue.nl/~aeb/linux/lk/lk-4.html
+%
+% Altro materiale al riguardo http://lwn.net/Articles/615809/
+% http://man7.org/linux/man-pages/man7/vdso.7.html
+
+Inoltre alcune \textit{system call} sono state modificate nel corso degli anni
+con lo sviluppo del kernel per aggiungere ad esempio funzionalità in forma di
+nuovi argomenti, o per consolidare diverse varianti in una interfaccia
+generica. Per questo motivo dovendo utilizzare una \textit{system call} è
+sempre preferibile usare l'interfaccia fornita dalla \textsl{glibc}, che si
+cura di mantenere una uniformità chiamando le versioni più aggiornate.
+
+Ci sono alcuni casi però in cui può essere necessario evitare questa
+associazione, e lavorare a basso livello con una specifica versione, oppure si
+può voler utilizzare una \textit{system call} che non è stata ancora associata
+ad una funzione di libreria. In tal caso, per evitare di dover effettuare
+esplicitamente le operazioni di preparazione citate, all'interno della
+\textsl{glibc} è fornita una specifica funzione,
+\funcd{syscall},\footnote{fino a prima del kernel 2.6.18 per l'esecuzione
+ diretta delle \textit{system call} erano disponibili anche una serie di
+ macro \texttt{\_syscall\textsl{N}} (con $N$ pari al numero di argomenti
+ della \textit{system call}); queste sono deprecate e pertanto non ne
+ parleremo ulteriormente.} che consente eseguire direttamente una
+\textit{system call}; il suo prototipo, accessibile se si è definita la macro
+\macro{\_GNU\_SOURCE}, è:
+
+\begin{funcproto}{
+ \fhead{unistd.h}
+ \fhead{sys/syscall.h}
+ \fdecl{long syscall(int number, ...)}
+ \fdesc{Esegue la \textit{system call} indicata da \param{number}.}
+}
+{La funzione ritorna un intero dipendente dalla \textit{system call} invocata,
+ in generale $0$ indica il successo ed un valore negativo un errore.}
+\end{funcproto}
+
+La funzione richiede come primo argomento il numero della \textit{system call}
+da invocare, seguita dagli argomenti da passare alla stessa, che ovviamente
+dipendono da quest'ultima, e restituisce il codice di ritorno della
+\textit{system call} invocata. In generale un valore nullo indica il successo
+ed un valore negativo è un codice di errore che poi viene memorizzato nella
+variabile \var{errno} (sulla gestione degli errori torneremo in dettaglio in
+sez.~\ref{sec:sys_errors}).
+
+Il valore di \param{number} dipende sia dalla versione di kernel che
+dall'architettura,\footnote{in genere le vecchie \textit{system call} non
+ vengono eliminate e se ne aggiungono di nuove con nuovi numeri.} ma
+ciascuna \textit{system call} viene in genere identificata da una costante
+nella forma \texttt{SYS\_*} dove al prefisso viene aggiunto il nome che spesso
+corrisponde anche alla omonima funzione di libreria. Queste costanti sono
+definite nel file \headfiled{sys/syscall.h}, ma si possono anche usare
+direttamente valori numerici.
+
+
+\subsection{La terminazione di un programma}
+\label{sec:proc_conclusion}
+
+Normalmente un programma conclude la sua esecuzione quando si fa ritornare la
+funzione \code{main}, si usa cioè l'istruzione \instruction{return} del
+linguaggio C all'interno della stessa, o se si richiede esplicitamente la
+chiusura invocando direttamente la funzione \func{exit}. Queste due modalità
+sono assolutamente equivalenti, dato che \func{exit} viene chiamata in maniera
+trasparente anche quando \code{main} ritorna, passandogli come argomento il
+valore indicato da \instruction{return}.
+
+La funzione \funcd{exit}, che è completamente generale, essendo definita dallo
+standard ANSI C, è quella che deve essere invocata per una terminazione
+``\textit{normale}'', il suo prototipo è:
+
+\begin{funcproto}{
+ \fhead{unistd.h}
+ \fdecl{void exit(int status)}
+ \fdesc{Causa la conclusione ordinaria del programma.}
+}
+{La funzione non ritorna, il processo viene terminato.}
+\end{funcproto}
+
+La funzione è pensata per eseguire una conclusione pulita di un programma che
+usi la libreria standard del C; essa esegue tutte le funzioni che sono state
+registrate con \func{atexit} e \func{on\_exit} (vedi
+sez.~\ref{sec:proc_atexit}), chiude tutti gli \textit{stream} (vedi
+sez.~\ref{sec:file_stream}) effettuando il salvataggio dei dati sospesi
+(chiamando \func{fclose}, vedi sez.~\ref{sec:file_fopen}), infine passa il
+controllo al kernel chiamando la \textit{system call} \func{\_exit} (che
+vedremo a breve) che completa la terminazione del processo.
+
+\itindbeg{exit~status}
+
+Il valore dell'argomento \param{status} o il valore di ritorno di \code{main}
+costituisce quello che viene chiamato lo \textsl{stato di uscita}
+(l'\textit{exit status}) del processo. In generale si usa questo valore per
+fornire al processo padre (come vedremo in sez.~\ref{sec:proc_wait}) delle
+informazioni generiche sulla riuscita o il fallimento del programma appena
+terminato.
+
+Anche se l'argomento \param{status} (ed il valore di ritorno di \code{main})
+sono numeri interi di tipo \ctyp{int}, si deve tener presente che il valore
+dello stato di uscita viene comunque troncato ad 8 bit, per cui deve essere
+sempre compreso fra 0 e 255. Si tenga presente che se si raggiunge la fine
+della funzione \code{main} senza ritornare esplicitamente si ha un valore di
+uscita indefinito, è pertanto consigliabile di concludere sempre in maniera
+esplicita detta funzione.
+
+Non esiste un significato intrinseco della stato di uscita, ma una convenzione
+in uso pressoché universale è quella di restituire 0 in caso di successo e 1
+in caso di fallimento. Una eccezione a questa convenzione è per i programmi
+che effettuano dei confronti (come \cmd{diff}), che usano 0 per indicare la
+corrispondenza, 1 per indicare la non corrispondenza e 2 per indicare
+l'incapacità di effettuare il confronto. Un'altra convenzione riserva i valori
+da 128 a 256 per usi speciali: ad esempio 128 viene usato per indicare
+l'incapacità di eseguire un altro programma in un sottoprocesso. Benché le
+convenzioni citate non siano seguite universalmente è una buona idea tenerle
+presenti ed adottarle a seconda dei casi.
+
+Si tenga presente inoltre che non è una buona idea usare eventuali codici di
+errore restituiti nella variabile \var{errno} (vedi sez.~\ref{sec:sys_errors})
+come \textit{exit status}. In generale infatti non ci si cura del valore dello
+stato di uscita di un processo se non per vedere se è diverso da zero, come
+indicazione di un qualche errore. Dato che viene troncato ad 8 bit utilizzare
+un intero di valore generico può comportare il rischio, qualora si vada ad
+usare un multiplo di 256, di avere uno stato di uscita uguale a zero, che
+verrebbe interpretato come un successo.
+
+Per questo motivo in \headfile{stdlib.h} sono definite, seguendo lo standard
+POSIX, le due costanti \constd{EXIT\_SUCCESS} e \constd{EXIT\_FAILURE}, da
+usare sempre per specificare lo stato di uscita di un processo. Su Linux, ed
+in generale in qualunque sistema POSIX, ad esse sono assegnati rispettivamente
+i valori 0 e 1.
+
+\itindend{exit~status}
+
+Una forma alternativa per effettuare una terminazione esplicita di un
+programma è quella di chiamare direttamente la \textit{system call}
+\funcd{\_exit},\footnote{la stessa è definita anche come \funcd{\_Exit} in
+ \headfile{stdlib.h}, inoltre a partire dalla \acr{glibc} 2.3 usando questa
+ funzione viene invocata \func{exit\_group} che termina tutti i
+ \textit{thread} del processo e non solo quello corrente (fintanto che non si
+ usano i \textit{thread}\unavref{, vedi sez.~\ref{cha:threads},} questo non
+ fa nessuna differenza).} che restituisce il controllo direttamente al
+kernel, concludendo immediatamente il processo, il suo prototipo è:
+
+\begin{funcproto}{ \fhead{unistd.h} \fdecl{void \_exit(int status)}
+ \fdesc{Causa la conclusione immediata del programma.} } {La funzione non
+ ritorna, il processo viene terminato.}
+\end{funcproto}
+
+La funzione termina immediatamente il processo e le eventuali funzioni
+registrate con \func{atexit} e \func{on\_exit} non vengono eseguite. La
+funzione chiude tutti i file descriptor appartenenti al processo, cosa che
+però non comporta il salvataggio dei dati eventualmente presenti nei buffer
+degli \textit{stream}, (torneremo sulle due interfacce dei file in
+sez.~\ref{sec:file_unix_interface} e
+sez.~\ref{sec:files_std_interface}). Infine fa sì che ogni figlio del processo
+sia adottato da \cmd{init} (vedi sez.~\ref{sec:proc_termination}), manda un
+segnale \signal{SIGCHLD} al processo padre (vedi
+sez.~\ref{sec:sig_job_control}) e salva lo stato di uscita specificato in
+\param{status} che può essere raccolto usando la funzione \func{wait} (vedi
+sez.~\ref{sec:proc_wait}).
+
+Si tenga presente infine che oltre alla conclusione ``\textsl{normale}''
+appena illustrata esiste anche la possibilità di una conclusione
+``\textsl{anomala}'' del programma a causa della ricezione di un segnale
+(tratteremo i segnali in cap.~\ref{cha:signals}) o della chiamata alla
+funzione \func{abort}; torneremo su questo in sez.~\ref{sec:proc_termination}.
+
+
+\subsection{Esecuzione di funzioni preliminari all'uscita}
+\label{sec:proc_atexit}
+
+Un'esigenza comune che si incontra è quella di dover effettuare una serie di
+operazioni di pulizia prima della conclusione di un programma, ad esempio
+salvare dei dati, ripristinare delle impostazioni, eliminare dei file
+temporanei, ecc. In genere queste operazioni vengono fatte in un'apposita
+sezione del programma, ma quando si realizza una libreria diventa antipatico
+dover richiedere una chiamata esplicita ad una funzione di pulizia al
+programmatore che la utilizza.
+
+È invece molto meno soggetto ad errori, e completamente trasparente
+all'utente, avere la possibilità di fare effettuare automaticamente la
+chiamata ad una funzione che effettui tali operazioni all'uscita dal
+programma. A questo scopo lo standard ANSI C prevede la possibilità di
+registrare un certo numero di funzioni che verranno eseguite all'uscita dal
+programma,\footnote{nel caso di \func{atexit} lo standard POSIX.1-2001
+ richiede che siano registrabili almeno \constd{ATEXIT\_MAX} funzioni (il
+ valore può essere ottenuto con \func{sysconf}, vedi
+ sez.~\ref{sec:sys_limits}).} sia per la chiamata ad \func{exit} che per il
+ritorno di \code{main}. La prima funzione che si può utilizzare a tal fine è
+\funcd{atexit}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{int atexit(void (*function)(void))}
+\fdesc{Registra la funzione \param{function} per la chiamata all'uscita
+ dal programma.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, \var{errno}
+ non viene modificata.}
+\end{funcproto}
+
+La funzione richiede come argomento \param{function} l'indirizzo di una
+opportuna funzione di pulizia da chiamare all'uscita del programma, che non
+deve prendere argomenti e non deve ritornare niente. In sostanza deve la
+funzione di pulizia dovrà essere definita come \code{void function(void)}.
+
+Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che la
+\acr{glibc} include per compatibilità con SunOS ma che non è detto sia
+definita su altri sistemi,\footnote{la funzione è disponibile dalla
+ \acr{glibc} 2.19 definendo la macro \macro{\_DEFAULT\_SOURCE}, mentre in
+ precedenza erano necessarie \macro{\_BSD\_SOURCE} o \macro{\_SVID\_SOURCE};
+ non essendo prevista dallo standard POSIX è in generale preferibile evitarne
+ l'uso.} il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{int on\_exit(void (*function)(int, void *), void *arg))}
+\fdesc{Registra la funzione \param{function} per la chiamata all'uscita dal
+ programma.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, \var{errno}
+ non viene modificata.}
+\end{funcproto}
+
+In questo caso la funzione da chiamare all'uscita prende i due argomenti
+specificati nel prototipo, un intero ed un puntatore; dovrà cioè essere
+definita come \code{void function(int status, void *argp)}. Il primo argomento
+sarà inizializzato allo stato di uscita con cui è stata chiamata \func{exit}
+ed il secondo al puntatore \param{arg} passato come secondo argomento di
+\func{on\_exit}. Così diventa possibile passare dei dati alla funzione di
+chiusura.
+
+Nella sequenza di chiusura tutte le funzioni registrate verranno chiamate in
+ordine inverso rispetto a quello di registrazione, ed una stessa funzione
+registrata più volte sarà chiamata più volte. Siccome entrambe le funzioni
+\func{atexit} e \func{on\_exit} fanno riferimento alla stessa lista, l'ordine
+di esecuzione sarà riferito alla registrazione in quanto tale,
+indipendentemente dalla funzione usata per farla.
+
+Una volta completata l'esecuzione di tutte le funzioni registrate verranno
+chiusi tutti gli \textit{stream} aperti ed infine verrà chiamata \func{\_exit}
+per la terminazione del programma. Questa è la sequenza ordinaria, eseguita a
+meno che una delle funzioni registrate non esegua al suo interno
+\func{\_exit}, nel qual caso la terminazione del programma sarà immediata ed
+anche le successive funzioni registrate non saranno invocate.
+
+Se invece all'interno di una delle funzioni registrate si chiama un'altra
+volta \func{exit} lo standard POSIX.1-2001 prescrive un comportamento
+indefinito, con la possibilità (che su Linux comunque non c'è) di una
+ripetizione infinita. Pertanto questa eventualità è da evitare nel modo più
+assoluto. Una altro comportamento indefinito si può avere se si termina
+l'esecuzione di una delle funzioni registrate con \func{longjmp} (vedi
+sez.~\ref{sec:proc_longjmp}).
+
+Si tenga presente infine che in caso di terminazione anomala di un processo
+(ad esempio a causa di un segnale) nessuna delle funzioni registrate verrà
+eseguita e che se invece si crea un nuovo processo con \func{fork} (vedi
+sez.~\ref{sec:proc_fork}) questo manterrà tutte le funzioni già registrate.
+
+
+\subsection{Un riepilogo}
+\label{sec:proc_term_conclusion}
+
+Data l'importanza dell'argomento è opportuno un piccolo riepilogo dei fatti
+essenziali relativi alla esecuzione di un programma. Il primo punto da
+sottolineare è che in un sistema unix-like l'unico modo in cui un programma
+può essere eseguito dal kernel è attraverso la chiamata alla \textit{system
+ call} \func{execve}, sia direttamente che attraverso una delle funzioni
+della famiglia \func{exec} che ne semplificano l'uso (vedi
+sez.~\ref{sec:proc_exec}).
+
+Allo stesso modo l'unico modo in cui un programma può concludere
+volontariamente la propria esecuzione è attraverso una chiamata alla
+\textit{system call} \func{\_exit}, sia che questa venga fatta esplicitamente,
+o in maniera indiretta attraverso l'uso di \func{exit} o il ritorno di
+\code{main}.
+
+Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
+normalmente un programma è riportato in fig.~\ref{fig:proc_prog_start_stop}.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=9cm]{img/proc_beginend}
+ % \begin{tikzpicture}[>=stealth]
+ % \filldraw[fill=black!35] (-0.3,0) rectangle (12,1);
+ % \draw(5.5,0.5) node {\large{\textsf{kernel}}};
+
+ % \filldraw[fill=black!15] (1.5,2) rectangle (4,3);
+ % \draw (2.75,2.5) node {\texttt{ld-linux.so}};
+ % \draw [->] (2.75,1) -- (2.75,2);
+ % \draw (2.75,1.5) node [anchor=west]{\texttt{execve}};
+
+ % \filldraw[fill=black!15,rounded corners] (1.5,4) rectangle (4,5);
+ % \draw (2.75,4.5) node {\texttt{main}};
+
+ % \draw [<->, dashed] (2.75,3) -- (2.75,4);
+ % \draw [->] (1.5,4.5) -- (0.3,4.5) -- (0.3,1);
+ % \draw (0.9,4.5) node [anchor=south] {\texttt{\_exit}};
+
+ % \filldraw[fill=black!15,rounded corners] (1.5,6) rectangle (4,7);
+ % \draw (2.75,6.5) node {\texttt{funzione}};
+
+ % \draw [<->, dashed] (2.75,5) -- (2.75,6);
+ % \draw [->] (1.5,6.5) -- (0.05,6.5) -- (0.05,1);
+ % \draw (0.9,6.5) node [anchor=south] {\texttt{\_exit}};
+
+ % \draw (6.75,4.5) node (exit) [rectangle,fill=black!15,minimum width=2.5cm,minimum height=1cm,rounded corners, draw]{\texttt{exit}};
+
+ % \draw[->] (4,6.5) -- node[anchor=south west]{\texttt{exit}} (exit);
+ % \draw[->] (4,4.5) -- node[anchor=south]{\texttt{exit}} (exit);
+ % \draw[->] (exit) -- node[anchor=east]{\texttt{\_exit}}(6.75,1);
+
+ % \draw (10,4.5) node (exithandler1) [rectangle,fill=black!15,rounded corners, draw]{\textsf{exit handler}};
+ % \draw (10,5.5) node (exithandler2) [rectangle,fill=black!15,rounded corners, draw]{\textsf{exit handler}};
+ % \draw (10,3.5) node (stream) [rectangle,fill=black!15,rounded corners, draw]{\textsf{chiusura stream}};
+
+ % \draw[<->, dashed] (exithandler1) -- (exit);
+ % \draw[<->, dashed] (exithandler2) -- (exit);
+ % \draw[<->, dashed] (stream) -- (exit);
+ % \end{tikzpicture}
+ \caption{Schema dell'avvio e della conclusione di un programma.}
+ \label{fig:proc_prog_start_stop}
+\end{figure}
+
+Si ricordi infine che un programma può anche essere interrotto dall'esterno
+attraverso l'uso di un segnale (modalità di conclusione non mostrata in
+fig.~\ref{fig:proc_prog_start_stop}); tratteremo nei dettagli i segnali e la
+loro gestione nel capitolo \ref{cha:signals}.
+
+
+
+\section{I processi e l'uso della memoria}
+\label{sec:proc_memory}
+
+Una delle risorse più importanti che ciascun processo ha a disposizione è la
+memoria, e la gestione della memoria è appunto uno degli aspetti più complessi
+di un sistema unix-like. In questa sezione, dopo una breve introduzione ai
+concetti di base, esamineremo come la memoria viene vista da parte di un
+programma in esecuzione, e le varie funzioni utilizzabili per la sua gestione.
+
+
+\subsection{I concetti generali}
+\label{sec:proc_mem_gen}
+
+\index{memoria~virtuale|(}
+
+Ci sono vari modi in cui i sistemi operativi organizzano la memoria, ed i
+dettagli di basso livello dipendono spesso in maniera diretta
+dall'architettura dell'hardware, ma quello più tipico, usato dai sistemi
+unix-like come Linux è la cosiddetta \textsl{memoria virtuale} che consiste
+nell'assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare,
+in cui gli indirizzi vanno da zero ad un qualche valore massimo.\footnote{nel
+ caso di Linux fino al kernel 2.2 detto massimo era, per macchine a 32bit, di
+ 2Gb. Con il kernel 2.4 ed il supporto per la \textit{high-memory} il limite
+ è stato esteso anche per macchine a 32 bit.} Come accennato nel
+cap.~\ref{cha:intro_unix} questo spazio di indirizzi è virtuale e non
+corrisponde all'effettiva posizione dei dati nella RAM del computer. In
+generale detto spazio non è neppure continuo, cioè non tutti gli indirizzi
+possibili sono utilizzabili, e quelli usabili non sono necessariamente
+adiacenti.
+
+\itindbeg{huge~page}
+
+Per la gestione da parte del kernel la memoria viene divisa in pagine di
+dimensione fissa. Inizialmente queste pagine erano di 4kb sulle macchine a 32
+bit e di 8kb sulle alpha. Con le versioni più recenti del kernel è possibile
+anche utilizzare pagine di dimensioni maggiori (di 4Mb, dette \textit{huge
+ page}), per sistemi con grandi quantitativi di memoria in cui l'uso di
+pagine troppo piccole comporta una perdita di prestazioni. In alcuni sistemi
+la costante \constd{PAGE\_SIZE}, definita in \headfile{limits.h}, indica la
+dimensione di una pagina in byte, con Linux questo non avviene e per ottenere
+questa dimensione si deve ricorrere alla funzione \func{getpagesize} (vedi
+sez.~\ref{sec:sys_memory_res}).
+
+\itindend{huge~page}
+\itindbeg{page~table}
+
+Ciascuna pagina di memoria nello spazio di indirizzi virtuale è associata ad
+un supporto che può essere una pagina di memoria reale o ad un dispositivo di
+stoccaggio secondario (come lo spazio disco riservato alla \textit{swap}, o i
+file che contengono il codice). Per ciascun processo il kernel si cura di
+mantenere un mappa di queste corrispondenze nella cosiddetta \textit{page
+ table}.\footnote{questa è una semplificazione brutale, il meccanismo è molto
+ più complesso; una buona trattazione di come Linux gestisce la memoria
+ virtuale si trova su \cite{LinVM}.}
+
+\itindend{page~table}
+
+Una stessa pagina di memoria reale può fare da supporto a diverse pagine di
+memoria virtuale appartenenti a processi diversi, come accade in genere per le
+pagine che contengono il codice delle librerie condivise. Ad esempio il codice
+della funzione \func{printf} starà su una sola pagina di memoria reale che
+farà da supporto a tutte le pagine di memoria virtuale di tutti i processi che
+hanno detta funzione nel loro codice.
+
+\index{paginazione|(}
+
+La corrispondenza fra le pagine della memoria virtuale di un processo e quelle
+della memoria fisica della macchina viene gestita in maniera trasparente dal
+kernel.\footnote{in genere con l'ausilio dell'hardware di gestione della
+ memoria (la \textit{Memory Management Unit} del processore), con i kernel
+ della serie 2.6 è comunque diventato possibile utilizzare Linux anche su
+ architetture che non dispongono di una MMU.} Poiché in genere la memoria
+fisica è solo una piccola frazione della memoria virtuale, è necessario un
+meccanismo che permetta di trasferire le pagine che servono dal supporto su
+cui si trovano in memoria, eliminando quelle che non servono. Questo
+meccanismo è detto \textsl{paginazione} (o \textit{paging}), ed è uno dei
+compiti principali del kernel.
+
+\itindbeg{page~fault}
+
+Quando un processo cerca di accedere ad una pagina che non è nella memoria
+reale, avviene quello che viene chiamato un \textit{page fault}; la gestione
+della memoria genera un'interruzione e passa il controllo al kernel il quale
+sospende il processo e si incarica di mettere in RAM la pagina richiesta,
+effettuando tutte le operazioni necessarie per reperire lo spazio necessario,
+per poi restituire il controllo al processo.
+
+Dal punto di vista di un processo questo meccanismo è completamente
+trasparente, e tutto avviene come se tutte le pagine fossero sempre
+disponibili in memoria. L'unica differenza avvertibile è quella dei tempi di
+esecuzione, che passano dai pochi nanosecondi necessari per l'accesso in RAM
+se la pagina è direttamente disponibile, a tempi estremamente più lunghi,
+dovuti all'intervento del kernel, qualora sia necessario reperire pagine
+riposte nella \textit{swap}.
+
+\itindend{page~fault}
+
+Normalmente questo è il prezzo da pagare per avere un \textit{multitasking}
+reale, ed in genere il sistema è molto efficiente in questo lavoro; quando
+però ci siano esigenze specifiche di prestazioni è possibile usare delle
+funzioni che permettono di bloccare il meccanismo della paginazione e
+mantenere fisse delle pagine in memoria (vedi sez.~\ref{sec:proc_mem_lock}).
+
+\index{paginazione|)}
+\index{memoria~virtuale|)}
+
+
+\subsection{La struttura della memoria di un processo}
+\label{sec:proc_mem_layout}
+
+\itindbeg{segment~violation}
+
+Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
+una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
+tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
+commette quando si è manipolato male un puntatore e genera quella che viene
+chiamata una \textit{segment violation}. Se si tenta cioè di leggere o
+scrivere con un indirizzo per il quale non esiste un'associazione nella
+memoria virtuale, il kernel risponde al relativo \textit{page fault} mandando
+un segnale \signal{SIGSEGV} al processo, che normalmente ne causa la
+terminazione immediata.
+
+\itindend{segment~violation}
+
+È pertanto importante capire come viene strutturata la memoria virtuale di un
+processo. Essa viene divisa in \textsl{segmenti}, cioè un insieme contiguo di
+indirizzi virtuali ai quali il processo può accedere. Solitamente un
+programma C viene suddiviso nei seguenti segmenti:
+\index{segmento!testo|(}
+\index{segmento!dati|(}
+\itindbeg{heap}
+\itindbeg{stack}
+\begin{enumerate}
+\item Il \textsl{segmento di testo} o \textit{text segment}. Contiene il
+ codice del programma, delle funzioni di librerie da esso utilizzate, e le
+ costanti. Normalmente viene condiviso fra tutti i processi che eseguono lo
+ stesso programma e nel caso delle librerie anche da processi che eseguono
+ altri programmi.
+
+ Quando l'architettura hardware lo supporta viene marcato in sola lettura per
+ evitare sovrascritture accidentali (o maliziose) che ne modifichino le
+ istruzioni. Viene allocato da \func{execve} all'avvio del programma e resta
+ invariato per tutto il tempo dell'esecuzione.
+\index{variabili!globali|(}
+\index{variabili!statiche|(}
+\item Il \textsl{segmento dei dati} o \textit{data segment}. Contiene tutti i
+ dati del programma, come le \textsl{variabili globali}, cioè quelle definite
+ al di fuori di tutte le funzioni che compongono il programma, e le
+ \textsl{variabili statiche}, cioè quelle dichiarate con l'attributo
+ \direct{static},\footnote{la direttiva \direct{static} indica al compilatore
+ C che una variabile così dichiarata all'interno di una funzione deve
+ essere mantenuta staticamente in memoria (nel segmento dati appunto);
+ questo significa che la variabile verrà inizializzata una sola volta alla
+ prima invocazione della funzione e che il suo valore sarà mantenuto fra
+ diverse esecuzioni della funzione stessa, la differenza con una variabile
+ globale è che essa può essere vista solo all'interno della funzione in cui
+ è dichiarata.} e la memoria allocata dinamicamente. Di norma è diviso in
+ tre parti:
+ \begin{itemize}
+ \item Il segmento dei dati inizializzati, che contiene le variabili il cui
+ valore è stato assegnato esplicitamente. Ad esempio se si definisce:
+ \includecodesnip{listati/pi.c}
+ questo valore sarà immagazzinato in questo segmento. La memoria di questo
+ segmento viene preallocata all'avvio del programma e inizializzata ai valori
+ specificati.
+ \item Il segmento dei dati non inizializzati, che contiene le variabili il
+ cui valore non è stato assegnato esplicitamente. Ad esempio se si
+ definisce:
+ \includecodesnip{listati/vect.c}
+ questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
+ allocato all'avvio, e tutte le variabili vengono inizializzate a zero (ed
+ i puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
+ variabili che vanno nel segmento dati, e non è affatto vero in
+ generale.} Storicamente questa seconda parte del segmento dati viene
+ chiamata \itindex{Block~Started~by~Symbol~(BSS)} BSS (da \textit{Block
+ Started by Symbol}). La sua dimensione è fissa.
+ \index{variabili!globali|)} \index{variabili!statiche|)}
+ \item Lo \textit{heap}, detto anche \textit{free store}. Tecnicamente lo si
+ può considerare l'estensione del segmento dei dati non inizializzati, a
+ cui di solito è posto giusto di seguito. Questo è il segmento che viene
+ utilizzato per l'allocazione dinamica della memoria. Lo \textit{heap} può
+ essere ridimensionato allargandolo e restringendolo per allocare e
+ disallocare la memoria dinamica con le apposite funzioni (vedi
+ sez.~\ref{sec:proc_mem_alloc}), ma il suo limite inferiore, quello
+ adiacente al segmento dei dati non inizializzati, ha una posizione fissa.
+ \end{itemize}
+\item Il segmento di \textit{stack}, che contiene quello che viene chiamato lo
+ ``\textit{stack}'' del programma. Tutte le volte che si effettua una
+ chiamata ad una funzione è qui che viene salvato l'indirizzo di ritorno e le
+ informazioni dello stato del chiamante (come il contenuto di alcuni registri
+ della CPU), poi la funzione chiamata alloca qui lo spazio per le sue
+ variabili locali. Tutti questi dati vengono \textit{impilati} (da questo
+ viene il nome \textit{stack}) in sequenza uno sull'altro; in questo modo le
+ funzioni possono essere chiamate ricorsivamente. Al ritorno della funzione
+ lo spazio è automaticamente rilasciato e ``\textsl{ripulito}''.\footnote{il
+ compilatore si incarica di generare automaticamente il codice necessario,
+ seguendo quella che viene chiamata una \textit{calling convention}; quella
+ standard usata con il C ed il C++ è detta \textit{cdecl} e prevede che gli
+ argomenti siano caricati nello \textit{stack} dal chiamante da destra a
+ sinistra, e che sia il chiamante stesso ad eseguire la ripulitura dello
+ \textit{stack} al ritorno della funzione, se ne possono però utilizzare di
+ alternative (ad esempio nel Pascal gli argomenti sono inseriti da sinistra
+ a destra ed è compito del chiamato ripulire lo \textit{stack}), in genere
+ non ci si deve preoccupare di questo fintanto che non si mescolano
+ funzioni scritte con linguaggi diversi.}
+
+ La dimensione di questo segmento aumenta seguendo la crescita dello
+ \textit{stack} del programma, ma non viene ridotta quando quest'ultimo si
+ restringe.
+\end{enumerate}
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[height=10cm]{img/memory_layout}
+ % \begin{tikzpicture}
+ % \draw (0,0) rectangle (4,1);
+ % \draw (2,0.5) node {\textit{text}};
+ % \draw (0,1) rectangle (4,2.5);
+ % \draw (2,1.75) node {dati inizializzati};
+ % \draw (0,2.5) rectangle (4,5);
+ % \draw (2,3.75) node {dati non inizializzati};
+ % \draw (0,5) rectangle (4,9);
+ % \draw[dashed] (0,6) -- (4,6);
+ % \draw[dashed] (0,8) -- (4,8);
+ % \draw (2,5.5) node {\textit{heap}};
+ % \draw (2,8.5) node {\textit{stack}};
+ % \draw [->] (2,6) -- (2,6.5);
+ % \draw [->] (2,8) -- (2,7.5);
+ % \draw (0,9) rectangle (4,10);
+ % \draw (2,9.5) node {\textit{environment}};
+ % \draw (4,0) node [anchor=west] {\texttt{0x08000000}};
+ % \draw (4,5) node [anchor=west] {\texttt{0x08xxxxxx}};
+ % \draw (4,9) node [anchor=west] {\texttt{0xC0000000}};
+ % \end{tikzpicture}
+ \caption{Disposizione tipica dei segmenti di memoria di un processo.}
+ \label{fig:proc_mem_layout}
+\end{figure}
+
+Una disposizione tipica dei vari segmenti (testo, dati inizializzati e non
+inizializzati, \textit{heap}, \textit{stack}, ecc.) è riportata in
+fig.~\ref{fig:proc_mem_layout}. Si noti come in figura sia indicata una
+ulteriore regione, marcata \textit{environment}, che è quella che contiene i
+dati relativi alle variabili di ambiente passate al programma al suo avvio
+(torneremo su questo argomento in sez.~\ref{sec:proc_environ}).
+
+Usando il comando \cmd{size} su un programma se ne può stampare le dimensioni
+dei segmenti di testo e di dati (solo però per i dati inizializzati ed il BSS,
+dato che lo \textit{heap} ha una dimensione dinamica). Si tenga presente
+comunque che il BSS, contrariamente al segmento dei dati inizializzati, non è
+mai salvato sul file che contiene l'eseguibile, dato che viene sempre
+inizializzato a zero al caricamento del programma.
+
+\index{segmento!testo|)}
+\index{segmento!dati|)}
+\itindend{heap}
+\itindend{stack}
+
+
+\subsection{Allocazione della memoria per i programmi C}
+\label{sec:proc_mem_alloc}
+
+Il C supporta direttamente, come linguaggio di programmazione, soltanto due
+modalità di allocazione della memoria: l'\textsl{allocazione statica} e
+l'\textsl{allocazione automatica}.
+
+L'\textsl{allocazione statica} è quella con cui sono memorizzate le variabili
+globali e le variabili statiche, cioè le variabili il cui valore deve essere
+mantenuto per tutta la durata del programma. Come accennato queste variabili
+vengono allocate nel segmento dei dati all'avvio del programma come parte
+delle operazioni svolte da \func{exec}, e lo spazio da loro occupato non viene
+liberato fino alla sua conclusione.
+
+\index{variabili!automatiche|(}
+
+L'\textsl{allocazione automatica} è quella che avviene per gli argomenti di
+una funzione e per le sue variabili locali, quelle che vengono definite
+all'interno della funzione che esistono solo per la durata della sua
+esecuzione e che per questo vengono anche dette \textsl{variabili
+ automatiche}. Lo spazio per queste variabili viene allocato nello
+\textit{stack} quando viene eseguita la funzione e liberato quando si esce
+dalla medesima.
+
+\index{variabili!automatiche|)}
+
+Esiste però un terzo tipo di allocazione, l'\textsl{allocazione dinamica}
+della memoria, che non è prevista direttamente all'interno del linguaggio C,
+ma che è necessaria quando il quantitativo di memoria che serve è
+determinabile solo durante il corso dell'esecuzione del programma. Il C non
+consente di usare variabili allocate dinamicamente, non è possibile cioè
+definire in fase di programmazione una variabile le cui dimensioni possano
+essere modificate durante l'esecuzione del programma. Per questo la libreria
+standard del C fornisce una opportuna serie di funzioni per eseguire
+l'allocazione dinamica di memoria, che come accennato avviene nello
+\textit{heap}.
+
+Le variabili il cui contenuto è allocato in questo modo non potranno essere
+usate direttamente come le altre (quelle nello \textit{stack}), ma l'accesso
+sarà possibile solo in maniera indiretta, attraverso i puntatori alla memoria
+loro riservata che si sono ottenuti dalle funzioni di allocazione.
+
+Le funzioni previste dallo standard ANSI C per la gestione della memoria sono
+quattro: \func{malloc}, \func{calloc}, \func{realloc} e \func{free}. Le prime
+due, \funcd{malloc} e \funcd{calloc} allocano nuovo spazio di memoria; i
+rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{void *calloc(size\_t nmemb, size\_t size)}
+\fdesc{Alloca un'area di memoria inizializzata a 0.}
+\fdecl{void *malloc(size\_t size)}
+\fdesc{Alloca un'area di memoria non inizializzata.}
+}
+{Entrambe le funzioni restituiscono il puntatore alla zona di memoria allocata
+in caso di successo e \val{NULL} in caso di fallimento, nel qual caso
+ \var{errno} assumerà il valore \errcode{ENOMEM}.}
+\end{funcproto}
+
+In genere si usano \func{malloc} e \func{calloc} per allocare dinamicamente
+un'area di memoria.\footnote{queste funzioni presentano un comportamento
+ diverso fra la \acr{glibc} e la \acr{uClib} quando il valore di \param{size}
+ è nullo. Nel primo caso viene comunque restituito un puntatore valido,
+ anche se non è chiaro a cosa esso possa fare riferimento, nel secondo caso
+ viene restituito \val{NULL}. Il comportamento è analogo con
+ \code{realloc(NULL, 0)}.} Dato che i puntatori ritornati sono di tipo
+generico non è necessario effettuare un cast per assegnarli a puntatori al
+tipo di variabile per la quale si effettua l'allocazione, inoltre le funzioni
+garantiscono che i puntatori siano allineati correttamente per tutti i tipi di
+dati; ad esempio sulle macchine a 32 bit in genere sono allineati a multipli
+di 4 byte e sulle macchine a 64 bit a multipli di 8 byte.
+
+Nel caso di \func{calloc} l'area di memoria viene allocata nello \textit{heap}
+come un vettore di \param{nmemb} membri di \param{size} byte di dimensione, e
+preventivamente inizializzata a zero, nel caso di \func{malloc} invece vengono
+semplicemente allocati \param{size} byte e l'area di memoria non viene
+inizializzata.
+
+Una volta che non sia più necessaria la memoria allocata dinamicamente deve
+essere esplicitamente rilasciata usando la funzione \funcd{free},\footnote{le
+ glibc provvedono anche una funzione \funcm{cfree} definita per compatibilità
+ con SunOS, che è deprecata.} il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{void free(void *ptr)}
+\fdesc{Disalloca un'area di memoria precedentemente allocata.}
+}
+{La funzione non ritorna nulla e non riporta errori.}
+\end{funcproto}
+
+Questa funzione vuole come argomento \var{ptr} il puntatore restituito da una
+precedente chiamata ad una qualunque delle funzioni di allocazione che non sia
+già stato liberato da un'altra chiamata a \func{free}. Se il valore di
+\param{ptr} è \val{NULL} la funzione non fa niente, mentre se l'area di
+memoria era già stata liberata da una precedente chiamata il comportamento
+della funzione è dichiarato indefinito, ma in genere comporta la corruzione
+dei dati di gestione dell'allocazione, che può dar luogo a problemi gravi, ad
+esempio un \textit{segmentation fault} in una successiva chiamata di una di
+queste funzioni.
+
+\itindbeg{double~free}
+
+Dato che questo errore, chiamato in gergo \textit{double free}, è abbastanza
+frequente, specie quando si manipolano vettori di puntatori, e dato che le
+conseguenze possono essere pesanti ed inaspettate, si suggerisce come
+soluzione precauzionale di assegnare sempre a \val{NULL} ogni puntatore su cui
+sia stata eseguita \func{free} immediatamente dopo l'esecuzione della
+funzione. In questo modo, dato che con un puntatore nullo \func{free} non
+esegue nessuna operazione, si evitano i problemi del \textit{double free}.
+
+\itindend{double~free}
+
+Infine la funzione \funcd{realloc} consente di modificare, in genere di
+aumentare, la dimensione di un'area di memoria precedentemente allocata; il
+suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{void *realloc(void *ptr, size\_t size)}
+\fdesc{Cambia la dimensione di un'area di memoria precedentemente allocata.}
+} {La funzione ritorna il puntatore alla zona di memoria allocata in caso
+ di successo e \val{NULL} per un errore, nel qual caso \var{errno}
+ assumerà il valore \errcode{ENOMEM}.}
+\end{funcproto}
+
+La funzione vuole come primo argomento il puntatore restituito da una
+precedente chiamata a \func{malloc} o \func{calloc} e come secondo argomento
+la nuova dimensione (in byte) che si intende ottenere. Se si passa
+per \param{ptr} il valore \val{NULL} allora la funzione si comporta come
+\func{malloc}.\footnote{questo è vero per Linux e l'implementazione secondo lo
+ standard ANSI C, ma non è vero per alcune vecchie implementazioni, inoltre
+ alcune versioni delle librerie del C consentivano di usare \func{realloc}
+ anche per un puntatore liberato con \func{free} purché non ci fossero state
+ nel frattempo altre chiamate a funzioni di allocazione, questa funzionalità
+ è totalmente deprecata e non è consentita sotto Linux.}
+
+La funzione si usa ad esempio quando si deve far crescere la dimensione di un
+vettore. In questo caso se è disponibile dello spazio adiacente al precedente
+la funzione lo utilizza, altrimenti rialloca altrove un blocco della
+dimensione voluta, copiandoci automaticamente il contenuto; lo spazio aggiunto
+non viene inizializzato. Se la funzione fallisce l'area di memoria originale
+non viene assolutamente toccata.
+
+Si deve sempre avere ben presente il fatto che il blocco di memoria restituito
+da \func{realloc} può non essere un'estensione di quello che gli si è passato
+in ingresso; per questo si dovrà \emph{sempre} eseguire la riassegnazione di
+\param{ptr} al valore di ritorno della funzione, e reinizializzare o provvedere
+ad un adeguato aggiornamento di tutti gli altri puntatori all'interno del
+blocco di dati ridimensionato.
+
+La \acr{glibc} ha un'implementazione delle funzioni di allocazione che è
+controllabile dall'utente attraverso alcune variabili di ambiente (vedi
+sez.~\ref{sec:proc_environ}), in particolare diventa possibile tracciare
+questo tipo di errori usando la variabile di ambiente \envvar{MALLOC\_CHECK\_}
+che quando viene definita mette in uso una versione meno efficiente delle
+funzioni suddette, che però è più tollerante nei confronti di piccoli errori
+come quello dei \textit{double free} o i \textit{buffer overrun} di un
+byte.\footnote{uno degli errori più comuni, causato ad esempio dalla scrittura
+ di una stringa di dimensione pari a quella del buffer, in cui ci si
+ dimentica dello zero di terminazione finale.} In particolare:
+\begin{itemize*}
+\item se la variabile è posta a $0$ gli errori vengono ignorati;
+\item se la variabile è posta a $1$ viene stampato un avviso sullo
+ \textit{standard error} (vedi sez.~\ref{sec:file_fd});
+\item se la variabile è posta a $2$ viene chiamata la funzione \func{abort}
+ (vedi sez.~\ref{sec:sig_alarm_abort}), che in genere causa l'immediata
+ terminazione del programma;
+\item se la variabile è posta a $3$ viene stampato l'avviso e chiamata
+ \func{abort}.
+\end{itemize*}
+
+\itindbeg{memory~leak}
+
+L'errore di programmazione più comune e più difficile da risolvere che si
+incontra con le funzioni di allocazione è quando non viene opportunamente
+liberata la memoria non più utilizzata, quello che in inglese viene chiamato
+\textit{memory leak}, cioè una \textsl{perdita di memoria}.
+
+Un caso tipico che illustra il problema è quello in cui in una propria
+funzione si alloca della memoria per uso locale senza liberarla prima di
+uscire. La memoria resta così allocata fino alla terminazione del processo.
+Chiamate ripetute alla stessa funzione continueranno ad effettuare altre
+allocazioni, che si accumuleranno causando a lungo andare un esaurimento della
+memoria disponibile e la probabile impossibilità di proseguire l'esecuzione
+del programma.
+
+Il problema è che l'esaurimento della memoria può avvenire in qualunque
+momento, in corrispondenza ad una qualunque chiamata di \func{malloc} che può
+essere in una sezione del codice che non ha alcuna relazione con la funzione
+che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
+\textit{memory leak}. In C e C++ il problema è particolarmente sentito. In
+C++, per mezzo della programmazione ad oggetti, il problema dei \textit{memory
+ leak} si può notevolmente ridimensionare attraverso l'uso accurato di
+appositi oggetti come gli \textit{smartpointers}. Questo però in genere va a
+scapito delle prestazioni dell'applicazione in esecuzione.
+
+% TODO decidere cosa fare di questo che segue 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é l'infrastruttura del
+% linguaggio gestisce automaticamente la cosiddetta
+% \itindex{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
+% eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
+% la presenza di una infrastruttura per la loro interpretazione e pertanto hanno
+% di per sé delle prestazioni più scadenti rispetto alle stesse applicazioni
+% compilate direttamente). Questo comporta però il problema della non
+% predicibilità del momento in cui viene deallocata la memoria precedentemente
+% allocata da un oggetto.
+
+Per limitare l'impatto di questi problemi, e semplificare la ricerca di
+eventuali errori, l'implementazione delle funzioni di allocazione nella
+\acr{glibc} mette a disposizione una serie di funzionalità che permettono 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
+sostituti opportuni delle funzioni di allocazione in grado, senza neanche
+ricompilare il programma,\footnote{esempi sono \textit{Dmalloc}
+ \url{http://dmalloc.com/} di Gray Watson ed \textit{Electric Fence} di Bruce
+ Perens.} di eseguire diagnostiche anche molto complesse riguardo
+l'allocazione della memoria. Vedremo alcune delle funzionalità di ausilio
+presenti nella \acr{glibc} in sez.~\ref{sec:proc_memory_adv_management}.
+
+\itindend{memory~leak}
+
+Una possibile alternativa all'uso di \func{malloc}, per evitare di soffrire
+dei problemi di \textit{memory leak} descritti in precedenza, è di allocare la
+memoria nel segmento di \textit{stack} della funzione corrente invece che
+nello \textit{heap}. Per farlo si può usare la funzione \funcd{alloca}, la cui
+sintassi è identica a quella di \func{malloc}; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{void *alloca(size\_t size)}
+\fdesc{Alloca un'area di memoria nello \textit{stack}.}
+}
+{La funzione ritorna il puntatore alla zona di memoria allocata, in caso
+ di errore il comportamento è indefinito.}
+\end{funcproto}
+
+La funzione alloca la quantità di memoria (non inizializzata) richiesta
+dall'argomento \param{size} nel segmento di \textit{stack} della funzione
+chiamante. Con questa funzione non è più necessario liberare la memoria
+allocata, e quindi non esiste un analogo della \func{free}, in quanto essa
+viene rilasciata automaticamente al ritorno della funzione.
+
+Come è evidente questa funzione ha alcuni vantaggi interessanti, anzitutto
+permette di evitare alla radice i problemi di \textit{memory leak}, dato che
+non serve più la deallocazione esplicita; inoltre la deallocazione automatica
+funziona anche quando si usa \func{longjmp} per uscire da una subroutine con
+un salto non locale da una funzione (vedi sez.~\ref{sec:proc_longjmp}). Un
+altro vantaggio è che in Linux la funzione è molto più veloce di \func{malloc}
+e non viene sprecato spazio, infatti non è necessario gestire un pool di
+memoria da riservare e si evitano così anche i problemi di frammentazione di
+quest'ultimo, che comportano inefficienze sia nell'allocazione della memoria
+che nell'esecuzione dell'allocazione.
+
+Gli svantaggi sono che questa funzione non è disponibile su tutti gli Unix, e
+non è inserita né nello standard POSIX né in SUSv3 (ma è presente in BSD), il
+suo utilizzo quindi limita la portabilità dei programmi. Inoltre la funzione
+non può essere usata nella lista degli argomenti di una funzione, perché lo
+spazio verrebbe allocato nel mezzo degli stessi. Inoltre non è chiaramente
+possibile usare \func{alloca} per allocare memoria che deve poi essere usata
+anche al di fuori della funzione in cui essa viene chiamata, dato che
+all'uscita dalla funzione lo spazio allocato diventerebbe libero, e potrebbe
+essere sovrascritto all'invocazione di nuove funzioni. Questo è lo stesso
+problema che si può avere con le variabili automatiche, su cui torneremo in
+sez.~\ref{sec:proc_var_passing}.
+
+Infine non esiste un modo di sapere se l'allocazione ha avuto successo, la
+funzione infatti viene realizzata inserendo del codice \textit{inline} nel
+programma\footnote{questo comporta anche il fatto che non è possibile
+ sostituirla con una propria versione o modificarne il comportamento
+ collegando il proprio programma con un'altra libreria.} che si limita a
+modificare il puntatore nello \textit{stack} e non c'è modo di sapere se se ne
+sono superate le dimensioni, per cui in caso di fallimento nell'allocazione il
+comportamento del programma può risultare indefinito, dando luogo ad una
+\textit{segment violation} la prima volta che si cerchi di accedere alla
+memoria non effettivamente disponibile.
+
+\index{segmento!dati|(}
+\itindbeg{heap}
+
+Le due funzioni seguenti vengono utilizzate soltanto quando è necessario
+effettuare direttamente la gestione della memoria associata allo spazio dati
+di un processo,\footnote{le due funzioni sono state definite con BSD 4.3, sono
+ marcate obsolete in SUSv2 e non fanno parte delle librerie standard del C e
+ mentre sono state esplicitamente rimosse dallo standard POSIX.1-2001.} per
+poterle utilizzare è necessario definire una della macro di funzionalità (vedi
+sez.~\ref{sec:intro_gcc_glibc_std}) fra \macro{\_BSD\_SOURCE},
+\macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE} (ad un valore maggiore o
+uguale di 500). La prima funzione è \funcd{brk}, ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int brk(void *addr)}
+\fdesc{Sposta la fine del segmento dati del processo.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà il valore \errcode{ENOMEM}.}
+\end{funcproto}
+
+La funzione è un'interfaccia all'omonima \textit{system call} ed imposta
+l'indirizzo finale del segmento dati di un processo (più precisamente dello
+\textit{heap}) all'indirizzo specificato da \param{addr}. Quest'ultimo deve
+essere un valore ragionevole e la dimensione totale non deve comunque eccedere
+un eventuale limite (vedi sez.~\ref{sec:sys_resource_limit}) sulle dimensioni
+massime del segmento dati del processo.
+
+Il valore di ritorno della funzione fa riferimento alla versione fornita dalla
+\acr{glibc}, in realtà in Linux la \textit{system call} corrispondente
+restituisce come valore di ritorno il nuovo valore della fine del segmento
+dati in caso di successo e quello corrente in caso di fallimento, è la
+funzione di interfaccia usata dalla \acr{glibc} che fornisce i valori di
+ritorno appena descritti; se si usano librerie diverse questo potrebbe non
+accadere.
+
+Una seconda funzione per la manipolazione diretta delle dimensioni del
+segmento dati\footnote{in questo caso si tratta soltanto di una funzione di
+ libreria, anche se basata sulla stessa \textit{system call}.} è
+\funcd{sbrk}, ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{void *sbrk(intptr\_t increment)}
+\fdesc{Incrementa la dimensione del segmento dati del processo.}
+}
+{La funzione ritorna il puntatore all'inizio della nuova zona di memoria
+ allocata in caso di successo e \val{NULL} per un errore, nel qual
+ caso \var{errno} assumerà il valore \errcode{ENOMEM}.}
+\end{funcproto}
+
+La funzione incrementa la dimensione dello \textit{heap} di un programma del
+valore indicato dall'argomento \param{increment}, restituendo il nuovo
+indirizzo finale dello stesso. L'argomento è definito come di tipo
+\typed{intptr\_t}, ma a seconda della versione delle librerie e del sistema
+può essere indicato con una serie di tipi equivalenti come \type{ptrdiff\_t},
+\type{ssize\_t}, \ctyp{int}. Se invocata con un valore nullo la funzione
+permette di ottenere l'attuale posizione della fine del segmento dati.
+
+Queste due funzioni sono state deliberatamente escluse dallo standard POSIX.1
+dato che per i normali programmi è sempre opportuno usare le funzioni di
+allocazione standard descritte in precedenza, a meno di non voler realizzare
+per proprio conto un diverso meccanismo di gestione della memoria del segmento
+dati.
+\itindend{heap}
+\index{segmento!dati|)}
+
+
+\subsection{Il controllo della memoria virtuale}
+\label{sec:proc_mem_lock}
+
+\index{memoria~virtuale|(}
+
+Come spiegato in sez.~\ref{sec:proc_mem_gen} il kernel gestisce la memoria
+virtuale in maniera trasparente ai processi, decidendo quando rimuovere pagine
+dalla memoria per metterle nell'area di \textit{swap}, sulla base
+dell'utilizzo corrente da parte dei vari processi.
+
+Nell'uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il
+meccanismo della paginazione riporta in RAM, ed in maniera trasparente, tutte
+le pagine che gli occorrono; esistono però esigenze particolari in cui non si
+vuole che questo meccanismo si attivi. In generale i motivi per cui si possono
+avere di queste necessità sono due:
+\begin{itemize*}
+\item \textsl{La velocità}. Il processo della paginazione è trasparente solo
+ se il programma in esecuzione non è sensibile al tempo che occorre a
+ riportare la pagina in memoria; per questo motivo processi critici che hanno
+ esigenze di tempo reale o tolleranze critiche nelle risposte (ad esempio
+ processi che trattano campionamenti sonori) possono non essere in grado di
+ sopportare le variazioni della velocità di accesso dovuta alla paginazione.
+
+ In certi casi poi un programmatore può conoscere meglio dell'algoritmo di
+ allocazione delle pagine le esigenze specifiche del suo programma e decidere
+ quali pagine di memoria è opportuno che restino in memoria per un aumento
+ delle prestazioni. In genere queste sono esigenze particolari e richiedono
+ anche un aumento delle priorità in esecuzione del processo (vedi
+ sez.~\ref{sec:proc_real_time}).
+
+\item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro
+ in memoria queste possono essere portate su disco dal meccanismo della
+ paginazione. Questo rende più lungo il periodo di tempo in cui detti segreti
+ sono presenti in chiaro e più complessa la loro cancellazione: un processo
+ infatti può cancellare la memoria su cui scrive le sue variabili, ma non può
+ toccare lo spazio disco su cui una pagina di memoria può essere stata
+ salvata. Per questo motivo di solito i programmi di crittografia richiedono
+ il blocco di alcune pagine di memoria.
+\end{itemize*}
+
+Per ottenere informazioni sulle modalità in cui un programma sta usando la
+memoria virtuale è disponibile una apposita funzione di sistema,
+\funcd{mincore}, che però non è standardizzata da POSIX e pertanto non è
+disponibile su tutte le versioni di kernel unix-like;\footnote{nel caso di
+ Linux devono essere comunque definite le macro \macro{\_BSD\_SOURCE} e
+ \macro{\_SVID\_SOURCE} o \macro{\_DEFAULT\_SOURCE}.} il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fhead{sys/mman.h}
+\fdecl{int mincore(void *addr, size\_t length, unsigned char *vec)}
+\fdesc{Ritorna lo stato delle pagine di memoria occupate da un processo.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+caso \var{errno} assumerà uno dei valori:
+\begin{errlist}
+ \item[\errcode{EAGAIN}] il kernel è temporaneamente non in grado di fornire
+ una risposta.
+ \item[\errcode{EFAULT}] \param{vec} punta ad un indirizzo non valido.
+ \item[\errcode{EINVAL}] \param{addr} non è un multiplo delle dimensioni di
+ una pagina.
+ \item[\errcode{ENOMEM}] o \param{addr}$+$\param{length} eccede la dimensione
+ della memoria usata dal processo o l'intervallo di indirizzi specificato
+ non è mappato.
+\end{errlist}}
+\end{funcproto}
+
+La funzione permette di ottenere le informazioni sullo stato della mappatura
+della memoria per il processo chiamante, specificando l'intervallo da
+esaminare con l'indirizzo iniziale, indicato con l'argomento \param{addr}, e
+la lunghezza, indicata con l'argomento \param{length}. L'indirizzo iniziale
+deve essere un multiplo delle dimensioni di una pagina, mentre la lunghezza
+può essere qualunque, fintanto che si resta nello spazio di indirizzi del
+processo,\footnote{in caso contrario si avrà un errore di \errcode{ENOMEM};
+ fino al kernel 2.6.11 in questo caso veniva invece restituito
+ \errcode{EINVAL}, in considerazione che il caso più comune in cui si
+ verifica questo errore è quando si usa per sbaglio un valore negativo
+ di \param{length}, che nel caso verrebbe interpretato come un intero
+ positivo di grandi dimensioni.} ma il risultato verrà comunque fornito per
+l'intervallo compreso fino al multiplo successivo.
+
+% TODO: verificare i cambiamenti di sematica con il kernel 5.0 (restrizione
+% solo alle pagine relative al processo stesso) vedi:
+% https://lwn.net/Articles/776034/,
+% https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=574823bfab82d9d8fa47f422778043fbb4b4f50e
+
+I risultati della funzione vengono forniti nel vettore puntato da \param{vec},
+che deve essere allocato preventivamente e deve essere di dimensione
+sufficiente a contenere tanti byte quante sono le pagine contenute
+nell'intervallo di indirizzi specificato, la dimensione cioè deve essere
+almeno pari a \code{(length+PAGE\_SIZE-1)/PAGE\_SIZE}. Al ritorno della
+funzione il bit meno significativo di ciascun byte del vettore sarà acceso se
+la pagina di memoria corrispondente è al momento residente in memoria, o
+cancellato altrimenti. Il comportamento sugli altri bit è indefinito, essendo
+questi al momento riservati per usi futuri. Per questo motivo in genere è
+comunque opportuno inizializzare a zero il contenuto del vettore, così che le
+pagine attualmente residenti in memoria saranno indicate da un valore non
+nullo del byte corrispondente.
+
+Dato che lo stato della memoria di un processo può cambiare continuamente, il
+risultato di \func{mincore} è assolutamente provvisorio e lo stato delle
+pagine potrebbe essere già cambiato al ritorno stesso della funzione, a meno
+che, come vedremo ora, non si sia attivato il meccanismo che forza il
+mantenimento di una pagina sulla memoria.
+
+\itindbeg{memory~locking}
+
+Il meccanismo che previene la paginazione di parte della memoria virtuale di
+un processo è chiamato \textit{memory locking} (o \textsl{blocco della
+ memoria}). Il blocco è sempre associato alle pagine della memoria virtuale
+del processo, e non al segmento reale di RAM su cui essa viene mantenuta. La
+regola è che se un segmento di RAM fa da supporto ad almeno una pagina
+bloccata allora esso viene escluso dal meccanismo della paginazione. I blocchi
+non si accumulano, se si blocca due volte la stessa pagina non è necessario
+sbloccarla due volte, una pagina o è bloccata oppure no.
+
+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}. Inoltre i \textit{memory lock} non sono
+ereditati dai processi figli, 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, e quindi fintanto che un
+figlio non scrive su un segmento bloccato, può usufruire del \textit{memory
+ lock} del padre. Infine i \textit{memory lock} vengono automaticamente
+rimossi se si pone in esecuzione un altro programma con \func{exec} (vedi
+sez.~\ref{sec:proc_exec}).
+
+Il sistema pone dei limiti all'ammontare di memoria di un processo che può
+essere bloccata e al totale di memoria fisica che si può dedicare a questo, lo
+standard POSIX.1 richiede che sia definita in \headfile{unistd.h} la macro
+\macrod{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
+\textit{memory locking}.