+Come accennato funzioni per l'uscita ``normale'' da un programma sono due, la
+prima è la funzione \func{exit} che è definita dallo standard ANSI C; il
+prototipo della funzione è il seguente:
+\begin{prototype}{stdlib.h}{void exit(int status)}
+ Causa la conclusione ordinaria del programma restituendo il valore
+ \var{status} al processo padre.
+
+ \bodydesc{La funzione non ritorna. Il processo viene terminato.}
+\end{prototype}
+
+La funzione \func{exit} è pensata per una conclusione pulita di un programma
+che usa le librerie standard del C; essa esegue tutte le funzioni che sono
+state registrate con \func{atexit} e \func{on\_exit} (vedi
+\secref{sec:proc_atexit}), e chiude tutti gli stream di I/O effettuando il
+salvataggio dei dati sospesi (chiamando \func{fclose}, vedi
+\secref{sec:file_fclose}), infine ripassa il controllo al kernel chiamando
+\func{\_exit} e passando il valore \var{status} come stato di uscita.
+
+La system call \func{\_exit} restituisce direttamente il controllo al
+kernel, concludendo immediatamente il processo, le eventuali funzioni
+registrate con \func{atexit} e \func{on\_exit} non vengono eseguite. Il
+prototipo della funzione è il seguente:
+\begin{prototype}{unistd.h}{void \_exit(int status)}
+ Causa la conclusione immediata del programma restituendo il valore
+ \var{status} al processo padre.
+
+ \bodydesc{La funzione non ritorna. Il processo viene terminato.}
+\end{prototype}
+
+La funzione chiude tutti i file descriptor appartenenti al processo (si tenga
+presente che questo non comporta il salvataggio dei dati bufferizzati degli
+stream), fa si che ogni figlio del processo sia ereditato da \cmd{init}
+(vedi \secref{cha:process_handling}), manda un segnale \macro{SIGCHLD} al
+processo padre (vedi \ref{sec:sig_job_control}) ed infine ritorna lo stato di
+uscita specificato in \var{status} che può essere raccolto usando la
+funzione \func{wait} (vedi \secref{sec:proc_wait}).
+
+
+\subsection{Le funzioni \func{atexit} e \func{on\_exit}}
+\label{sec:proc_atexit}
+
+Come accennato l'uso di \func{exit} al posto della \func{\_exit} è fatto
+principalmente per permettere una uscita pulita dalle funzioni delle librerie
+standard del C (in particolare per quel che riguarda la chiusura degli
+stream).
+
+Quando si realizza una libreria da usare in varie applicazioni può essere
+perciò utile evitare di richiedere di chiamare esplicitamente un funzione di
+uscita che esegua tutte le operazioni di pulizia prima di uscire (come quella
+di salvare eventuali dati sospesi). È invece molto meno soggetto ad errori e
+completamente trasparente all'utente poter effettuare una chiamata automatica
+di 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 funzioni che verranno eseguite all'uscita dal programma (sia per
+la chiamata ad \func{exit} che per il ritorno di \func{main}). La prima
+funzione che si può utilizzare a tal fine è:
+\begin{prototype}{stdlib.h}{void atexit(void (*function)(void))}
+ Registra la funzione \param{function} per essere chiamata all'uscita dal
+ programma.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ fallimento, \var{errno} non viene settata.}
+\end{prototype}
+
+La funzione richiede come argomento l'indirizzo della opportuna da chiamare
+all'uscita che non deve prendere argomenti e non deve ritornare niente. Una
+estensione di \func{atexit} è la funzione \func{on\_exit} (che la glibc
+include per compatibilità con SunOS e che non è detto sia definita su altri
+sistemi), il cui prototipo è:
+\begin{prototype}{stdlib.h}
+{void on\_exit(void (*function)(int status, void *arg), void *arg)}
+ Registra la funzione \var{function} per essere chiamata all'uscita dal
+ programma. Tutte le funzioni registrate vengono chiamate in ordine inverso
+ rispetto a quello di registrazione.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ fallimento, \var{errno} non viene settata.}
+\end{prototype}
+
+In questo caso la funzione da chiamare prende due parametri, il primo dei
+quali sarà inizializzato allo stato di uscita con cui è stata chiamata
+\func{exit} ed il secondo al puntatore generico specificato come secondo
+argomento nella chiamata di \func{on\_exit}.
+
+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); poi verranno chiusi tutti gli
+stream aperti, infine verrà chiamata \func{\_exit}.
+
+
+\subsection{Conclusioni}
+\label{sec:proc_term_conclusion}
+
+Data l'importanza dell'argomento è opportuno sottolineare ancora una volta che
+in un sistema unix l'unico modo in cui un programma può essere eseguito dal
+kernel è attraverso la chiamata alla system call \func{execve} (in genere
+attraverso una delle funzioni \func{exec} che vedremo in
+\secref{sec:proc_exec}).
+
+Allo stesso modo l'unico modo in cui un programma può concludere
+volontariamente la sua esecuzione è attraverso una chiamata alla system call
+\func{\_exit} sia esplicitamente o che in maniera indiretta attraverso l'uso
+di \func{exit} o il ritorno della funzione \func{main}.
+
+Lo schema delle modalità con cui si avvia e conclude normalmente un programma
+è riportato in \nfig.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=12cm]{img/proc_beginend}
+ \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
+\curfig); torneremo su questo aspetto in \secref{cha:signals}.
+
+
+
+\section{I processi e l'uso della memoria}
+\label{sec:proc_memory}
+
+Una delle risorse base che ciascun processo ha a disposizione è la memoria, ed
+uno degli aspetti più complessi di un sistema unix (ed in particolar modo di
+Linux) è appunto la gestione della memoria. Qui ci occuperemo però di come la
+memoria viene vista dal punto di vista di un programma in esecuzione in un
+processo.
+
+
+\subsection{I concetti generali}
+\label{sec:proc_mem_gen}
+
+Ci sono vari modi in cui i vari sistemi organizzano la memoria (ed i dettagli
+di basso livello dipendono in maniera diretta dall'architettura
+dell'hardware), ma quello più tipico, usato da unix (e da Linux) è quello di
+assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare in
+cui gli indirizzi vanno da zero ad un qualche valore massimo (nel caso di
+Linux fino al kernel 2.2 detto massimo era per macchine a 32bit di 2Gb, con il
+kernel 2.4 il limite è stato esteso).
+
+Come accennato nell'introduzione questo spazio di indirizzi è virtuale e non
+corrisponde all'effettiva posizione dei dati nella RAM del computer; in genere
+detto spazio non è neanche continuo (cioè non tutti gli indirizzi sono
+utilizzabili e/o utilizzati).
+
+La memoria virtuale viene divisa in pagine di dimensione fissa (che ad esempio
+sono di 4kb su macchine a 32 bit e 8kb sulle alpha, valori strettamente
+connessi all'hardware di gestione della memoria), e ciascuna pagina della
+memoria virtuale è associata ad un supporto che può essere una pagina di
+memoria reale o ad un dispositivo di stoccaggio secondario (in genere lo
+spazio disco riservato alla swap, o i file che contengono il codice).
+
+Lo stesso pezzo di memoria reale (o di spazio disco) 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 hanno detta funzione nel loro codice.
+
+La corrispondenza fra le pagine della memoria virtuale e quelle della memoria
+fisica della macchina viene gestita in maniera trasparente dall'hardware di
+gestione della memoria (la \textit{Memory Management Unit} del processore),
+ma poiché in genere quest'ultima è solo una piccola frazione della memoria
+virtuale è necessario un meccanismo che permetta di trasferire le pagine
+virtuali che servono dal supporto su cui si trovano in memoria, eliminando
+quelle che non servono. Questo meccanismo è detto \textit{paging}, ed è uno
+dei compiti principali del kernel.
+
+Quando un processo cerca di accedere ad una pagina che non è nella memoria
+reale, avviene quello che viene chiamato un \textit{page fault}; l'hardware di
+gestione della memoria (la MMU del processore) genera una 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 a tempi molto più
+lunghi, dovuti all'intervento del kernel. Normalmente questo è il prezzo da
+pagare per avere un 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 del paging e mantenere fisse delle pagine in memoria (vedi
+\ref{sec:proc_mem_lock}).
+
+
+\subsection{La struttura della memoria di un processo}
+\label{sec:proc_mem_layout}
+
+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 quello che viene
+chiamato un \textit{segmentation fault}. Se si tenta cioè di leggere o
+scrivere da un indirizzo per il quale non esiste una associazione della pagina
+virtuale il kernel risponde al relativo \textit{page fault}, mandando un
+segnale \macro{SIGSEGV} al processo, che normalmente ne causa la terminazione
+immediata.
+
+È 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:
+
+\begin{enumerate}
+\item Il segmento di testo (\textit{text segment}). Contiene il codice
+ macchina del programma e le costanti statiche. Normalmente viene condiviso,
+ in modo che più processi (anche diversi nel caso di librerie) possano
+ utilizzarlo, e viene marcato in sola lettura per evitare sovrascritture
+ accidentali (o maliziose) che ne modifichino le istruzioni.
+
+ Viene allocato da \func{exec} all'avvio del programma e resta invariato
+ per tutto il tempo dell'esecuzione.
+
+\item Il segmento dei dati (\textit{data segment}). Contiene le variabili
+ globali (cioè quelle definite al di fuori di tutte le funzioni). Di norma è
+ diviso in due parti.
+
+ La prima parte è il segmento dei dati inizializzati, che contiene le
+ variabili globali il cui valore è stato assegnato esplicitamente. Ad esempio
+ se si definisce:
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+ double pi = 3.14;
+\end{lstlisting}
+ questo valore sarà immagazzinato in questo segmento. La memoria di questo
+ segmento viene preallocato dalla \func{exec} e inizializzata ai valori
+ specificati.
+
+ La seconda parte è il segmento dei dati non inizializzati, che contiene le
+ variabili globali il cui valore è stato non è assegnato esplicitamente. Ad
+ esempio se si definisce:
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+ int vect[100];
+\end{lstlisting}
+ questo valore sarà immagazzinato in questo segmento. Anch'esso viene
+ allocato all'avvio, e tutte le variabili vengono inizializzate a
+ zero (ed i puntatori a \macro{NULL}).
+
+ Storicamente questo segmento viene chiamato BBS (da \textit{block started by
+ symbol}. La sua dimensione è fissa.
+
+\item Lo \textit{heap}. Tecnicamente lo si può considerare l'estensione del
+ segmento dati, a cui di solito è posto giusto di seguito. È qui che avviene
+ l'allocazione dinamica della memoria; può essere ridimensionato allocando e
+ disallocando la memoria dinamica con le apposite funzioni (vedi
+ \secref{sec:proc_mem_alloc}), ma il suo limite inferiore (quello adiacente
+ al segmento dati) ha una posizione fissa.
+
+\item Il segmento di \textit{stack}, che contiene 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 (tipo il contenuto di alcuni registri della CPU); poi la
+ funzione chiamata alloca qui lo spazio per le sue variabili locali, in
+ questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
+ della funzione lo spazio è automaticamente rilasciato.
+
+ La dimensione di questo segmento aumenta seguendo la crescita dello stack
+ del programma, ma non viene ridotta quando quest'ultimo si restringe.
+\end{enumerate}
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=5cm]{img/memory_layout}
+ \caption{Disposizione tipica dei segmenti di memoria di un processo}
+ \label{fig:proc_mem_layout}
+\end{figure}
+
+Una disposizione tipica di questi segmenti è riportata in \nfig. Usando il
+comando \cmd{size} su un programma se ne può stampare le dimensioni dei
+segmenti di testo e di dati (inizializzati e BSS); il BSS però non è mai
+salvato sul file, in quanto viene inizializzato a zero al caricamento del
+programma.
+
+
+\subsection{Allocazione della memoria per i programmi C}
+\label{sec:proc_mem_alloc}
+
+Il C supporta due tipi di allocazione della memoria, l'allocazione statica è
+quella in cui vanno le variabili globali e le variabili statiche (e viene
+effettuata nel segmento dei dati), lo spazio per queste variabili viene
+allocati all'avvio del programma (come parte delle operazioni svolte da
+\func{exec}) e non viene liberato fino alla sua conclusione.
+
+L'allocazione automatica è quella che avviene per le cosiddette variabili
+automatiche, cioè gli argomenti delle funzioni o le variabili locali. Lo
+spazio per queste variabili viene allocato nello stack quando viene eseguito
+comando di invocazione della funzione e liberato quando si esce dalla
+medesima.
+
+Esiste però un terzo tipo di allocazione, che non è prevista dal linguaggio C,
+che è l'allocazione dinamica della memoria, necessaria quando il quantitativo
+di memoria che serve è determinabile solo in corso di 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ò le librerie
+del C forniscono una serie opportuna di funzioni per permettere l'allocazione
+dinamica di spazio in memoria (in genere nello heap, usando la system call
+\func{sbrk}), solo che a questo punto detto spazio sarà accessibile solo in
+maniera indiretta attraverso dei puntatori.
+
+
+\subsection{Le funzioni \func{malloc}, \func{calloc}, \func{realloc} e
+ \func{free}}
+\label{sec:proc_mem_malloc}
+
+Le funzioni previste dallo standard ANSI C per la gestione della memoria sono
+quattro, i prototipi sono i seguenti:
+\begin{functions}
+\headdecl{stdlib.h}
+\funcdecl{void *calloc(size\_t size)}
+ Alloca \var{size} byte nello heap. La memoria viene inizializzata a 0.
+
+ La funzione restituisce il puntatore alla zona di memoria allocata in caso
+ di successo e \macro{NULL} in caso di fallimento, nel qual caso
+ \var{errno} viene settata a \macro{ENOMEM}.
+\funcdecl{void *malloc(size\_t size)}
+ Alloca \var{size} byte nello heap. La memoria non viene inizializzata.
+
+ La funzione restituisce il puntatore alla zona di memoria allocata in caso
+ di successo e \macro{NULL} in caso di fallimento, nel qual caso
+ \var{errno} viene settata a \macro{ENOMEM}.
+\funcdecl{void *realloc(void *ptr, size\_t size)}
+ Cambia la dimensione del blocco allocato all'indirizzo \var{ptr}
+ portandola a \var{size}.
+
+ La funzione restituisce il puntatore alla zona di memoria allocata in caso
+ di successo e \macro{NULL} in caso di fallimento, nel qual caso
+ \var{errno} viene settata a \macro{ENOMEM}.
+\funcdecl{void free(void *ptr)}
+ Disalloca lo spazio di memoria puntato da \var{ptr}.
+
+ La funzione non ritorna nulla e non riporta errori.
+\end{functions}
+Il puntatore che le funzioni di allocazione ritornano è garantito essere
+sempre correttamente allineato per tutti i tipi di dati; ad esempio sulle
+macchine a 32 bit in genere è allineato a multipli di 4 byte e sulle macchine
+a 64 bit a multipli di 8 byte.
+
+In genere su usano le funzioni \func{malloc} e \func{calloc} per allocare
+dinamicamente la memoria necessaria al programma, siccome 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 la
+allocazione.
+
+La memoria allocata dinamicamente deve essere esplicitamente rilasciata usando
+\func{free}\footnote{le glibc provvedono anche una funzione \func{cfree}
+ definita per compatibilità con SunOS, che è deprecata} una volta che non
+sia più necessaria. Questa funzione vuole come parametro un puntatore
+restituito da una precedente chiamata a una qualunque delle funzioni di
+allocazione e che non sia già stato liberato da un'altra chiamata a
+\func{free}, in caso contrario il comportamento della funzione è indefinito.
+
+La funzione \func{realloc} si usa invece per cambiare (in genere aumentare)
+la dimensione di un'area di memoria precedentemente allocata, la funzione
+vuole in ingresso il puntatore restituito dalla precedente chiamata ad una
+\func{malloc} (se è passato un valore \macro{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 altre chiamate a funzioni di
+ allocazione, questa funzionalità è totalmente deprecata e non è consentita
+ sotto Linux}), 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.
+
+Si deve sempre avere ben presente il fatto che il blocco di memoria restituito
+da \func{realloc} può non essere una estensione di quello che gli si è passato
+come parametro; pertanto esso deve essere trattato allo stesso modo di una
+nuova allocazione; in particolare si dovrà \emph{sempre} eseguire la
+riassegnazione di \var{ptr} al valore di ritorno della funzione, e
+reinizializzare (o provvedere ad un adeguato aggiornamento qualora ancora
+servano) tutti gli altri puntatori al blocco di dati ridimensionato.
+
+Uno degli errori più comuni (specie se si ha a che fare con array di
+puntatori) è infatti quello di chiamare \func{free} più di una volta sullo
+stesso puntatore; per evitare questo problema una soluzione di ripiego è
+quella di assegnare sempre a \macro{NULL} ogni puntatore liberato con
+\func{free}, dato che, quando il parametro è un puntatore nullo,
+\func{free} non esegue nessuna operazione.
+
+Linux e le glibc hanno una implementazione delle routine di allocazione che è
+controllabile dall'utente attraverso alcune variabili di ambiente, in
+particolare diventa possibile tracciare questo tipo di errori usando la
+variabile \macro{MALLOC\_CHECK\_} che quando viene settata mette in uso una
+versione meno efficiente delle funzioni, che però è più 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 è posta ad 1 viene stampato un avviso sullo \textit{standard error}
+ (vedi \secref{sec:file_std_stream}).
+\item se è posta a 2 viene chiamata \func{abort}, che in genere causa
+ l'immediata conclusione del programma.
+\end{itemize*}
+
+Il problema più comune e più difficile da tracciare che si incontra con
+l'allocazione della memoria è però quando la memoria non più utilizzata non
+viene opportunamente liberata (quello che in inglese viene chiamato
+\textit{memory-leak}, traducibile come \textsl{perdita di memoria}).
+
+Un caso tipico è quando l'allocazione viene fatta da una subroutine per un uso
+locale, ma la memoria non viene liberata una volta usata; chiamate ripetute
+alla stessa subroutine causeranno a lungo andare un esaurimento della memoria
+disponibile, con un conseguente crash dell'applicazione che può avvenire in
+qualunque momento, e senza nessuna relazione con la subroutine che contiene
+l'errore.
+
+Per questo motivo l'implementazione delle routine di allocazione delle glibc
+mette a disposizione una serie di funzionalità (su cui torneremo in
+\secref{sec:xxx_advanced}) che permettono di tracciare le allocazioni e
+le disallocazione, e definisce anche una serie di possibili agganci che
+permettono di sostituire alle funzioni di libreria una propria versione (che
+può essere più o meno specializzata per il debugging).
+
+
+\subsection{La funzione \func{alloca}}
+\label{sec:proc_mem_alloca}
+
+Una alternativa possibile all'uso di \func{malloc}, che non soffre del tipo
+di problemi di memory leak descritti in precedenza è la funzione
+\func{alloca} che invece che allocare la memoria nello heap usa lo il
+segmento di stack della funzione corrente. La sintassi è identica:
+\begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
+ Alloca \var{size} byte nel segmento di stack della funzione chiamante.
+ La memoria non viene inizializzata.
+
+ La funzione restituisce il puntatore alla zona di memoria allocata in caso
+ di successo e \macro{NULL} in caso di fallimento, nel qual caso
+ \var{errno} viene settata a \macro{ENOMEM}.
+\end{prototype}
+\noindent ma in questo caso non è più necessario liberare la memoria in quanto
+questa viene rilasciata automaticamente al ritorno della funzione.
+
+Come è evidente questa funzione ha molti vantaggi, e permette di evitare i
+problemi di memory leak non essendo più necessaria la deallocazione esplicita;
+una delle ragioni principali per usarla è però che funziona anche quando si
+usa \func{longjmp} per uscire con un salto non locale da una funzione (vedi
+\secref{sec:proc_longjmp}),
+
+Un altro vantaggio e che in Linux la funzione è molto veloce e non viene
+sprecato spazio, infatti non è necessario gestire un pool di memoria da
+riservare e si evitano anche i problemi di frammentazione di quest'ultimo che
+comportano inefficienze sia nell'allocazione della memoria che nell'esecuzione
+della funzione.
+
+Gli svantaggi sono che questa funzione non è disponibile su tutti gli unix,
+(quando non è possibile aumentare le dimensioni dello stack una volta chiamata
+una funzione) e quindi l'uso limita la portabilità dei programmi, inoltre se
+si cerca di allocare troppa memoria non si ottiene un messaggio di errore, ma
+un segnale di \textit{segment violation} analogo a quello che si avrebbe da
+una ricorsione infinita.
+
+Inoltre non è chiaramente possibile usare questa funzione per allocare memoria
+che deve poi essere usata anche al di fuori della funzione in cui questa viene
+chiamata, in quanto all'uscita dalla funzione lo spazio allocato diventerebbe
+libero, e potrebbe essere sovrascritto all'invocazione di nuove funzioni con
+conseguenze imprevedibili. Questo è lo stesso problema potenziale che si può
+avere con le variabili automatiche, su cui torneremo in
+\secref{sec:proc_auto_var}.
+
+
+\subsection{Le funzioni \func{brk} e \func{sbrk}}
+\label{sec:proc_mem_sbrk}
+
+L'uso di queste funzioni è necessario solo quando si voglia accedere alle
+analoghe system call a cui fanno da interfaccia (ad esempio per implementare
+una propria versione di \func{malloc}. Le funzioni sono:
+\begin{functions}
+ \headdecl{unistd.h}
+ \funcdecl{int brk(void *end\_data\_segment)}
+ Sposta la fine del segmento dei dati all'indirizzo specificato da
+ \var{end\_data\_segment}.
+
+ La funzione restituisce 0 in caso di successo e -1 in caso di
+ fallimento, nel qual caso \var{errno} viene settata a \macro{ENOMEM}.
+
+ \funcdecl{void *sbrk(ptrdiff\_t increment)} Incrementa lo spazio dati di un
+ programma di \var{increment}. Un valore zero restituisce l'attuale posizione
+ della fine del segmento dati.
+
+ La funzione restituisce il puntatore all'inizio della nuova zona di memoria
+ allocata in caso di successo e \macro{NULL} in caso di fallimento, nel qual
+ caso \macro{errno} viene settata a \macro{ENOMEM}.
+\end{functions}
+
+Queste funzioni sono state deliberatamente escluse dallo standard POSIX.1 e
+per i programmi normali è opportuno usare le funzioni di allocazione standard
+descritte in precedenza, che sono costruite su di esse. In genere si usa
+\func{sbrk} con un valore zero per ottenere l'attuale posizione della fine
+del segmento dati.
+
+
+% \subsection{La personalizzazione delle funzioni di allocazione}
+% \label{sec:proc_mem_malloc_custom}
+
+
+\subsection{Il controllo della memoria virtuale}
+\label{sec:proc_mem_lock}
+
+Come spiegato in \secref{sec:proc_mem_gen} il kernel gestisce la memoria in
+maniera trasparente ai processi, decidendo quando rimuovere pagine dalla
+memoria per metterle nello 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 si attivi il meccanismo dello \textit{swapping}, in generale i
+motivi per cui si possono avere queste necessità sono sostanzialmente due:
+\begin{itemize}
+\item La velocità. Il processo della paginazione è trasparente solo se il
+ programma in esecuzione se non è sensibile al tempo che occorre a riportare
+ la pagina in memoria; per questo motivi processi critici che hanno esigenze
+ di tempo reale o tolleranze critiche nella 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 (vedi \secref{sec:xxx_xxx}).
+
+\item La sicurezza. Se si tengono password o chiavi in memoria queste possono
+ essere portate su disco dal meccanismo della paginazione, questo rende più
+ lungo il periodo di tempo in cui i segreti sono presenti in chiaro e più
+ complessa la loro cancellazione (ad un processo è possibile cancellare la
+ memoria su cui scrive le sue variabili, ma non può toccare lo spazio disco
+ su cui la pagina contenente i segreti può essere stata salvata). Per questo
+ motivo di solito i programmi di crittografia richiedono il blocco di alcune
+ pagine di memoria.
+\end{itemize}
+
+Il meccanismo che previene la paginazione di parte della memoria virtuale di
+un processo è chiamato \textit{memory locking} (blocco della memoria), il
+blocco è sempre associato alle pagine della memoria virtuale del processo, non
+con il 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 o 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}.
+
+I \textit{memory lock} non sono ereditati dai processi figli\footnote{ma
+ siccome Linux usa il copy on write gli indirizzi virtuali del figlio sono
+ mantenuti sullo stesso segmento di RAM del padre, quindi fintanto che un
+ figlio non scrive su un segmento, può usufruire dei memory lock del padre}.
+Siccome la presenza di un \textit{memory lock} riduce la memoria disponibile
+al sistema con un impatto su tutti gli altri processi, solo l'amministratore ha
+la capacità di bloccare una pagina. Ogni processo però può sbloccare le sue
+pagine.
+
+
+Il sistema pone dei limiti all'ammontare di memoria di un processo che può
+essere bloccata e al totale di memoria fisica che può dedicare a questo, lo
+standard POSIX.1 richiede che sia definita in \file{unistd.h} la costante
+\macro{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
+\textit{memory locking} e la costante \macro{PAGESIZE} in \file{limits.h} per
+indicare la dimensione di una pagina in byte.
+
+
+Le funzioni per bloccare e sbloccare singole sezioni di memoria sono
+\func{mlock} e \func{munlock}; i loro prototipi sono:
+\begin{functions}
+ \headdecl{sys/mman.h}
+
+ \funcdecl{int mlock(const void *addr, size\_t len)}
+ Blocca la paginazione per l'intervallo di memoria da \var{addr} per
+ \var{len} byte. Tutte le pagine che contengono una parte dell'intervallo
+ sono mantenute in RAM per tutta la durata del blocco.
+
+ \funcdecl{int munlock(const void *addr, size\_t len)}
+ Sblocca l'intervallo di memoria da \var{addr} per \var{len} byte.
+
+
+ \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 in
+ caso di errore, nel qual caso \var{errno} è settata ad uno dei
+ valori seguenti:
+ \begin{errlist}
+ \item[\macro{ENOMEM}] alcuni indirizzi dell'intervallo specificato non
+ corrispondono allo spazio di indirizzi del processo o si è ecceduto
+ il numero massimo consentito di pagine bloccate.
+ \item[\macro{EINVAL}] \var{len} non è un valore positivo.
+ \end{errlist}
+ e, per \func{mlock}, anche \macro{EPERM} quando il processo non ha i
+ privilegi richiesti per l'operazione.}
+\end{functions}
+
+Altre due funzioni, \func{mlockall} e \func{munlockall}, consentono di
+bloccare genericamente lo spazio di indirizzi di un processo. I prototipi di
+queste funzioni sono:
+
+\begin{functions}
+ \headdecl{sys/mman.h}
+
+ \funcdecl{int mlockall(int flags)}
+ Blocca la paginazione per lo spazio di indirizzi del processo corrente.
+
+ \funcdecl{int munlockall(void)}
+ Sblocca la paginazione per lo spazio di indirizzi del processo corrente.
+
+ \bodydesc{Codici di ritorno ed errori sono gli stessi di \func{mlock}
+ e \func{munlock}.}
+\end{functions}
+
+Il parametro \var{flags} di \func{mlockall} permette di controllarne il
+comportamento; esso può essere specificato come l'OR aritmetico delle due
+costanti:
+\begin{basedescript}{\desclabelwidth{2.5cm}}
+\item[\macro{MCL\_CURRENT}] blocca tutte le pagine correntemente mappate nello
+ spazio di indirizzi del processo.
+\item[\macro{MCL\_FUTURE}] blocca tutte le pagine che saranno mappate nello
+ spazio di indirizzi del processo.
+\end{basedescript}
+
+Con \func{mlockall} si può bloccare tutte le pagine mappate nello spazio di
+indirizzi del processo, sia che comprendano il segmento di testi, di dati, lo
+stack e lo heap e pure le funzioni di libreria chiamate, i file mappati in
+memoria, i dati del kernel mappati in user space, la memoria condivisa. L'uso
+dei flag permette di selezionare con maggior finezza le pagine da bloccare, ad
+esempio limitandosi a tutte le pagine allocate a partire da un certo momento.
+
+In ogni caso un processo real-time che deve entrare in una sezione critica
+deve provvedere a riservare memoria sufficiente prima dell'ingresso, in genere
+questo si fa chiamando una funzione che ha allocato una quantità sufficiente
+ampia di variabili automatiche, in modo che esse vengano mappate in RAM dallo
+stack e poi ci scrive sopra, per scongiurare in partenza un eventuale page
+fault causato dal meccanismo di copy on write.
+
+
+\section{La gestione di parametri e opzioni}
+\label{sec:proc_options}
+
+Il passaggio dei parametri e delle variabili di ambiente dalla riga di comando
+al singolo programma quando viene lanciato è effettuato attraverso le
+variabili \var{argc}, \var{argv} che vengono passate al programma
+come argomenti della funzione principale.
+
+\subsection{Il formato dei parametri}
+\label{sec:proc_par_format}
+In genere passaggio dei parametri 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 parametro; di default per
+individuare le parole viene usato come separatore lo spazio (comportamento
+modificabile attraverso il settaggio della variabile di ambiente IFS).
+
+Nella scansione viene costruito il vettore di puntatori \var{argv} inserendo
+in successione il puntatore alla stringa costituente l'$n$-simo parametro; la
+variabile \var{argc} viene inizializzata al numero di parametri trovati, in
+questo modo il primo parametro è sempre il nome del programma (vedi \nfig).
+
+\subsection{La gestione delle opzioni}
+\label{sec:proc_opt_handling}
+
+In generale un programma unix riceve da linea di comando sia gli argomenti che
+le opzioni, queste ultime sono standardizzate per essere riconosciute come
+tali: un elemento di \var{argv} che inizia con \texttt{-} e che non sia un
+singolo \texttt{-} o \texttt{--} viene considerato un'opzione. In in genere
+le opzioni sono costituite da una lettera preceduta dal meno e possono avere o
+no un parametro associato; un comando tipico può essere cioè qualcosa del
+tipo:
+\begin{verbatim}
+touch -r riferimento.txt -m questofile.txt
+\end{verbatim}
+ed in questo caso le opzioni sono \texttt{m} ed \texttt{r}.
+
+Per gestire le opzioni all'interno dei argomenti a linea di comando passati in
+\func{argv} le librerie standard del C forniscono la funzione \func{getopt}
+che ha il seguente prototipo:
+\begin{prototype}{unistd.h}
+{int getopt(int argc, char * const argv[], const char * optstring)}
+Esegue il parsing degli argomenti passati da linea di comando
+riconoscendo le possibili opzioni segnalate con \var{optstring}.
+
+\bodydesc{Ritorna il carattere che segue l'opzione, \cmd{':'} se manca un
+ parametro all'opzione, \cmd{'?'} se l'opzione è sconosciuta, e -1 se non
+ esistono altre opzioni.}
+\end{prototype}
+
+Questa funzione prende come argomenti le due variabili \var{argc} e \var{argv}
+passate a \func{main} (vedi \secref{sec:proc_main}) ed una stringa che indica
+quali sono le opzioni valide; la funzione effettua la scansione della lista
+degli argomenti ricercando ogni stringa che comincia con \cmd{-} e ritorna ogni
+volta che trova una opzione valida.
+
+La stringa \var{optstring} indica quali sono le opzioni riconosciute ed è
+costituita da tutti i caratteri usati per identificare le singole opzioni, se
+l'opzione ha un parametro al carattere deve essere fatto seguire un segno di
+due punti \var{':'}, nel caso appena accennato ad esempio la stringa di
+opzioni sarebbe \var{"r:m"}.
+
+La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
+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 \var{optstring} viene ritornato il carattere \texttt{'?'}
+mentre se un opzione che lo richiede non è seguita da un parametro viene
+ritornato il carattere \texttt{':'}, infine se viene incontrato il valore
+\cmd{--} la scansione viene considerata conclusa, anche se vi sono altri
+elementi di \var{argv} che cominciano con il carattere \texttt{'-'}.
+
+\begin{figure}[htb]
+ \footnotesize
+ \begin{lstlisting}{}
+ opterr = 0; /* don't want writing to stderr */
+ while ( (i = getopt(argc, argv, "hp:c:e:")) != -1) {
+ switch (i) {
+ /*
+ * Handling options
+ */
+ case 'h': /* help option */
+ printf("Wrong -h option use\n");
+ usage();
+ return -1;
+ break;
+ case 'c': /* take wait time for childen */
+ wait_child = strtol(optarg, NULL, 10); /* convert input */
+ break;
+ case 'p': /* take wait time for childen */
+ wait_parent = strtol(optarg, NULL, 10); /* convert input */
+ break;
+ case 'e': /* take wait before parent exit */
+ wait_end = strtol(optarg, NULL, 10); /* convert input */
+ break;
+ case '?': /* unrecognized options */
+ printf("Unrecognized options -%c\n",optopt);
+ usage();
+ default: /* should not reached */
+ usage();
+ }
+ }
+ debug("Optind %d, argc %d\n",optind,argc);
+ \end{lstlisting}
+ \caption{Esempio di codice per la gestione delle opzioni.}
+ \label{fig:proc_options_code}
+\end{figure}
+
+Quando la funzione trova un'opzione essa ritorna il valore numerico del
+carattere, in questo modo si possono prendere le azioni relative usando uno
+\func{switch}; la funzione inizializza inoltre alcune variabili globali:
+\begin{itemize*}
+\item \var{char * optarg} contiene il puntatore alla stringa parametro
+ dell'opzione.
+\item \var{int optind} alla fine della scansione restituisce l'indice del
+ primo elemento di \var{argv} che non è un'opzione.
+\item \var{int opterr} previene, se posto a zero, la stampa di un messaggio
+ di errore in caso di riconoscimento di opzioni non definite.
+\item \var{int optopt} contiene il carattere dell'opzione non riconosciuta.
+\end{itemize*}
+
+In \figref{fig:proc_options_code} è mostrata la sezione del programma
+\file{ForkTest.c} (che useremo nel prossimo capitolo per effettuare dei test
+sulla creazione dei processi) deputata alla decodifica delle opzioni a riga di
+comando.
+
+Anzitutto si può notare che si è anzitutto (\texttt{\small 1}) disabilitata la
+stampa di messaggi di errore per opzioni non riconosciute, per poi passare al
+ciclo per la verifica delle opzioni (\texttt{\small 2-27}); per ciascuna delle
+opzioni possibili si è poi provveduto ad una opportuna azione, ad esempio per
+le tre opzioni che prevedono un parametro si è effettuata la decodifica del
+medesimo, il cui indirizzo è contenuto nella variabile \var{optarg},
+avvalorando la relativa variabile (\texttt{\small 12-14}, \texttt{\small
+ 15-17} e \texttt{\small 18-20}). Completato il ciclo troveremo in
+\var{optind} l'indice in \var{argv[]} del primo degli argomenti a linea di
+comando restanti.
+
+Normalmente \func{getopt} compie una permutazione degli elementi di \var{argv}
+così che alla fine della scansione gli elementi che non sono opzioni sono
+spostati in coda al vettore. Oltre a questa esistono altre due modalità di
+gestire gli elementi di \var{argv}; se \var{optstring} inizia con il carattere
+\texttt{'+'} (o è settata la variabile di ambiente \macro{POSIXLY\_CORRECT})
+la scansione viene fermata non appena si incontra un elemento che non è
+un'opzione. L'ultima modalità, usata quando un programma può gestire la
+mescolanza fra opzioni e argomenti, ma se li aspetta in un ordine definito, si
+attiva quando \var{optstring} inizia con il carattere \texttt{'-'}. In questo
+caso ogni elemento che non è un'opzione viene considerato comunque un'opzione
+e associato ad un valore di ritorno pari ad 1, questo permette di identificare
+gli elementi che non sono opzioni, ma non effettua il riordinamento del
+vettore \var{argv}.
+
+
+\subsection{Opzioni in formato esteso}
+\label{sec:proc_opt_extended}
+
+Un'estensione di questo schema è costituito 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}.
+
+(NdA: da finire).
+
+
+\subsection{Le variabili di ambiente}
+\label{sec:proc_environ}
+
+Oltre agli argomenti passati a linea di comando ogni processo riceve dal
+sistema un \textsl{ambiente}, nella forma di una lista di variabili
+(\textit{environment list}) messa a disposizione dal processo, e costruita
+nella chiamata alla funzione \func{exec} quando questo viene lanciato.
+
+Come per la lista dei parametri anche questa lista è un array di puntatori a
+caratteri, ciascuno dei quali punta ad una stringa (terminata da un
+\macro{NULL}). A differenza di \var{argv[]} però in questo caso non si ha una
+lunghezza dell'array data da un equivalente di \var{argc}, ma la lista è
+terminata da un puntatore nullo.
+
+L'indirizzo della lista delle variabili di ambiente è passato attraverso la
+variabile globale \var{environ}, a cui si può accedere attraverso una semplice
+dichiarazione del tipo:
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+extern char ** environ;
+\end{lstlisting}
+un esempio del contenuto dell'ambiente, in si è riportato un estratto delle
+variabili che normalmente sono definite dal sistema, è riportato in \nfig.
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=11cm]{img/environ_var}
+ \caption{Esempio di lista delle variabili di ambiente.}
+ \label{fig:proc_envirno_list}
+\end{figure}
+
+Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
+\textsl{\texttt{nome=valore}}. Inoltre alcune variabili, come quelle elencate
+in \curfig, sono definite dal sistema per essere usate da diversi programmi e
+funzioni: per queste c'è l'ulteriore convenzione di usare nomi espressi in
+caratteri maiuscoli.
+
+Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
+riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
+costituiscono un modo comodo per definire un comportamento specifico senza
+dover ricorrere all'uso di opzioni a linea di comando o di file di
+configurazione.
+
+La shell ad esempio ne usa molte per il suo funzionamento (come \var{PATH} per
+la ricerca dei comandi), e alcune di esse (come \var{HOME}, \var{USER}, etc.)
+sono definite al login. In genere è cura dell'amministratore definire le
+opportune variabili di ambiente in uno script di avvio. Alcune servono poi
+come riferimento generico per molti programmi (come \var{EDITOR} che indica
+l'editor preferito da invocare in caso di necessità).
+
+Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
+comuni), come riportato in \ntab. GNU/Linux le supporta tutte e ne definisce
+anche altre: per una lista più completa si può controllare \cmd{man environ}.
+
+\begin{table}[htb]
+ \centering
+ \begin{tabular}[c]{|l|c|c|c|p{7cm}|}
+ \hline
+ \textbf{Variabile} & \textbf{POSIX} & \textbf{XPG3}
+ & \textbf{Linux} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \macro{USER} & $\bullet$ & $\bullet$ & $\bullet$ & Nome utente\\
+ \macro{LOGNAME} & $\bullet$ & $\bullet$ & $\bullet$ & Nome utente\\
+ \macro{HOME} & $\bullet$ & $\bullet$ & $\bullet$ &
+ Directory base dell'utente\\
+ \macro{LANG} & $\bullet$ & $\bullet$ & $\bullet$ & Localizzazione\\
+ \macro{PATH} & $\bullet$ & $\bullet$ & $\bullet$ & Elenco delle directory
+ dei programmi\\
+ \macro{PWD} & $\bullet$ & $\bullet$ & $\bullet$ & Directory corrente\\
+ \macro{SHELL} & $\bullet$ & $\bullet$ & $\bullet$ & Shell in uso\\
+ \macro{TERM} & $\bullet$ & $\bullet$ & $\bullet$ & Tipo di terminale\\
+ \macro{PAGER} & $\bullet$ & $\bullet$ & $\bullet$ & Programma per vedere i
+ testi\\
+ \macro{EDITOR} & $\bullet$ & $\bullet$ & $\bullet$ & Editor di default\\
+ \macro{BROWSER} & $\bullet$ & $\bullet$ & $\bullet$ & Browser di default\\
+ \hline
+ \end{tabular}
+ \caption{Variabile di ambiente più comuni definite da vari standard}
+ \label{tab:proc_env_var}
+\end{table}
+
+Lo standard ANSI C, pur non entrando nelle specifiche di come sono strutturati
+i contenuti, definisce la funzione \func{getenv} che permette di ottenere i
+valori delle variabili di ambiente, il suo prototipo è:
+\begin{prototype}{stdlib.h}{char *getenv(const char *name)}
+ Esamina l'ambiente del processo cercando una stringa che corrisponda a
+ quella specificata da \param{name}.
+
+ \bodydesc{La funzione ritorna \macro{NULL} se non trova nulla, o il
+ puntatore alla stringa che corrisponde (di solito nella forma
+ \texttt{NOME=valore}).}
+\end{prototype}
+
+Oltre a questa funzione di lettura, che è l'unica definita dallo standard ANSI
+C, in seguito sono state proposte altre da utilizzare per settare e per
+cancellare le variabili di ambiente presenti; uno schema delle funzioni
+previste nei vari standard unix e disponibili in Linux è riportato in \ntab.
+
+\begin{table}[htb]
+ \centering
+ \begin{tabular}[c]{|l|c|c|c|c|c|c|}
+ \hline
+ \textbf{Funzione} & \textbf{ANSI C} & \textbf{POSIX.1} & \textbf{XPG3} &
+ \textbf{SVr4} & \textbf{BSD} & \textbf{Linux} \\
+ \hline
+ \hline
+ \func{getenv} & $\bullet$ & $\bullet$ & $\bullet$ &
+ $\bullet$ & $\bullet$ & $\bullet$ \\
+ \func{setenv} & & & &
+ & $\bullet$ & $\bullet$ \\
+ \func{unsetenv} & & & &
+ & $\bullet$ & $\bullet$ \\
+ \func{putenv} & & opz. & $\bullet$ &
+ & $\bullet$ & $\bullet$ \\
+ \func{clearenv} & & opz. & &
+ & & \\
+ \hline
+ \end{tabular}
+ \caption{Funzioni per la gestione delle variabili di ambiente.}
+ \label{tab:proc_env_func}
+\end{table}
+
+In Linux solo le prime quattro funzioni di \curtab\ sono definite; delle tre
+restanti le prime due, \func{putenv} e \func{setenv} servono per assegnare
+nuove variabili di ambiente, i loro prototipi sono i seguenti:
+\begin{functions}
+ \headdecl{stdlib.h}
+
+ \funcdecl{int putenv(char *string)} Aggiunge la stringa \param{string}
+ all'ambiente.
+
+ \funcdecl{int setenv(const char *name, const char *value, int overwrite)}
+ Setta la variabile di ambiente \param{name} al valore \param{value}.
+
+ \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 per un
+ errore, che è sempre \macro{ENOMEM}.}
+\end{functions}
+\noindent la terza è:
+\begin{functions}
+ \headdecl{stdlib.h}
+
+ \funcdecl{void unsetenv(const char *name)}
+ Rimuove la variabile di ambiente \param{name}.
+\end{functions}
+
+Per cancellare una variabile di ambiente si usa \func{unsetenv}, che elimina
+ogni occorrenza della variabile, se la variabile specificata non esiste non
+succede nulla, e non è previsto (dato che la funzione è \type{void}) nessuna
+segnalazione di errore.
+
+Per modificare o aggiungere una variabile di ambiente si possono usare le
+funzioni \func{setenv} e \func{putenv}. La prima permette di specificare
+separatamente nome e valore della variabile di ambiente, inoltre il valore di
+\param{overwrite} specifica il comportamento della funzione nel caso la
+variabile esista già, sovrascrivendola se diverso da zero, lasciandola
+immutata se uguale a zero.
+
+La seconda funzione prende come parametro una stringa analoga quella
+restituita da \func{getenv}, e sempre nella forma \texttt{NOME=valore}. Se la
+variabile specificata non esiste la stringa sarà aggiunta all'ambiente, se
+invece esiste il suo valore sarà settato a quello specificato da
+\func{string}. Si tenga presente che, seguendo lo standard SUSv2, le
+\acr{glibc} successive alla versione 2.1.2 aggiungono\footnote{il
+ comportamento è lo stesso delle vecchie \acr{libc4} e \acr{libc5}; nelle
+ \acr{glibc}, dalla versione 2.0 alla 2.1.1, veniva invece fatta una copia,
+ seguendo il comportamento di BSD4.4; dato che questo può dar luogo a perdite
+ di memoria e non rispetta lo standard il comportamento è stato modificato a
+ partire dalle 2.1.2, eliminando anche, sempre in conformità a SUSv2,
+ l'attributo \type{const} dal prototipo.} \func{string} alla lista delle
+variabili di ambiente; pertanto ogni cambiamento alla stringa in questione si
+riflette automaticamente sull'ambiente, e quindi si deve evitare di passare
+alla funzione variabili automatiche (per evitare i problemi esposti in
+\secref{sec:proc_auto_var}).
+
+Si tenga infine presente che se si passa a \func{putenv} solo il nome di una
+variabile (cioè \param{string} è nella forma \texttt{NAME} e non contiene un
+\var{=}) allora questa viene cancellata dall'ambiente. Infine se la chiamata
+di \func{putenv} comporta la necessità di allocare una nuova versione del
+vettore \var{environ} questo sarà allocato, ma la versione corrente sarà
+deallocata solo se anch'essa risultante da una allocazione fatta in precedenza
+da un'altra \func{putenv}, il vettore originale (in genere piazzato al di
+sopra dello stack, vedi \figref{fig:proc_mem_layout}), o la memoria associata
+alle variabili di ambiente eliminate non viene comunque liberata.
+
+
+\section{Problematiche di programmazione generica}
+\label{sec:proc_gen_prog}
+
+Benché questo non sia un libro di C, è opportuno affrontare alcune delle
+problematiche generali che possono emergere nella programmazione e di quali
+precauzioni o accorgimenti occorre prendere per risolverle. Queste
+problematiche non sono specifiche di sistemi unix-like o multitasking, ma
+avendo trattato in questo capitolo il comportamento dei processi visti come
+entità a se stanti, le riportiamo qui.
+
+
+\subsection{Il passaggio delle variabili e dei valori di ritorno}
+\label{sec:proc_var_passing}
+
+Una delle caratteristiche standard del C è che le variabili vengono passate
+alle subroutine attraverso un meccanismo che viene chiamato \textit{by value}
+(diverso ad esempio da quanto avviene con il Fortran, dove le variabili sono
+passate, come suol dirsi, \textit{by reference}, o dal C++ dove la modalità
+del passaggio può essere controllata con l'operatore \cmd{\&}).
+
+Il passaggio di una variabile \textit{by value} significa che in realtà quello
+che viene passato alla subroutine è una copia del valore attuale di quella
+variabile, copia che la subroutine potrà modificare a piacere, senza che il
+valore originale nella routine chiamante venga toccato. In questo modo non
+occorre preoccuparsi di eventuali effetti delle operazioni della subroutine
+sulla variabile passata come parametro.
+
+Questo però va inteso nella maniera corretta. Il passaggio \textit{by value}
+vale per qualunque variabile, puntatori compresi; quando però in una
+subroutine si usano dei puntatori (ad esempio per scrivere in un buffer) in
+realtà si va a modificare la zona di memoria a cui essi puntano, per cui anche
+se i puntatori sono copie, i dati a cui essi puntano sono sempre gli stessi, e
+le eventuali modifiche avranno effetto e saranno visibili anche nella routine
+chiamante.
+
+Nella maggior parte delle funzioni di libreria e delle system call i puntatori
+vengono usati per scambiare dati (attraverso buffer o strutture) e le
+variabili semplici vengono usate per specificare parametri; in genere le
+informazioni a riguardo dei risultati vengono passate alla routine chiamante
+attraverso il valore di ritorno. È buona norma seguire questa pratica anche
+nella programmazione normale.
+
+
+Talvolta però è necessario che la funzione possa restituire indietro alla
+funzione chiamante un valore relativo ad uno dei suoi parametri. Per far
+questo si usa il cosiddetto \textit{value result argument}, si passa cioè,
+invece di una normale variabile un puntatore; vedremo alcuni esempi di questa
+modalità nelle funzioni che gestiscono i socket (in
+\secref{sec:TCPel_functions}) in cui, per permettere al kernel di restituire
+informazioni sulle dimensioni delle strutture degli indirizzi utilizzate,
+viene usato questo meccanismo.
+
+
+\subsection{Il passaggio di un numero variabile di argomenti}
+\label{sec:proc_variadic}
+
+Come vedremo nei capitoli successivi, non sempre è possibile specificare
+un numero fisso di parametri per una funzione. Lo standard ISO C
+prevede la possibilità di definire delle \textit{varadic function} che
+abbiano un numero variabile di argomenti, ma non provvede nessun
+meccanismo con cui queste funzioni possono accedere a questi argomenti.
+
+(NdT il resto è da fare).
+
+\subsection{Potenziali problemi con le variabili automatiche}
+\label{sec:proc_auto_var}
+
+Uno dei possibili problemi che si possono avere con le subroutine è quello di
+restituire alla funzione chiamante dei dati che sono contenuti in una
+variabile automatica. Ovviamente quando la subroutine ritorna la sezione
+dello stack che conteneva la variabile automatica potrà essere riutilizzata da
+una nuova funzione, con le conseguenze immaginabili di sovrapposizione.
+
+Per questo una delle regole fondamentali della programmazione in C è che
+all'uscita di una funzione non deve restare nessun riferimento a variabili
+locali di quella funzione; qualora necessiti di utilizzare variabili che
+possano essere viste anche dalla funzione chiamante queste devono essere
+allocate esplicitamente, o in maniera statica (usando variabili di tipo
+\type{static} o \type{extern}), o dinamicamente con una delle funzioni della
+famiglia \func{malloc}.