+configurazione. É di norma cura della shell, quando esegue un comando, passare
+queste variabili al programma messo in esecuzione attraverso un uso opportuno
+delle relative chiamate (si veda sez.~\ref{sec:proc_exec}).
+
+La shell ad esempio ne usa molte per il suo funzionamento, come \envvar{PATH}
+per indicare la lista delle directory in cui effettuare la ricerca dei comandi
+o \envvar{PS1} per impostare il proprio \textit{prompt}. Alcune di esse, come
+\envvar{HOME}, \envvar{USER}, ecc. sono invece definite al login (per i
+dettagli si veda sez.~\ref{sec:sess_login}), ed in genere è cura della propria
+distribuzione definire le opportune variabili di ambiente in uno script di
+avvio. Alcune servono poi come riferimento generico per molti programmi, come
+\envvar{EDITOR} che indica l'editor preferito da invocare in caso di
+necessità. Una in particolare, \envvar{LANG}, serve a controllare la
+localizzazione del programma
+%(su cui torneremo in sez.~\ref{sec:proc_localization})
+per adattarlo alla lingua ed alle convezioni
+dei vari paesi.
+
+Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
+comuni), come riportato in tab.~\ref{tab:proc_env_var}. GNU/Linux le supporta
+tutte e ne definisce anche altre, in particolare poi alcune funzioni di
+libreria prevedono la presenza di specifiche variabili di ambiente che ne
+modificano il comportamento, come quelle usate per indicare una localizzazione
+e quelle per indicare un fuso orario; una lista più completa che comprende
+queste ed ulteriori variabili si può ottenere con il comando \cmd{man 7
+ environ}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|c|c|c|l|}
+ \hline
+ \textbf{Variabile} & \textbf{POSIX} & \textbf{XPG3}
+ & \textbf{Linux} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \texttt{USER} &$\bullet$&$\bullet$&$\bullet$& Nome utente.\\
+ \texttt{LOGNAME}&$\bullet$&$\bullet$&$\bullet$& Nome di login.\\
+ \texttt{HOME} &$\bullet$&$\bullet$&$\bullet$& Directory base
+ dell'utente.\\
+ \texttt{LANG} &$\bullet$&$\bullet$&$\bullet$& Localizzazione.\\
+ \texttt{PATH} &$\bullet$&$\bullet$&$\bullet$& Elenco delle directory
+ dei programmi.\\
+ \texttt{PWD} &$\bullet$&$\bullet$&$\bullet$& Directory corrente.\\
+ \texttt{SHELL} &$\bullet$&$\bullet$&$\bullet$& Shell in uso.\\
+ \texttt{TERM} &$\bullet$&$\bullet$&$\bullet$& Tipo di terminale.\\
+ \texttt{PAGER} &$\bullet$&$\bullet$&$\bullet$& Programma per vedere i
+ testi.\\
+ \texttt{EDITOR} &$\bullet$&$\bullet$&$\bullet$& Editor preferito.\\
+ \texttt{BROWSER}&$\bullet$&$\bullet$&$\bullet$& Browser preferito.\\
+ \texttt{TMPDIR} &$\bullet$&$\bullet$&$\bullet$& Directory dei file
+ temporanei.\\
+ \hline
+ \end{tabular}
+ \caption{Esempi delle variabili di ambiente più comuni definite da vari
+ standard.}
+ \label{tab:proc_env_var}
+\end{table}
+
+Lo standard ANSI C prevede l'esistenza di un ambiente, e pur non entrando
+nelle specifiche di come sono strutturati i contenuti, definisce la funzione
+\funcd{getenv} che permette di ottenere i valori delle variabili di ambiente;
+il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{char *getenv(const char *name)}
+\fdesc{Cerca una variabile di ambiente del processo.}
+}
+{La funzione ritorna il puntatore alla stringa contenente il valore della
+ variabile di ambiente in caso di successo e \val{NULL} per un errore.}
+\end{funcproto}
+
+La funzione effettua una ricerca nell'ambiente del processo cercando una
+variabile il cui nome corrisponda a quanto indicato con
+l'argomento \param{name}, ed in caso di successo ritorna il puntatore alla
+stringa che ne contiene il valore, nella forma ``\texttt{NOME=valore}''.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \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. & --
+ & -- & -- & $\bullet$ \\
+ \hline
+ \end{tabular}
+ \caption{Funzioni per la gestione delle variabili di ambiente.}
+ \label{tab:proc_env_func}
+\end{table}
+
+Oltre a questa funzione di lettura, che è l'unica definita dallo standard ANSI
+C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
+utilizzare per impostare, modificare e cancellare le variabili di
+ambiente. Uno schema delle funzioni previste nei vari standard e disponibili
+in Linux è riportato in tab.~\ref{tab:proc_env_func}. Tutte le funzioni sono
+state comunque inserite nello standard POSIX.1-2001, ad eccetto di
+\func{clearenv} che è stata rigettata.
+
+In Linux sono definite tutte le funzioni elencate in
+tab.~\ref{tab:proc_env_func},\footnote{in realtà nelle libc4 e libc5 sono
+ definite solo le prime quattro, \func{clearenv} è stata introdotta con la
+ \acr{glibc} 2.0.} anche se parte delle funzionalità sono ridondanti. La
+prima funzione di manipolazione che prenderemo in considerazione è
+\funcd{putenv}, che consente di aggiungere, modificare e cancellare una
+variabile di ambiente; il suo prototipo è:
+
+\begin{funcproto}{
+\fdecl{int putenv(char *string)}
+\fdesc{Inserisce, modifica o rimuove una variabile d'ambiente.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, che può
+ essere solo \errval{ENOMEM}.}
+\end{funcproto}
+
+La funzione prende come argomento una stringa analoga a quella restituita da
+\func{getenv} e sempre nella forma ``\texttt{NOME=valore}''. Se la variabile
+specificata (nel caso \texttt{NOME}) non esiste la stringa sarà aggiunta
+all'ambiente, se invece esiste il suo valore sarà impostato a quello
+specificato dal contenuto di \param{string} (nel caso \texttt{valore}). Se
+invece si passa come argomento solo il nome di una variabile di ambiente
+(cioè \param{string} è nella forma ``\texttt{NOME}'' e non contiene il
+carattere ``\texttt{=}'') allora questa, se presente nell'ambiente, verrà
+cancellata.
+
+Si tenga presente che, seguendo lo standard SUSv2, le \acr{glibc} successive
+alla versione 2.1.2 aggiungono direttamente \param{string} nella lista delle
+variabili di ambiente illustrata in fig.~\ref{fig:proc_envirno_list}
+sostituendo il relativo puntatore;\footnote{il comportamento è lo stesso delle
+ vecchie \acr{libc4} e \acr{libc5}; nella \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 dalla 2.1.2,
+ eliminando anche, sempre in conformità a SUSv2, l'attributo \direct{const}
+ dal prototipo.} pertanto ogni cambiamento alla stringa in questione si
+riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
+questa funzione una variabile automatica (per evitare i problemi esposti in
+sez.~\ref{sec:proc_var_passing}). Benché non sia richiesto dallo standard,
+nelle versioni della \acr{glibc} a partire dalla 2.1 la funzione è rientrante
+(vedi sez.~\ref{sec:proc_reentrant}).
+
+Infine quando una chiamata a \func{putenv} comporta la necessità di creare una
+nuova versione del vettore \var{environ} questo sarà allocato automaticamente,
+ma la versione corrente sarà deallocata solo se anch'essa è risultante da
+un'allocazione fatta in precedenza da un'altra \func{putenv}. Questo avviene
+perché il vettore delle variabili di ambiente iniziale, creato dalla chiamata
+ad \func{exec} (vedi sez.~\ref{sec:proc_exec}) è piazzato nella memoria al di
+sopra dello \textit{stack}, (vedi fig.~\ref{fig:proc_mem_layout}) e non nello
+\textit{heap} e quindi non può essere deallocato. Inoltre la memoria
+associata alle variabili di ambiente eliminate non viene liberata.
+
+Come alternativa a \func{putenv} si può usare la funzione \funcd{setenv} che
+però consente solo di aggiungere o modificare una variabile di ambiente; il
+suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{int setenv(const char *name, const char *value, int overwrite)}
+\fdesc{Inserisce o modifica una variabile di ambiente.}
+}
+{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{EINVAL}] \param{name} è \val{NULL} o una stringa di lunghezza
+ nulla o che contiene il carattere ``\texttt{=}''.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per aggiungere una nuova
+ variabile all'ambiente.
+\end{errlist}}
+\end{funcproto}
+
+La funzione consente di specificare separatamente nome e valore della
+variabile di ambiente da aggiungere negli argomenti \param{name}
+e \param{value}. Se la variabile è già presente nell'ambiente
+l'argomento \param{overwrite} specifica il comportamento della funzione, se
+diverso da zero sarà sovrascritta, se uguale a zero sarà lasciata immutata. A
+differenza di \func{putenv} la funzione esegue delle copie del contenuto degli
+argomenti \param{name} e \param{value} e non è necessario preoccuparsi di
+allocarli in maniera permanente.
+
+La cancellazione di una variabile di ambiente viene invece gestita
+esplicitamente con \funcd{unsetenv}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{int unsetenv(const char *name)}
+\fdesc{Rimuove una variabile di ambiente.}
+}
+{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{EINVAL}] \param{name} è \val{NULL} o una stringa di lunghezza
+ nulla o che contiene il carattere ``\texttt{=}''.
+\end{errlist}}
+\end{funcproto}
+
+La funzione richiede soltanto il nome della variabile di ambiente
+nell'argomento \param{name}, se la variabile non esiste la funzione ritorna
+comunque con un valore di successo.\footnote{questo con le versioni della
+ \acr{glibc} successive la 2.2.2, per le precedenti \func{unsetenv} era
+ definita come \texttt{void} e non restituiva nessuna informazione.}
+
+L'ultima funzione per la gestione dell'ambiente è
+\funcd{clearenv},\footnote{che come accennato è l'unica non presente nello
+ standard POSIX.1-2000, ed è disponibili solo per versioni della \acr{glibc}
+ a partire dalla 2.0; per poterla utilizzare occorre aver definito le macro
+ \macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE}.} che viene usata per
+cancellare completamente tutto l'ambiente; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{int clearenv(void)}
+\fdesc{Cancella tutto l'ambiente.}
+}
+{La funzione ritorna $0$ in caso di successo e un valore diverso da zero per
+ un errore.}
+\end{funcproto}
+
+In genere si usa questa funzione in maniera precauzionale per evitare i
+problemi di sicurezza connessi nel trasmettere ai programmi che si invocano un
+ambiente che può contenere dei dati non controllati, le cui variabili possono
+causare effetti indesiderati. Con l'uso della funzione si provvede alla
+cancellazione di tutto l'ambiente originale in modo da poterne costruirne una
+versione ``\textsl{sicura}'' da zero.
+
+\index{variabili!di~ambiente|)}
+
+
+% \subsection{La localizzazione}
+% \label{sec:proc_localization}
+
+% Abbiamo accennato in sez.~\ref{sec:proc_environ} come la variabile di ambiente
+% \envvar{LANG} sia usata per indicare ai processi il valore della cosiddetta
+% \textsl{localizzazione}. Si tratta di una funzionalità fornita dalle librerie
+% di sistema\footnote{prenderemo in esame soltanto il caso della \acr{glibc}.}
+% che consente di gestire in maniera automatica sia la lingua in cui vengono
+% stampati i vari messaggi (come i messaggi associati agli errori che vedremo in
+% sez.~\ref{sec:sys_strerror}) che le convenzioni usate nei vari paesi per una
+% serie di aspetti come il formato dell'ora, quello delle date, gli ordinamenti
+% alfabetici, le espressioni della valute, ecc.
+
+% Da finire.
+
+% La localizzazione di un programma si può selezionare con la
+
+% In realtà perché un programma sia effettivamente localizzato non è sufficiente
+
+% TODO trattare, quando ci sarà tempo, setlocale ed il resto
+
+
+%\subsection{Opzioni in formato esteso}
+%\label{sec:proc_opt_extended}
+
+%Oltre alla modalità ordinaria di gestione delle opzioni trattata in
+%sez.~\ref{sec:proc_opt_handling} la \acr{glibc} fornisce una modalità
+%alternativa costituita dalle cosiddette \textit{long-options}, che consente di
+%esprimere le opzioni in una forma più descrittiva che nel caso più generale è
+%qualcosa del tipo di ``\texttt{-{}-option-name=parameter}''.
+
+%(NdA: questa parte verrà inserita in seguito).
+
+% TODO opzioni in formato esteso
+
+% TODO trattare il vettore ausiliario e getauxval (vedi
+% http://lwn.net/Articles/519085/)
+
+
+\section{Problematiche di programmazione generica}
+\label{sec:proc_gen_prog}
+
+Benché questo non sia un libro sul linguaggio C, è opportuno affrontare alcune
+delle problematiche generali che possono emergere nella programmazione con
+questo linguaggio e di quali precauzioni o accorgimenti occorre prendere per
+risolverle. Queste problematiche non sono specifiche di sistemi unix-like o
+\textit{multitasking}, ma avendo trattato in questo capitolo il comportamento
+dei processi visti come entità a sé stanti, le riportiamo qui.
+
+
+\subsection{Il passaggio di variabili e valori di ritorno nelle funzioni}
+\label{sec:proc_var_passing}
+
+Una delle caratteristiche standard del C è che le variabili vengono passate
+alle funzioni che si invocano in un programma 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 funzione è una copia del valore attuale di quella
+variabile, copia che la funzione potrà modificare a piacere, senza che il
+valore originale nella funzione chiamante venga toccato. In questo modo non
+occorre preoccuparsi di eventuali effetti delle operazioni svolte nella
+funzione stessa sulla variabile passata come argomento.
+
+Questo però va inteso nella maniera corretta. Il passaggio \textit{by value}
+vale per qualunque variabile, puntatori compresi; quando però in una funzione
+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 saranno sempre gli stessi, e
+le eventuali modifiche avranno effetto e saranno visibili anche nella funzione
+chiamante.
+
+Nella maggior parte delle funzioni di libreria e delle \textit{system call} i
+puntatori vengono usati per scambiare dati (attraverso i buffer o le strutture
+a cui fanno riferimento) e le variabili normali vengono usate per specificare
+argomenti; in genere le informazioni a riguardo dei risultati vengono passate
+alla funzione chiamante attraverso il valore di ritorno. È buona norma
+seguire questa pratica anche nella programmazione normale.
+
+\itindbeg{value~result~argument}
+
+Talvolta però è necessario che la funzione possa restituire indietro alla
+funzione chiamante un valore relativo ad uno dei suoi argomenti usato anche in
+ingresso. Per far questo si usa il cosiddetto \textit{value result argument},
+si passa cioè, invece di una normale variabile, un puntatore alla stessa. Gli
+esempi di questa modalità di passaggio sono moltissimi, ad esempio essa viene
+usata nelle funzioni che gestiscono i socket (in
+sez.~\ref{sec:TCP_functions}), in cui, per permettere al kernel di restituire
+informazioni sulle dimensioni delle strutture degli indirizzi utilizzate,
+viene usato proprio questo meccanismo.
+
+Occorre tenere ben presente questa differenza, perché le variabili passate in
+maniera ordinaria, che vengono inserite nello \textit{stack}, cessano di
+esistere al ritorno di una funzione, ed ogni loro eventuale modifica
+all'interno della stessa sparisce con la conclusione della stessa, per poter
+passare delle informazioni occorre quindi usare un puntatore che faccia
+riferimento ad un indirizzo accessibile alla funzione chiamante.
+
+\itindend{value~result~argument}
+
+Questo requisito di accessibilità è fondamentale, infatti dei possibili
+problemi che si possono avere con il passaggio dei dati è quello di restituire
+alla funzione chiamante dei dati che sono contenuti in una variabile
+automatica. Ovviamente quando la funzione ritorna la sezione dello
+\textit{stack} che conteneva la variabile automatica (si ricordi quanto detto
+in sez.~\ref{sec:proc_mem_alloc}) verrà liberata automaticamente e potrà
+essere riutilizzata all'invocazione di un'altra funzione, con le immaginabili
+conseguenze, quasi invariabilmente catastrofiche, di sovrapposizione e
+sovrascrittura dei dati.
+
+Per questo una delle regole fondamentali della programmazione in C è che
+all'uscita di una funzione non deve restare nessun riferimento alle sue
+variabili locali. Qualora sia necessario utilizzare delle variabili che devono
+essere viste anche dalla funzione chiamante queste devono essere allocate
+esplicitamente, o in maniera statica usando variabili globali o dichiarate
+come \direct{extern},\footnote{la direttiva \direct{extern} informa il
+ compilatore che la variabile che si è dichiarata in una funzione non è da
+ considerarsi locale, ma globale, e per questo allocata staticamente e
+ visibile da tutte le funzioni dello stesso programma.} o dinamicamente con
+una delle funzioni della famiglia \func{malloc}, passando opportunamente il
+relativo puntatore fra le funzioni.
+
+
+\subsection{Il passaggio di un numero variabile di argomenti}
+\label{sec:proc_variadic}
+
+\index{funzioni!\textit{variadic}|(}
+
+Come vedremo nei capitoli successivi, non sempre è possibile specificare un
+numero fisso di argomenti per una funzione. Lo standard ISO C prevede nella
+sua sintassi la possibilità di definire delle \textit{variadic function} che
+abbiano un numero variabile di argomenti, attraverso l'uso nella dichiarazione
+della funzione dello speciale costrutto ``\texttt{...}'', che viene chiamato
+\textit{ellipsis}.
+
+Lo standard però non provvede a livello di linguaggio alcun meccanismo con cui
+dette funzioni possono accedere ai loro argomenti. L'accesso viene pertanto
+realizzato a livello della libreria standard del C che fornisce gli strumenti
+adeguati. L'uso di una \textit{variadic function} prevede quindi tre punti:
+\begin{itemize*}
+\item \textsl{dichiarare} la funzione come \textit{variadic} usando un
+ prototipo che contenga una \textit{ellipsis};
+\item \textsl{definire} la funzione come \textit{variadic} usando la stessa
+ \textit{ellipsis}, ed utilizzare le apposite macro che consentono la
+ gestione di un numero variabile di argomenti;
+\item \textsl{invocare} la funzione specificando prima gli argomenti fissi, ed
+ a seguire quelli addizionali.
+\end{itemize*}
+
+Lo standard ISO C prevede che una \textit{variadic function} abbia sempre
+almeno un argomento fisso. Prima di effettuare la dichiarazione deve essere
+incluso l'apposito \textit{header file} \headfile{stdarg.h}; un esempio di
+dichiarazione è il prototipo della funzione \func{execl} che vedremo in
+sez.~\ref{sec:proc_exec}:
+\includecodesnip{listati/exec_sample.c}
+in questo caso la funzione prende due argomenti fissi ed un numero variabile
+di altri argomenti, che andranno a costituire gli elementi successivi al primo
+del vettore \param{argv} passato al nuovo processo. Lo standard ISO C richiede
+inoltre che l'ultimo degli argomenti fissi sia di tipo
+\textit{self-promoting}\footnote{il linguaggio C prevede che quando si
+ mescolano vari tipi di dati, alcuni di essi possano essere \textsl{promossi}
+ per compatibilità; ad esempio i tipi \ctyp{float} vengono convertiti
+ automaticamente a \ctyp{double} ed i \ctyp{char} e gli \ctyp{short} ad
+ \ctyp{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
+ a sé stesso.} il che esclude vettori, puntatori a funzioni e interi di tipo
+\ctyp{char} o \ctyp{short} (con segno o meno). Una restrizione ulteriore di
+alcuni compilatori è di non dichiarare l'ultimo argomento fisso come variabile
+di tipo \direct{register}.\footnote{la direttiva \direct{register} del
+ compilatore chiede che la variabile dichiarata tale sia mantenuta, nei
+ limiti del possibile, all'interno di un registro del processore; questa
+ direttiva è originaria dell'epoca dai primi compilatori, quando stava al
+ programmatore scrivere codice ottimizzato, riservando esplicitamente alle
+ variabili più usate l'uso dei registri del processore, oggi questa direttiva
+ è in disuso pressoché completo dato che tutti i compilatori sono normalmente
+ in grado di valutare con maggior efficacia degli stessi programmatori quando
+ sia il caso di eseguire questa ottimizzazione.}
+
+Una volta dichiarata la funzione il secondo passo è accedere ai vari argomenti
+quando la si va a definire. Gli argomenti fissi infatti hanno un loro nome, ma
+quelli variabili vengono indicati in maniera generica dalla
+\textit{ellipsis}. L'unica modalità in cui essi possono essere recuperati è
+pertanto quella sequenziale, in cui vengono estratti dallo \textit{stack}
+secondo l'ordine in cui sono stati scritti nel prototipo della funzione.
+
+\macrobeg{va\_start}
+
+Per fare questo in \headfile{stdarg.h} sono definite delle macro specifiche,
+previste dallo standard ISO C89, che consentono di eseguire questa operazione.
+La prima di queste macro è \macro{va\_start}, che inizializza opportunamente
+una lista degli argomenti, la sua definizione è:
+
+{\centering
+\begin{funcbox}{
+\fhead{stdarg.h}
+\fdecl{void va\_start(va\_list ap, last)}
+\fdesc{Inizializza una lista degli argomenti di una funzione
+ \textit{variadic}.}
+}
+\end{funcbox}}
+
+La macro inizializza il puntatore alla lista di argomenti \param{ap} che deve
+essere una apposita variabile di tipo \type{va\_list}; il
+parametro \param{last} deve indicare il nome dell'ultimo degli argomenti fissi
+dichiarati nel prototipo della funzione \textit{variadic}.
+
+\macrobeg{va\_arg}
+
+La seconda macro di gestione delle liste di argomenti di una funzione
+\textit{variadic} è \macro{va\_arg}, che restituisce in successione un
+argomento della lista; la sua definizione è:
+
+{\centering
+\begin{funcbox}{
+\fhead{stdarg.h}
+\fdecl{type va\_arg(va\_list ap, type)}
+\fdesc{Restituisce il valore del successivo argomento opzionale.}
+}
+\end{funcbox}}
+
+La macro restituisce il valore di un argomento, modificando opportunamente la
+lista \param{ap} perché una chiamata successiva restituisca l'argomento
+seguente. La macro richiede che si specifichi il tipo dell'argomento che si
+andrà ad estrarre attraverso il parametro \param{type} che sarà anche il tipo
+del valore da essa restituito. Si ricordi che il tipo deve essere
+\textit{self-promoting}.
+
+In generale è perfettamente legittimo richiedere meno argomenti di quelli che
+potrebbero essere stati effettivamente forniti, per cui nella esecuzione delle
+\macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
+saranno ignorati. Se invece si richiedono più argomenti di quelli
+effettivamente forniti si otterranno dei valori indefiniti. Si avranno
+risultati indefiniti anche quando si chiama \macro{va\_arg} specificando un
+tipo che non corrisponde a quello usato per il corrispondente argomento.
+
+\macrobeg{va\_end}
+
+Infine una volta completata l'estrazione occorre indicare che si sono concluse
+le operazioni con la macro \macrod{va\_end}, la cui definizione è:
+
+{\centering
+\begin{funcbox}{
+\fhead{stdarg.h}
+\fdecl{void va\_end(va\_list ap)}
+\fdesc{Conclude l'estrazione degli argomenti di una funzione
+ \textit{variadic}.}
+}
+\end{funcbox}}
+
+Dopo l'uso di \macro{va\_end} la variabile \param{ap} diventa indefinita e
+successive chiamate a \macro{va\_arg} non funzioneranno. Nel caso del
+\cmd{gcc} l'uso di \macro{va\_end} può risultare inutile, ma è comunque
+necessario usarla per chiarezza del codice, per compatibilità con diverse
+implementazioni e per eventuali modifiche future a questo comportamento.
+
+Riassumendo la procedura da seguire per effettuare l'estrazione degli
+argomenti di una funzione \textit{variadic} è la seguente:
+\begin{enumerate*}
+\item inizializzare una lista degli argomenti attraverso la macro
+ \macro{va\_start};
+\item accedere agli argomenti con chiamate successive alla macro
+ \macro{va\_arg}: la prima chiamata restituirà il primo argomento, la seconda
+ il secondo e così via;
+\item dichiarare la conclusione dell'estrazione degli argomenti invocando la
+ macro \macro{va\_end}.
+\end{enumerate*}
+
+Si tenga presente che si possono usare anche più liste degli argomenti,
+ciascuna di esse andrà inizializzata con \macro{va\_start} e letta con
+\macro{va\_arg}, e ciascuna potrà essere usata per scandire la lista degli
+argomenti in modo indipendente. Infine ciascuna scansione dovrà essere
+terminata con \macro{va\_end}.
+
+Un limite di queste macro è che i passi 1) e 3) devono essere eseguiti nel
+corpo principale della funzione, il passo 2) invece può essere eseguito anche
+in un'altra funzione, passandole lista degli argomenti \param{ap}. In questo
+caso però al ritorno della funzione \macro{va\_arg} non può più essere usata
+(anche se non si era completata l'estrazione) dato che il valore di \param{ap}
+risulterebbe indefinito.
+
+\macroend{va\_start}
+\macroend{va\_arg}
+\macroend{va\_end}
+
+Esistono dei casi in cui è necessario eseguire più volte la scansione degli
+argomenti e poter memorizzare una posizione durante la stessa. In questo caso
+sembrerebbe naturale copiarsi la lista degli argomenti \param{ap} con una
+semplice assegnazione ad un'altra variabile dello stesso tipo. Dato che una
+delle realizzazioni più comuni di \type{va\_list} è quella di un puntatore
+nello \textit{stack} all'indirizzo dove sono stati salvati gli argomenti, è
+assolutamente normale pensare di poter effettuare questa operazione.
+
+\index{tipo!opaco|(}
+
+In generale però possono esistere anche realizzazioni diverse, ed è per questo
+motivo che invece che un semplice puntatore, \typed{va\_list} è quello che
+viene chiamato un \textsl{tipo opaco}. Si chiamano così quei tipi di dati, in
+genere usati da una libreria, la cui struttura interna non deve essere vista
+dal programma chiamante (da cui deriva il nome opaco) che li devono utilizzare
+solo attraverso dalle opportune funzioni di gestione.
+
+\index{tipo!opaco|)}
+
+Per questo motivo una variabile di tipo \typed{va\_list} non può essere
+assegnata direttamente ad un'altra variabile dello stesso tipo, ma lo standard
+ISO C99\footnote{alcuni sistemi che non hanno questa macro provvedono al suo
+ posto \macrod{\_\_va\_copy} che era il nome proposto in una bozza dello
+ standard.} ha previsto una macro ulteriore che permette di eseguire la
+copia di una lista degli argomenti:
+
+{\centering
+\begin{funcbox}{
+\fhead{stdarg.h}
+\fdecl{void va\_copy(va\_list dest, va\_list src)}
+\fdesc{Copia la lista degli argomenti di una funzione \textit{variadic}.}
+}
+\end{funcbox}}
+
+La macro copia l'attuale della lista degli argomenti \param{src} su una nuova
+lista \param{dest}. Anche in questo caso è buona norma chiudere ogni
+esecuzione di una \macrod{va\_copy} con una corrispondente \macro{va\_end} sul
+nuovo puntatore alla lista degli argomenti.
+
+La chiamata di una funzione con un numero variabile di argomenti, posto che la
+si sia dichiarata e definita come tale, non prevede nulla di particolare;
+l'invocazione è identica alle altre, con gli argomenti, sia quelli fissi che
+quelli opzionali, separati da virgole. Quello che però è necessario tenere
+presente è come verranno convertiti gli argomenti variabili.
+
+In Linux gli argomenti dello stesso tipo sono passati allo stesso modo, sia
+che siano fissi sia che siano opzionali (alcuni sistemi trattano diversamente
+gli opzionali), ma dato che il prototipo non può specificare il tipo degli
+argomenti opzionali, questi verranno sempre promossi, pertanto nella ricezione
+dei medesimi occorrerà tenerne conto (ad esempio un \ctyp{char} verrà visto da
+\macro{va\_arg} come \ctyp{int}).
+
+Un altro dei problemi che si devono affrontare con le funzioni con un numero
+variabile di argomenti è che non esiste un modo generico che permetta di
+stabilire quanti sono gli argomenti effettivamente passati in una chiamata.
+
+Esistono varie modalità per affrontare questo problema; una delle più
+immediate è quella di specificare il numero degli argomenti opzionali come uno
+degli argomenti fissi. Una variazione di questo metodo è l'uso di un argomento
+fisso per specificare anche il tipo degli argomenti variabili, come fa la
+stringa di formato per \func{printf} (vedi sez.~\ref{sec:file_formatted_io}).
+
+Infine una ulteriore modalità diversa, che può essere applicata solo quando il
+tipo degli argomenti lo rende possibile, è quella che prevede di usare un
+valore speciale per l'ultimo argomento, come fa ad esempio \func{execl} che
+usa un puntatore \val{NULL} per indicare la fine della lista degli argomenti
+(vedi sez.~\ref{sec:proc_exec}).
+
+\index{funzioni!\textit{variadic}|)}
+
+\subsection{Il controllo di flusso non locale}
+\label{sec:proc_longjmp}