+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 prevede l'esistenza di un ambiente, pur non entrando nelle
+specifiche di come sono strutturati i contenuti, e definisce la funzione
+\func{getenv} che permette di ottenere i valori delle variabili di ambiente,
+il cui 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
+ \cmd{NOME=valore}).}
+\end{prototype}
+
+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 settare e per cancellare le variabili di ambiente. Uno schema
+delle funzioni previste nei vari standard 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,
+\func{getenv} l'abbiamo già esaminata; 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 setenv(const char *name, const char *value, int overwrite)}
+ Setta la variabile di ambiente \param{name} al valore \param{value}.
+
+ \funcdecl{int putenv(char *string)} Aggiunge la stringa \param{string}
+ all'ambiente.
+
+ \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 per un
+ errore, che è sempre \macro{ENOMEM}.}
+\end{functions}
+\noindent la terza, \func{unsetenv}, serve a cancellare una variabile di
+ambiente; il suo prototipo è:
+\begin{functions}
+ \headdecl{stdlib.h}
+
+ \funcdecl{void unsetenv(const char *name)} Rimuove la variabile di ambiente
+ \param{name}.
+\end{functions}
+\noindent questa funzione elimina ogni occorrenza della variabile specificata;
+se essa non esiste non succede nulla. Non è prevista (dato che la funzione è
+\type{void}) nessuna segnalazione di errore.
+
+Per modificare o aggiungere una variabile di ambiente si possono usare sia
+\func{setenv} che \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 \var{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
+\param{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 a
+questa funzione una variabile automatica (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
+\texttt{=}) 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 alla stessa; 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 nella
+sua sintassi la possibilità di definire delle \textit{variadic function} che
+abbiano un numero variabile di argomenti, attraverso l'uso della
+\textit{ellipsis} \var{...} nella dichiarazione della funzione; ma non
+provvede a livello di linguaggio alcun meccanismo con cui dette funzioni
+possono accedere ai loro argomenti.
+
+L'accesso viene invece realizzato dalle librerie standard che provvedono gli
+strumenti adeguati. L'uso delle \textit{variadic function} prevede 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 lo stesso
+ \textit{ellipsis}, ed utilizzare le apposite macro che consentono la
+ gestione di un numero variabile di argomenti.
+\item \textsl{Chiamare} la funzione specificando prima gli argomenti fissi, e
+ a seguire gli 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 header file \file{stdarg.h}; un esempio di dichiarazione è
+il prototipo della funzione \func{execl} che vedremo in
+\secref{sec:proc_exec}:
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+ int execl(const char *path, const char *arg, ...);
+\end{lstlisting}
+in questo caso la funzione prende due parametri fissi ed un numero variabile
+di altri parametri (che verranno a costituire gli elementi successivi al primo
+del vettore \var{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 \type{float} vengono convertiti
+ automaticamente a \type{double} ed i \type{char} e gli \type{short} ad
+ \type{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
+ a se stesso.} il che esclude array, puntatori a funzioni e interi di tipo
+\type{char} o \type{short} (con segno o meno). Una ulteriore restrizione di
+alcuni compilatori è di non dichiarare l'ultimo parametro fisso come
+\type{register}.
+
+Una volta dichiarata la funzione il secondo passo è accedere ai vari parametri
+quando la si va a definire. I parametri fissi infatti hanno un loro nome, ma
+quelli variabili vengono indicati in maniera generica dalla ellipsis.
+
+L'unica modalità in cui essi possono essere recuperati è pertanto quella
+sequenziale; essi verranno estratti dallo stack secondo l'ordine in cui sono
+stati scritti. Per fare questo in \file{stdarg.h} sono definite delle apposite
+macro; la procedura da seguire è la seguente:
+\begin{enumerate*}
+\item Inizializzare un puntatore alla lista degli argomenti di tipo
+ \type{va\_list} attraverso la macro \macro{va\_start}.
+\item Accedere ai vari argomenti opzionali 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 dei parametri invocando la
+ macro \macro{va\_end}.
+\end{enumerate*}
+in generale è perfettamente legittimo richiedere meno argomenti di quelli che
+potrebbero essere stati effettivamente forniti, e nella esecuzione delle
+\macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
+saranno ignorati; se invece si richiedono più argomenti di quelli forniti si
+otterranno dei valori indefiniti. Nel caso del \cmd{gcc} poi l'uso della macro
+\macro{va\_end} è inutile, ma si consiglia di usarlo ugualmente per
+compatibilità.
+
+Le definizioni delle tre macro sono le seguenti:
+\begin{functions}
+ \headdecl{stdarg.h}
+
+ \funcdecl{void va\_start(va\_list ap, last)} Inizializza il puntatore alla
+ lista di argomenti \param{ap}; il parametro \param{last} \emph{deve} essere
+ l'ultimo dei parametri fissi.
+
+ \funcdecl{type va\_arg(va\_list ap, type)} Restituisce il valore del
+ successivo parametro opzionale, modificando opportunamente \param{ap}; la
+ macro richiede che si specifichi il tipo dell'argomento attraverso il
+ parametro \param{type} che deve essere il nome del tipo dell'argomento in
+ questione. Il tipo deve essere \textit{self-promoting}.
+
+ \funcdecl{void va\_end(va\_list ap)} Conclude l'uso di \param{ap}.
+\end{functions}
+
+In generale si possono avere più puntatori alla lista degli argomenti,
+ciascuno andrà inizializzato con \macro{va\_start} e letto con \macro{va\_arg}
+e ciascuno potrà scandire la lista degli argomenti per conto suo.
+
+Dopo l'uso di \macro{va\_end} la variabile \var{ap} diventa indefinita e
+successive chiamate a \macro{va\_arg} non funzioneranno. Si avranno risultati
+indefiniti anche chiamando \macro{va\_arg} specificando un tipo che non
+corrisponde a quello del parametro.
+
+Un altro limite delle macro è che i passi 1) e 3) devono essere eseguiti nel
+corpo principale della funzione, il passo 2) invece può essere eseguito anche
+in una subroutine passandole il puntatore alla lista di argomenti; in questo
+caso però si richiede che al ritorno della funzione il puntatore non venga più
+usato (lo standard richiederebbe la chiamata esplicita di \macro{va\_end}),
+dato che il valore di \var{ap} risulterebbe indefinito.
+
+Esistono dei casi in cui è necessario eseguire più volte la scansione dei
+parametri e poter memorizzare una posizione durante la stessa. La cosa più
+naturale in questo caso sembrerebbe quella di copiarsi il puntatore alla lista
+degli argomenti con una semplice assegnazione. Dato che una delle
+realizzazioni più comuni di \macro{va\_list} è quella di un puntatore nello
+stack all'indirizzo dove sono stati salvati i parametri, è assolutamente
+normale pensare di poter effettuare questa operazione.
+
+In generale però possono esistere anche realizzazioni diverse, per questo
+motivo \macro{va\_list} è definito come tipo opaco e non può essere assegnato
+direttamente ad un altra variabile dello stesso tipo. Per risolvere questo
+problema lo standard ISO C99\footnote{alcuni sistemi che non hanno questa
+ macro provvedono al suo posto \macro{\_\_va\_copy} che era il nome proposto
+ in una bozza dello standard} ha previsto una ulteriore macro che permette di
+eseguire la copia di un puntatore alla lista degli argomenti:
+\begin{prototype}{stdarg.h}{void va\_copy(va\_list dest, va\_list src)}
+ Copia l'attuale valore \param{src} del puntatore alla lista degli argomenti
+ su \param{dest}.
+\end{prototype}
+\noindent anche in questo caso è buona norma chiudere ogni esecuzione di una
+\macro{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 i parametri, 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 \type{char} verrà visto da
+\macro{va\_arg} come \type{int}).
+
+
+Uno 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 i parametri passati effettivamente 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 parametro
+per specificare anche il tipo degli argomenti (come fa la stringa di formato
+per \func{printf}).
+
+Una modalità diversa, che può essere applicata solo quando il tipo dei
+parametri lo rende possibile, è quella che prevede di usare un valore speciale
+come ultimo argomento (come fa ad esempio \func{execl} che usa un puntatore
+\macro{NULL} per indicare la fine della lista degli argomenti).
+
+
+\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 immaginabili conseguenze 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 variabili
+locali; qualora sia necessario 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}.
+
+\subsection{Il controllo di flusso non locale}
+\label{sec:proc_longjmp}
+
+Il controllo del flusso di un programma in genere viene effettuato con le
+varie istruzioni del linguaggio C, la più bistrattata delle quali è il
+\code{goto}, ampiamente deprecato in favore di costrutti più puliti; esiste
+però un caso in l'uso di questa istruzione porta all'implementazione più
+efficiente, quello dell'uscita in caso di errore.
+
+Il C però non consente di effettuare un salto ad una label definita in
+un'altra funzione, per cui se l'errore avviene in funzioni profondamente
+annidate occorre usare quello che viene chiamato un salto \textsl{non-locale};
+questo viene fatto usando salvando il contesto dello stack nel punto in cui si
+vuole tornare in caso di errore, e ripristinandolo quando l'occorrenza capita.
+
+
+La funzione che permette di salvare il contesto dello stack è \func{setjmp},
+il cui prototipo è:
+
+\begin{functions}
+ \headdecl{setjmp.h}
+ \funcdecl{void setjmp(jmp\_buf env)}
+
+ Salva il contesto dello stack in \param{env} per un successivo uso da parte
+ di \func{longjmp}. Il contesto viene invalidato se la routine che ha
+ chiamato \func{setjmp} ritorna.
+
+ \bodydesc{La funzione ritorna zero quando è chiamata direttamente e un
+ valore diverso da zero quando ritorna da una chiamata di \func{longjmp}
+ che usa il contesto salvato in precedenza.}
+\end{functions}