process.tex

   1 \chapter{L'interfaccia base con i processi}
   2 \label{cha:process_interface}
   3
   4 Come accennato nell'introduzione il processo è l'unità di base con cui un
   5 sistema unix alloca ed utilizza le risorse.  Questo capitolo tratterà
   6 l'interfaccia base fra il sistema e i processi, su come vengono passati i
   7 parametri, come viene gestita e allocata la memoria, su come un processo può
   8 richiedere servizi al sistema, su cosa deve fare quando ha finito la sua
   9 esecuzione. Nella sezione finale acceneremo ad alcune problematiche generiche
  10 di programmazione.
  11
  12 In genere un programma viene eseguito quando un processo lo fa partire
  13 eseguendo una funzione della famiglia \func{exec}; torneremo su questo e
  14 sulla la creazione e gestione dei processi nel prossimo capitolo, in questo
  15 affronteremo l'avvio e il funzionamento di un singolo processo partendo dal
  16 punto di vista del programma posto in esecuzione.
  17
  18
  19
  20 \section{Esecuzione e conclusione di un programma}
  21
  22 Una delle concetti base relativi ai processi è che un processo esegue sempre
  23 uno ed un solo programma: si possono avere più processi che eseguono lo stesso
  24 programma ma ciascun processo vedrà la sua copia del codice (in realtà il
  25 kernel fa si che tutte le parti uguali siano condivise) avrà un suo spazio di
  26 indirizzi, variabili proprie e sarà eseguito in maniera completamente
  27 indipendente da tutti gli altri.
  28
  29 Anche quando all'interno di un programma possono essere presenti più
  30 \textsl{filoni} di esecuzione (i cosiddetti \textit{thread}), o questo possa
  31 essere composto da moduli multipli completamente separati, quando questo sarà
  32 posto in esecuzione esso apparirà al sistema come un solo processo (il
  33 discorso dei \textit{thread} comunque in Linux necessita di una trattazione a
  34 parte per la peculiarità dell'implementazione).
  35
  36 \subsection{La funzione \func{main}}
  37 \label{sec:proc_main}
  38
  39 Quando un programma viene lanciato il kernel esegue una opportuna routine di
  40 avvio, usando il programma \cmd{ld-linux.so}, è questo programma che prima
  41 carica le librerie condivise che servono al programma, effettua il link
  42 dinamico del codice e poi alla fine lo esegue. Infatti, a meno di non aver
  43 specificato il flag \texttt{-static} durante la compilazione, tutti i
  44 programmi in Linux sono incompleti e necessitano di essere linkati alle
  45 librerie condivise quando vengono avviati.  La procedura è controllata da
  46 alcune variabili di ambiente e dal contenuto di \file{/etc/ld.so.conf}, i
  47 dettagli sono riportati nella man page di \cmd{ld.so}.
  48
  49 Il sistema fa partire qualunque programma chiamando la funzione \func{main};
  50 sta al programmatore chiamare così la funzione principale del programma da cui
  51 si suppone iniziale l'esecuzione; in ogni caso senza questa funzione lo stesso
  52 linker darebbe luogo ad errori.
  53
  54 Lo standard ISO C specifica che la funzione \func{main} può non avere
  55 argomenti o prendere due argomenti che rappresentano gli argomenti passati da
  56 linea di comando, in sostanza un prototipo che va sempre bene è il seguente:
  57 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
  58      int main (int argc, char *argv[])
  59 \end{lstlisting}
  60
  61 In realtà nei sistemi unix esiste un'altro modo per definire la funzione
  62 \func{main}, che prevede la presenza di un terzo parametro, \var{char
  63   *envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{sec:proc_environ})
  64 del programma; questa forma però non è prevista dallo standard POSIX.1 per cui
  65 se si vogliono scrivere programmi portabili è meglio evitarla.
  66
  67
  68 \subsection{Come chiudere un programma}
  69 \label{sec:proc_conclusion}
  70
  71 La via normale per la quale un programma finisce è quando la funzione
  72 \func{main} ritorna, una modalità equivalente di conclusione è quella di
  73 chiamare direttamente la funzione \func{exit} (che viene comunque chiamata
  74 dalla routine di avvio del programma quando la funzione \func{main} ritorna).
  75 Una forma alternativa è quella di chiamare direttamente la system call
  76 \func{\_exit} che passa il controllo direttamente al kernel.
  77
  78 Oltre alla conclusione ``normale'' esiste anche la possibilità di una
  79 conclusione ``anomala'' del programma a causa di segnali o della chiamata alla
  80 funzione \func{abort} (che comunque genera un segnale che termina il
  81 programma); torneremo su questo in \secref{sec:proc_termination}.
  82
  83 Il valore di ritorno della funzione main, o quello usato nelle chiamate ad
  84 \func{exit} e \func{\_exit}, viene chiamato \textit{exit status} e passato
  85 al processo padre che aveva lanciato il programma (in genere la shell). In
  86 generale si usa questo valore per fornire un'informazione generica sulla
  87 riuscita o il fallimento del programma; l'informazione è necessariamente
  88 generica, ed il valore deve essere compreso fra 0 e 255.
  89
  90 In generale si usa la convenzione di restituire 0 in caso di successo e 1 in
  91 caso di fallimento, i programmi che effettuano dei confronti (come
  92 \cmd{diff}) usano invece una notazione leggermente diversa, usando 0 per
  93 indicare la corrispondenza, 1 per indicare la non corrispondenza e 2 per
  94 indicare l'incapacità di effettuare il confronto. È opportuno adottare una di
  95 queste convenzioni a seconda dei casi. Si tenga presente che se si raggiunge
  96 la fine della funzione \func{main} senza ritornare esplicitamente si ha un
  97 valore di uscita indefinito, è pertanto consigliabile di concludere sempre in
  98 maniera esplicita detta funzione.
  99
 100 Una altra convenzione riserva i valori da 128 in su per usi speciali, ad
 101 esempio 128 viene usato per indicare l'incapacità di eseguire un altro
 102 programma in un sottoprocesso. Benché anche questa convenzione non sia
 103 universalmente seguita è una buona idea tenerne conto.
 104
 105 Si tenga presente inoltre che non è una buona idea usare il valore dell'errore
 106 restituito dalla variabile \var{errno} come stato di uscita, in generale
 107 una shell non si cura di tutto questo e comunque il valore dello stato di
 108 uscita è sempre troncato ad 8 bit, per cui si potrebbe incorrere nel caso in
 109 cui l'errore 256, diventando zero, verrebbe interpretato come un successo. In
 110 \file{stdlib.h} sono definite due macro \macro{EXIT\_SUCCESS} e
 111 \macro{EXIT\_FAILURE}, che in Linux sono poste rispettivamente ai valori 0 e
 112 1 (di tipo \type{int}), seguendo lo standard POSIX.
 113
 114 Infine occorre distinguere fra lo stato di uscita di un programma
 115 (l'\textit{exit status}) e lo stato di conclusione di un processo (il
 116 \textit{termination status}), abbiamo già accennato infatti che è comunque
 117 possibile un processo possa essere terminato (da un segnale) prima che il
 118 programma in esecuzione si sia concluso. In caso di conclusione normale del
 119 programma però lo stato di uscita diventa parte dello stato di conclusione del
 120 processo (vedi \secref{sec:proc_termination}).
 121
 122
 123 \subsection{Le funzioni \func{exit} e \func{\_exit}}
 124 \label{sec:proc_exit}
 125
 126 Come accennato funzioni per l'uscita ``normale'' da un programma sono due, la
 127 prima è la funzione \func{exit} che è definita dallo standard ANSI C; il
 128 prototipo della funzione è il seguente:
 129 \begin{prototype}{stdlib.h}{void exit(int status)}
 130   Causa la conclusione ordinaria del programma restituendo il valore
 131   \var{status} al processo padre.
 132
 133   La funzione non ritorna. Il processo viene terminato
 134 \end{prototype}
 135
 136 La funzione \func{exit} è pensata per una conclusione pulita di un programma
 137 che usa le librerie standard del C; essa esegue tutte le funzioni che sono
 138 state registrate con \func{atexit} e \func{on\_exit} (vedi
 139 \secref{sec:proc_atexit}), e chiude tutti gli stream di I/O effettuando il
 140 salvataggio dei dati sospesi (chiamando \func{fclose}, vedi
 141 \secref{sec:file_fclose}), infine ripassa il controllo al kernel chiamando
 142 \func{\_exit} e passando il valore \var{status} come stato di uscita.
 143
 144 La system call \func{\_exit} restituisce direttamente il controllo al
 145 kernel, concludendo immediatamente il processo, le eventuali funzioni
 146 registrate con \func{atexit} e \func{on\_exit} non vengono eseguite. Il
 147 prototipo della funzione è il seguente:
 148 \begin{prototype}{unistd.h}{void \_exit(int status)}
 149   Causa la conclusione immediata del programma restituendo il valore
 150   \var{status} al processo padre.
 151
 152   La funzione non ritorna. Il processo viene terminato.
 153 \end{prototype}
 154
 155 La funzione chiude tutti i file descriptor appartenenti al processo (sui tenga
 156 presente che questo non comporta il salvataggio dei dati bufferizzati degli
 157 stream), fa si che ogni figlio del processo sia ereditato da \cmd{init}
 158 (vedi \secref{cha:process_handling}), manda un segnale \macro{SIGCHLD} al
 159 processo padre (vedi \ref{sec:sig_job_control}) ed infine ritorna lo stato di
 160 uscita specificato in \var{status} che può essere raccolto usando la
 161 funzione \func{wait} (vedi \secref{sec:proc_wait}).
 162
 163
 164 \subsection{Le funzioni \func{atexit} e \func{on\_exit}}
 165 \label{sec:proc_atexit}
 166
 167 Come accennato l'uso di \func{exit} al posto della \func{\_exit} è fatto
 168 principalmente per permettere una uscita pulita dalle funzioni delle librerie
 169 standard del C (in particolare per quel che riguarda la chiusura degli
 170 stream).
 171
 172 Quando si realizza una libreria da usare in varie applicazioni può essere
 173 perciò utile evitare di richiedere di chiamare esplicitamente un funzione di
 174 uscita che esegua tutte le operazioni di pulizia prima di uscire (come quella
 175 di salvare eventuali dati sospesi). È invece molto meno soggetto ad errori e
 176 completamente trasparente all'utente poter effettuare una chiamata automatica
 177 di una funzione che effettui tali operazioni all'uscita dal programma.
 178
 179 A questo scopo lo standard ANSI C prevede la possibilità di registrare un
 180 certo numero funzioni che verranno eseguite all'uscita dal programma (sia per
 181 la chiamata ad \func{exit} che per il ritorno di \func{main}). La prima
 182 funzione che si può utilizzare a tal fine è:
 183 \begin{prototype}{stdlib.h}{void atexit(void (*function)(void))}
 184   Registra la funzione \var{function} per essere chiamata all'uscita dal
 185   programma.
 186
 187   La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
 188   \texttt{errno} non viene settata.
 189 \end{prototype}
 190
 191 La funzione richiede come argomento l'indirizzo della opportuna da chiamare
 192 all'uscita che non deve prendere argomenti e non deve ritornare niente. Una
 193 estensione di \func{atexit} è la funzione \func{on\_exit} (che la glibc
 194 include per compatibilità con SunOS e che non è detto sia definita su altri
 195 sistemi), il cui prototipo è:
 196 \begin{prototype}{stdlib.h}
 197 {void on\_exit(void (*function)(int status, void *arg), void *arg)}
 198   Registra la funzione \var{function} per essere chiamata all'uscita dal
 199   programma. Tutte le funzioni registrate vengono chiamate in ordine inverso
 200   rispetto a quello di registrazione.
 201
 202   La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
 203   \var{errno} non viene settata.
 204 \end{prototype}
 205
 206 In questo caso la funzione da chiamare prende due parametri, il primo dei
 207 quali sarà inizializzato allo stato di uscita con cui è stata chiamata
 208 \func{exit} ed il secondo al puntatore generico specificato come secondo
 209 argomento nella chiamata di \func{on\_exit}.
 210
 211 Nella sequenza di chiusura tutte le funzioni registrate verranno chiamate in
 212 ordine inverso rispetto a quello di registrazione (ed una stessa funzione
 213 registrata più volte sarà chiamata più volte); poi verranno chiusi tutti gli
 214 stream aperti, infine verrà chiamata \func{\_exit}.
 215
 216
 217 \subsection{Conclusioni}
 218 \label{sec:proc_term_conclusion}
 219
 220 Data l'importanza dell'argomento è opportuno sottolineare ancora una volta che
 221 in un sistema unix l'unico modo in cui un programma può essere eseguito dal
 222 kernel è attraverso la chiamata alla system call \func{execve} (in genere
 223 attraverso una delle funzioni \func{exec} che vedremo in
 224 \secref{sec:proc_exec}).
 225
 226 Allo stesso modo l'unico modo in cui un programma può concludere
 227 volontariamente la sua esecuzione è attraverso una chiamata alla system call
 228 \func{\_exit} sia esplicitamente o che in maniera indiretta attraverso l'uso
 229 di \func{exit} o il ritorno della funzione \func{main}.
 230
 231 Lo schema delle modalità con cui si avvia e conclude normalmente un programma
 232 è riportato in \nfig.
 233
 234 \begin{figure}[htb]
 235   \centering
 236
 237   \caption{Schema dell'avvio e della conclusione di un programma.}
 238   \label{fig:proc_prog_start_stop}
 239 \end{figure}
 240
 241 Si ricordi infine che un programma può anche essere interrotto dall'esterno
 242 attraverso l'uso di un segnale (modalità di conclusione non mostrata in
 243 \curfig); torneremo su questo aspetto in \secref{cha:signals}.
 244
 245
 246
 247 \section{I processi e l'uso della memoria}
 248 \label{sec:proc_memory}
 249
 250 Una delle risorse base che ciascun processo ha a disposizione è la memoria, ed
 251 uno degli aspetti più complessi di un sistema unix (ed in particolar modo di
 252 Linux) è appunto la gestione della memoria. Qui ci occuperemo però di come la
 253 memoria viene vista dal punto di vista di un programma in esecuzione in un
 254 processo.
 255
 256
 257 \subsection{I concetti generali}
 258 \label{sec:proc_mem_gen}
 259
 260 Ci sono vari modi in cui i vari sistemi organizzano la memoria (ed i dettagli
 261 di basso livello dipendono in maniera diretta dall'architettura
 262 dell'hardware), ma quello più tipico, usato da unix (e da Linux) è quello di
 263 assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare in
 264 cui gli indirizzi vanno da zero ad un qualche valore massimo (nel caso di
 265 Linux fino al kernel 2.2 detto massimo era per macchine a 32bit di 2Gb, con il
 266 kernel 2.4 il limite è stato esteso).
 267
 268 Come accennato nell'introduzione questo spazio di indirizzi è virtuale e non
 269 corrisponde all'effettiva posizione dei dati nella RAM del computer; in genere
 270 detto spazio non è neanche continuo (cioè non tutti gli indirizzi sono
 271 utilizzabili e/o utilizzati).
 272
 273 La memoria virtuale viene divisa in pagine di dimensione fissa (che ad esempio
 274 sono di 4kb su macchine a 32 bit e 8kb sulle alpha, valori strettamente
 275 connessi all'hardware di gestione della memoria), e ciascuna pagina della
 276 memoria virtuale è associata ad un supporto che può essere una pagina di
 277 memoria reale o ad un dispositivo di stoccaggio secondario (in genere lo
 278 spazio disco riservato alla swap, o i file che contengono il codice).
 279
 280 Lo stesso pezzo di memoria reale (o di spazio disco) può fare da supporto a
 281 diverse pagine di memoria virtuale appartenenti a processi diversi (come
 282 accade in genere per le pagine che contengono il codice delle librerie
 283 condivise). Ad esempio il codice della funzione \func{printf} starà su una
 284 sola pagina di memoria reale che farà da supporto a tutte le pagine di memoria
 285 virtuale di tutti i processi hanno detta funzione nel loro codice.
 286
 287 La corrispondenza fra le pagine della memoria virtuale e quelle della memoria
 288 fisica della macchina viene gestita in maniera trasparente dall'hardware di
 289 gestione della memoria (la \textit{Memory Management Unit} del processore),
 290 ma poiché in genere quest'ultima è solo una piccola frazione della memoria
 291 virtuale è necessario un meccanismo che permetta di trasferire le pagine
 292 virtuali che servono dal supporto su cui si trovano in memoria, eliminando
 293 quelle che non servono. Questo meccanismo è detto \textit{paging}, ed è uno
 294 dei compiti principali del kernel.
 295
 296 Quando un processo cerca di accedere ad una pagina che non è nella memoria
 297 reale, avviene quello che viene chiamato un \textit{page fault}; l'hardware di
 298 gestione della memoria (la MMU del processore) genera una interruzione e passa
 299 il controllo al kernel il quale sospende il processo e si incarica di mettere
 300 in RAM la pagina richiesta (effettuando tutte le operazioni necessarie per
 301 reperire lo spazio necessario), per poi restituire il controllo al
 302 processo.
 303
 304 Dal punto di vista di un processo questo meccanismo è completamente
 305 trasparente e tutto avviene come se tutte le pagine fossero sempre disponibili
 306 in memoria.  L'unica differenza avvertibile è quella dei tempi di esecuzione,
 307 che passano dai pochi nanosecondi necessari per l'accesso a tempi molto più
 308 lunghi, dovuti all'intervento del kernel. Normalmente questo è il prezzo da
 309 pagare per avere un multitasking reale, ed in genere il sistema è molto
 310 efficiente in questo lavoro; quando però ci siano esigenze specifiche di
 311 prestazioni è possibile usare delle funzioni che permettono di bloccare il
 312 meccanismo del paging e mantenere fisse delle pagine in memoria (vedi
 313 \ref{sec:proc_mem_lock}).
 314
 315
 316 \subsection{La struttura della memoria di un processo}
 317 \label{sec:proc_mem_layout}
 318
 319 Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
 320 una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
 321 tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
 322 commette quando si è manipolato male un puntatore e genera quello che viene
 323 chiamato un \textit{segmentation fault}. Se si tenta cioè di leggere o
 324 scrivere da un indirizzo per il quale non esiste una associazione della pagina
 325 virtuale il kernel risponde al relativo \textit{page fault}, mandando un
 326 segnale \macro{SIGSEGV} al processo, che normalmente ne causa la terminazione
 327 immediata.
 328
 329 È pertanto importante capire come viene strutturata la memoria virtuale di un
 330 processo; essa viene divisa in \textsl{segmenti}, cioè un insieme contiguo di
 331 indirizzi virtuali ai quali il processo può accedere. Solitamente un
 332 programma C viene suddiviso nei seguenti segmenti:
 333
 334 \begin{enumerate}
 335 \item Il segmento di testo (\textit{text segment}). Contiene il codice
 336   macchina del programma e le costanti statiche. Normalmente viene condiviso,
 337   in modo che più processi (anche diversi nel caso di librerie) possano
 338   utilizzarlo, e viene marcato in sola lettura per evitare sovrascritture
 339   accidentali (o maliziose) che ne modifichino le istruzioni.
 340
 341   Viene allocato da \func{exec} all'avvio del programma e resta invariato
 342   per tutto il tempo dell'esecuzione.
 343
 344 \item Il segmento dei dati (\textit{data segment}). Contiene le variabili
 345   globali (cioè quelle definite al di fuori di tutte le funzioni). Di norma è
 346   diviso in due parti.
 347
 348   La prima parte è il segmento dei dati inizializzati, che contiene le
 349   variabili globali il cui valore è stato assegnato esplicitamente. Ad esempio
 350   se si definisce:
 351 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
 352     double pi = 3.14;
 353 \end{lstlisting}
 354   questo valore sarà immagazzinato in questo segmento. La memoria di questo
 355   segmento viene preallocato dalla \func{exec} e inizializzata ai valori
 356   specificati.
 357
 358   La seconda parte è il segmento dei dati non inizializzati, che contiene le
 359   variabili globali il cui valore è stato non è assegnato esplicitamente. Ad
 360   esempio se si definisce:
 361 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
 362     int vect[100];
 363 \end{lstlisting}
 364   questo valore sarà immagazzinato in questo segmento. Anch'esso viene
 365   allocato all'avvio, e tutte le variabili vengono inizializzate a
 366   zero (ed i puntatori a \macro{NULL}).
 367
 368   Storicamente questo segmento viene chiamato BBS (da \textit{block started by
 369     symbol}. La sua dimensione è fissa.
 370
 371 \item Lo \textit{heap}. Tecnicamente lo si può considerare l'estensione del
 372   segmento dati, a cui di solito è posto giusto di seguito. È qui che avviene
 373   l'allocazione dinamica della memoria; può essere ridimensionato allocando e
 374   disallocando la memoria dinamica con le apposite funzioni (vedi
 375   \secref{sec:proc_mem_alloc}), ma il suo limite inferiore (quello adiacente
 376   al segmento dati) ha una posizione fissa.
 377
 378 \item Il segmento di \textit{stack}, che contiene lo \textit{stack} del
 379   programma.  Tutte le volte che si effettua una chiamata ad una funzione è
 380   qui che viene salvato l'indirizzo di ritorno e le informazioni dello stato
 381   del chiamante (tipo il contenuto di alcuni registri della CPU); poi la
 382   funzione chiamata alloca qui lo spazio per le sue variabili locali, in
 383   questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
 384   della funzione lo spazio è automaticamente rilasciato.
 385
 386   La dimensione di questo segmento aumenta seguendo la crescita dello stack
 387   del programma, ma non viene ridotta quando quest'ultimo si restringe.
 388 \end{enumerate}
 389
 390 \begin{figure}[htb]
 391   \centering
 392   \includegraphics[width=5cm]{img/memory_layout.eps}
 393   \caption{Disposizione tipica dei segmenti di memoria di un processo}
 394   \label{fig:proc_mem_layout}
 395 \end{figure}
 396
 397 Una disposizione tipica di questi segmenti è riportata in \nfig. Usando il
 398 comando \cmd{size} su un programma se ne può stampare le dimensioni dei
 399 segmenti di testo e di dati (inizializzati e BSS); il BSS però non è mai
 400 salvato sul file, in quanto viene inizializzato a zero al caricamento del
 401 programma.
 402
 403
 404 \subsection{Allocazione della memoria per i programmi C}
 405 \label{sec:proc_mem_alloc}
 406
 407 Il C supporta due tipi di allocazione della memoria, l'allocazione statica è
 408 quella in cui vanno le variabili globali e le variabili statiche (e viene
 409 effettuata nel segmento dei dati), lo spazio per queste variabili viene
 410 allocati all'avvio del programma (come parte delle operazioni svolte da
 411 \func{exec}) e non viene liberato fino alla sua conclusione.
 412
 413 L'allocazione automatica è quella che avviene per le cosiddette variabili
 414 automatiche, cioè gli argomenti delle funzioni o le variabili locali. Lo
 415 spazio per queste variabili viene allocato nello stack quando viene eseguito
 416 comando di invocazione della funzione e liberato quando si esce dalla
 417 medesima.
 418
 419 Esiste però un terzo tipo di allocazione, che non è prevista dal linguaggio C,
 420 che è l'allocazione dinamica della memoria, necessaria quando il quantitativo
 421 di memoria che serve è determinabile solo in corso di esecuzione del
 422 programma.
 423
 424 Il C non consente di usare variabili allocate dinamicamente, non è possibile
 425 cioè definire in fase di programmazione una variabile le cui dimensioni
 426 possano essere modificate durante l'esecuzione del programma; però le librerie
 427 del C forniscono una serie opportuna di funzioni per permettere l'allocazione
 428 dinamica di spazio in memoria (in genere nello heap, usando la system call
 429 \func{sbrk}), solo che a questo punto detto spazio sarà accessibile solo in
 430 maniera indiretta attraverso dei puntatori.
 431
 432
 433 \subsection{Le funzioni \func{malloc}, \func{calloc}, \func{realloc} e
 434   \func{free}}
 435 \label{sec:proc_mem_malloc}
 436
 437 Le funzioni previste dallo standard ANSI C per la gestione della memoria sono
 438 quattro, i prototipi sono i seguenti:
 439 \begin{functions}
 440 \headdecl{stdlib.h}
 441 \funcdecl{void *calloc(size\_t size)}
 442   Alloca \var{size} byte nello heap. La memoria viene inizializzata a 0.
 443
 444   La funzione restituisce il puntatore alla zona di memoria allocata in caso
 445   di successo e \macro{NULL} in caso di fallimento, nel qual caso
 446   \var{errno} viene settata a \macro{ENOMEM}.
 447 \funcdecl{void *malloc(size\_t size)}
 448   Alloca \var{size} byte nello heap. La memoria non viene inizializzata.
 449
 450   La funzione restituisce il puntatore alla zona di memoria allocata in caso
 451   di successo e \macro{NULL} in caso di fallimento, nel qual caso
 452   \var{errno} viene settata a \macro{ENOMEM}.
 453 \funcdecl{void *realloc(void *ptr, size\_t size)}
 454   Cambia la dimensione del blocco allocato all'indirizzo \var{ptr}
 455   portandola a \var{size}.
 456
 457   La funzione restituisce il puntatore alla zona di memoria allocata in caso
 458   di successo e \macro{NULL} in caso di fallimento, nel qual caso
 459   \var{errno} viene settata a \macro{ENOMEM}.
 460 \funcdecl{void free(void *ptr)}
 461   Disalloca lo spazio di memoria puntato da \var{ptr}.
 462
 463   La funzione non ritorna nulla.
 464 \end{functions}
 465 Il puntatore che le funzioni di allocazione ritornano è garantito essere
 466 sempre correttamente allineato per tutti i tipi di dati; ad esempio sulle
 467 macchine a 32 bit in genere è allineato a multipli di 4 byte e sulle macchine
 468 a 64 bit a multipli di 8 byte.
 469
 470 In genere su usano le funzioni \func{malloc} e \func{calloc} per allocare
 471 dinamicamente la memoria necessaria al programma, siccome i puntatori
 472 ritornati sono di tipo generico non è necessario effettuare un cast per
 473 assegnarli a puntatori al tipo di variabile per la quale si effettua la
 474 allocazione.
 475
 476 La memoria allocata dinamicamente deve essere esplicitamente rilasciata usando
 477 \func{free}\footnote{le glibc provvedono anche una funzione \func{cfree}
 478   definita per compatibilità con SunOS, che è deprecata} una volta che non
 479 sia più necessaria. Questa funzione vuole come parametro un puntatore
 480 restituito da una precedente chiamata a una qualunque delle funzioni di
 481 allocazione e che non sia già stato liberato da un'altra chiamata a
 482 \func{free}, in caso contrario il comportamento della funzione è indefinito.
 483
 484 La funzione \func{realloc} si usa invece per cambiare (in genere aumentare)
 485 la dimensione di un'area di memoria precedentemente allocata, la funzione
 486 vuole in ingresso il puntatore restituito dalla precedente chiamata ad una
 487 \func{malloc} (se è passato un valore \macro{NULL} allora la funzione si
 488 comporta come \func{malloc}\footnote{questo è vero per Linux e
 489   l'implementazione secondo lo standard ANSI C, ma non è vero per alcune
 490   vecchie implementazioni, inoltre alcune versioni delle librerie del C
 491   consentivano di usare \func{realloc} anche per un puntatore liberato con
 492   \func{free} purché non ci fossero state altre chiamate a funzioni di
 493   allocazione, questa funzionalità è totalmente deprecata e non è consentita
 494   sotto Linux}), ad esempio quando si deve far crescere la dimensione di un
 495 vettore; in questo caso se è disponibile dello spazio adiacente al precedente
 496 la funzione lo utilizza, altrimenti rialloca altrove un blocco della dimensione
 497 voluta copiandoci automaticamente il contenuto, lo spazio in più non viene
 498 inizializzato.
 499
 500 Il fatto che il blocco di memoria restituito da \func{realloc} possa
 501 cambiare comporta che si deve sempre riassegnare al puntatore passato per il
 502 ridimensionamento il valore di ritorno della funzione, e che non ci devono
 503 essere altri puntatori che puntino all'interno di un'area che si vuole
 504 ridimensionare.
 505
 506 Uno degli errori più comuni (specie se si ha a che fare con array di
 507 puntatori) è infatti quello di chiamare \func{free} più di una volta sullo
 508 stesso puntatore; per evitare questo problema una soluzione di ripiego è
 509 quella di assegnare sempre a \macro{NULL} ogni puntatore liberato con
 510 \func{free}, dato che, quando il parametro è un puntatore nullo,
 511 \func{free} non esegue nessuna operazione.
 512
 513 Linux e le glibc hanno una implementazione delle routine di allocazione che è
 514 controllabile dall'utente attraverso alcune variabili di ambiente, in
 515 particolare diventa possibile tracciare questo tipo di errori usando la
 516 variabile \macro{MALLOC\_CHECK\_} che quando viene settata mette in uso una
 517 versione meno efficiente delle funzioni, che però è più tollerante nei
 518 confronti di piccoli errori come quello di chiamate doppie a \func{free}; in
 519 particolare:
 520 \begin{itemize*}
 521 \item se la variabile è posta a zero gli errori vengono ignorati.
 522 \item se è posta ad 1 viene stampato un avviso sullo \textit{standard error}
 523   (vedi \secref{sec:file_stdfiles}).
 524 \item se è posta a 2 viene chiamata \func{abort}, che in genere causa
 525   l'immediata conclusione del programma.
 526 \end{itemize*}
 527
 528 Il problema più comune e più difficile da tracciare che si incontra con
 529 l'allocazione della memoria è però quando la memoria non più utilizzata non
 530 viene opportunamente liberata (quello che in inglese viene chiamato
 531 \textit{memory-leak}, traducibile come \textsl{perdita di memoria}).
 532
 533 Un caso tipico è quando l'allocazione viene fatta da una subroutine per un uso
 534 locale, ma la memoria non viene liberata una volta usata; chiamate ripetute
 535 alla stessa subroutine causeranno a lungo andare un esaurimento della memoria
 536 disponibile, con un conseguente crash dell'applicazione che può avvenire in
 537 qualunque momento, e senza nessuna relazione con la subroutine che contiene
 538 l'errore.
 539
 540 Per questo motivo l'implementazione delle routine di allocazione delle glibc
 541 mette a disposizione una serie di funzionalità (su cui torneremo in
 542 \secref{sec:xxx_advanced}) che permettono di tracciare le allocazioni e
 543 le disallocazione, e definisce anche una serie di possibili agganci che
 544 permettono di sostituire alle funzioni di libreria una propria versione (che
 545 può essere più o meno specializzata per il debugging).
 546
 547
 548 \subsection{La funzione \texttt{alloca}}
 549 \label{sec:proc_mem_alloca}
 550
 551 Una alternativa possibile all'uso di \texttt{malloc}, che non soffre del tipo
 552 di problemi di memory leak descritti in precedenza è la funzione
 553 \texttt{alloca} che invece che allocare la memoria nello heap usa lo il
 554 segmento di stack della funzione corrente. La sintassi è identica:
 555 \begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
 556   Alloca \texttt{size} byte nel segmento di stack della funzione chiamante.
 557   La memoria non viene inizializzata.
 558
 559   La funzione restituisce il puntatore alla zona di memoria allocata in caso
 560   di successo e \texttt{NULL} in caso di fallimento, nel qual caso
 561   \texttt{errno} viene settata a \texttt{ENOMEM}.
 562 \end{prototype}
 563 ma in questo caso non è più necessario liberare la memoria in quanto questa
 564 viene rilasciata automaticamente al ritorno della funzione.
 565
 566 Come è evidente questa funzione ha molti vantaggi, e permette di evitare i
 567 problemi di memory leak non essendo più necessaria la deallocazione esplicita;
 568 una delle ragioni principali per usarla è però che funziona anche quando si
 569 usa \func{longjump} per uscire con un salto non locale da una funzione (vedi
 570 \secref{sec:proc_longjmp}),
 571
 572 Un altro vantaggio e che in Linux la funzione è molto veloce e non viene
 573 sprecato spazio, infatti non è necessario gestire un pool di memoria da
 574 riservare e si evitano anche problemi di frammentazione.
 575
 576 Gli svantaggi sono che la funzione non è disponibile su tutti gli unix, quando
 577 non è possibile aumentare le dimensioni dello stack una volta chiamata una
 578 funzione e quindi l'uso limita la portabilità dei programmi, inoltre se si
 579 cerca di allocare troppa memoria non si ottiene un messaggio di errore, ma un
 580 segnale di \textit{segment violation} analogo a quello che si avrebbe da una
 581 ricorsione infinita.
 582
 583 Inoltre non è chiaramente possibile usare questa funzione per allocare memoria
 584 che deve poi essere usata anche al di fuori della funzione in cui questa viene
 585 chiamata, in quanto all'uscita dalla funzione lo spazio allocato diventerebbe
 586 libero, e potrebbe essere sovrascritto all'invocazione di nuove funzioni con
 587 conseguenze imprevedibili.
 588
 589 Questo è lo stesso problema potenziale che si può avere con le variabili
 590 automatiche; un errore comune infatti è quello di restituire al chiamante un
 591 puntatore ad una di queste variabili, che sarà automaticamente distrutta
 592 all'uscita della funzione, con gli stessi problemi appena citati per
 593 \func{alloca}.
 594
 595 \subsection{Le funzioni \func{brk} e \func{sbrk}}
 596 \label{sec:proc_mem_sbrk}
 597
 598 L'uso di queste funzioni è necessario solo quando si voglia accedere alle
 599 analoghe system call a cui fanno da interfaccia (ad esempio per implementare
 600 una propria versione di \func{malloc}. Le  funzione sono:
 601 \begin{prototype}{unistd.h}{int *brk(void end\_data\_segment)}
 602   Sposta la fine del segmento dei dati all'indirizzo specificato da
 603   \var{end\_data\_segment}.
 604
 605   La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
 606   nel qual caso \var{errno} viene settata a \macro{ENOMEM}.
 607 \end{prototype}
 608 \begin{prototype}{unistd.h}{int *sbrk(ptrdiff\_t increment)}
 609   Incrementa lo spazio dati di un programma di \var{increment}. Un valore
 610   zero restituisce l'attuale posizione della fine del segmento dati.
 611
 612   La funzione restituisce il puntatore all'inizio della nuova zona di memoria
 613   allocata in caso di successo e \macro{NULL} in caso di fallimento, nel qual
 614   caso \macro{errno} viene settata a \macro{ENOMEM}.
 615 \end{prototype}
 616
 617 Queste funzioni sono state deliberatamente escluse dallo standard POSIX.1 e
 618 per i programmi normali è opportuno usare le funzioni di allocazione standard
 619 descritte in precedenza, che sono costruite su di esse.  In genere si usa
 620 \func{sbrk} con un valore zero per ottenere l'attuale posizione della fine
 621 del segmento dati.
 622
 623
 624 % \subsection{La personalizzazione delle funzioni di allocazione}
 625 % \label{sec:proc_mem_malloc_custom}
 626
 627
 628 \subsection{Il controllo della memoria virtuale}
 629 \label{sec:proc_mem_lock}
 630
 631 Come spiegato in \secref{sec:proc_mem_gen} il kernel gestisce la memoria in
 632 maniera trasparente ai processi, decidendo quando rimuovere pagine dalla
 633 memoria per metterle nello swap sulla base dell'utilizzo corrente da parte dei
 634 vari processi.
 635
 636 Nell'uso comune un processo non deve preoccuparsi di tutto ciò in quanto il
 637 meccanismo della paginazione riporta in RAM, ed in maniera trasparente, tutte
 638 le pagine che gli occorrono; esistono però esigenze particolari in cui non si
 639 vuole che il meccanismo dello \textit{swapping}, in generale i motivi per cui
 640 si possono avere queste necessità sono sostanzialmente due:
 641 \begin{itemize}
 642 \item La velocità. Il processo della paginazione è trasparente solo se il
 643   programma in esecuzione se non è sensibile al tempo che occorre a riportare
 644   la pagina in memoria; per questo motivi processi critici che hanno esigenze
 645   di tempo reale o tolleranze critiche nella risposte (ad esempio processi che
 646   trattano campionamenti sonori) possono non essere in grado di sopportare
 647   le variazioni della velocità di accesso dovuta alla paginazione.
 648
 649   In certi casi poi un programmatore può conoscere meglio dell'algoritmo di
 650   allocazione delle pagine le esigenze specifiche del suo programma e decidere
 651   quali pagine di memoria è opportuno che restino in memoria per un aumento
 652   delle prestazioni. In genere queste sono esigenze particolari e richiedono
 653   anche un aumento delle priorità in esecuzione (vedi \secref{sec:xxx_xxx}).
 654
 655 \item La sicurezza. Se si tengono password o chiavi in memoria queste possono
 656   essere portate su disco dal meccanismo della paginazione, questo rende più
 657   lungo il periodo di tempo in cui i segreti sono presenti in chiaro, e
 658   complessa la loro cancellazione (in genere è possibile cancellare della RAM
 659   ma altrettanto non vale per il disco su cui la pagina contenente i segreti
 660   può essere stata salvata). Per questo motivo programmi di crittografia
 661   richiedono il blocco di alcune pagine di memoria.
 662 \end{itemize}
 663
 664 Il meccanismo che previene la paginazione di parte della memoria virtuale di
 665 un processo è chiamato \textit{memory locking} (blocco della memoria), il
 666 blocco è sempre associato alle pagine della memoria virtuale del processo, non
 667 con il segmento reale di RAM su cui essa viene mantenuta.
 668
 669 La regola è che se un segmento di RAM fa da supporto ad almeno una pagina
 670 bloccata allora esso viene escluso dal meccanismo della paginazione. I blocchi
 671 non si accumulano, se si blocca due volte la stessa pagina non è necessario
 672 sbloccarla due volte, una pagina o è bloccata o no.
 673
 674 Il \textit{memory lock} persiste fintanto che il processo che detiene la
 675 memoria bloccata non la sblocca. Chiaramente la terminazione del processo
 676 comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
 677 tutti i \textit{memory lock}.
 678
 679 I \textit{memory lock} non sono ereditati dai processi figli\footnote{ma
 680   siccome Linux usa il copy on write gli indirizzi virtuali del figlio sono
 681   mantenuti sullo stesso segmento di RAM del padre, quindi fintanto che un
 682   figlio non scrive su un segmento, può usufruire dei memory lock del padre}.
 683 Siccome la presenza di \textit{memory lock} ha un impatto sugli altri processi
 684 solo l'amministratore ha la capacità di bloccare una pagina; ogni processo
 685 però può sbloccare le sue pagine. Il sistema pone dei limiti all'ammontare di
 686 memoria di un processo che può essere bloccata e al totale di memoria fisica
 687 che può dedicare a questo.
 688
 689 Le funzioni per bloccare e sbloccare singole sezioni di memoria sono
 690 \func{mlock} e \func{munlock}; i loro prototipi sono:
 691
 692 \begin{functions}
 693 \headdecl{stdlib.h}
 694 \funcdecl{void *calloc(size\_t size)}
 695   Alloca \var{size} byte nello heap. La memoria viene inizializzata a 0.
 696
 697   La funzione restituisce il puntatore alla zona di memoria allocata in caso
 698   di successo e \macro{NULL} in caso di fallimento, nel qual caso
 699   \var{errno} viene settata a \macro{ENOMEM}.
 700 \funcdecl{void *malloc(size\_t size)}
 701   Alloca \var{size} byte nello heap. La memoria non viene inizializzata.
 702
 703   La funzione restituisce il puntatore alla zona di memoria allocata in caso
 704   di successo e \macro{NULL} in caso di fallimento, nel qual caso
 705   \var{errno} viene settata a \macro{ENOMEM}.
 706 \funcdecl{void *realloc(void *ptr, size\_t size)}
 707   Cambia la dimensione del blocco allocato all'indirizzo \var{ptr}
 708   portandola a \var{size}.
 709
 710   La funzione restituisce il puntatore alla zona di memoria allocata in caso
 711   di successo e \macro{NULL} in caso di fallimento, nel qual caso
 712   \var{errno} viene settata a \macro{ENOMEM}.
 713 \funcdecl{void free(void *ptr)}
 714   Disalloca lo spazio di memoria puntato da \var{ptr}.
 715
 716   La funzione non ritorna nulla.
 717 \end{functions}
 718
 719
 720
 721
 722
 723 \section{La gestione di parametri e opzioni}
 724 \label{sec:proc_options}
 725
 726 Il passaggio dei parametri e delle variabili di ambiente dalla riga di comando
 727 al singolo programma quando viene lanciato è effettuato attraverso le
 728 variabili \var{argc}, \var{argv} che vengono passate al programma
 729 come argomenti della funzione principale.
 730
 731 \subsection{Il formato dei parametri}
 732 \label{sec:proc_par_format}
 733 In genere passaggio dei parametri al programma viene effettuato dalla shell,
 734 che si incarica di leggere la linea di comando e di effettuarne la scansione
 735 (il cosiddetto \textit{parsing}) per individuare le parole che la compongono,
 736 ciascuna delle quali viene considerata un parametro; di default per
 737 individuare le parole viene usato come separatore lo spazio (comportamento
 738 modificabile attraverso il settaggio della variabile di ambiente IFS).
 739
 740 Nella scansione viene costruito il vettore di puntatori \var{argv} inserendo
 741 in successione il puntatore alla stringa costituente l'$n$-simo parametro; la
 742 variabile \var{argc} viene inizializzata al numero di parametri trovati, in
 743 questo modo il primo parametro è sempre il nome del programma (vedi \nfig).
 744
 745 \subsection{La gestione delle opzioni}
 746 \label{sec:proc_opt_handling}
 747
 748 In generale un programma unix riceve da linea di comando sia gli argomenti che
 749 le opzioni, queste ultime sono standardizzate per essere riconosciute come
 750 tali: un elemento di \var{argv} che inizia con \texttt{-} e che non sia un
 751 singolo \texttt{-} o \texttt{--} viene considerato un'opzione.  In in genere
 752 le opzioni sono costituite da una lettera preceduta dal meno e possono avere o
 753 no un parametro associato; un comando tipico può essere cioè qualcosa del
 754 tipo:
 755 \begin{verbatim}
 756 touch -r riferimento.txt -m questofile.txt
 757 \end{verbatim}
 758 ed in questo caso le opzioni sono \texttt{m} ed \texttt{r}.
 759
 760 Per gestire le opzioni all'interno dei argomenti a linea di comando passati in
 761 \func{argv} le librerie standard del C forniscono la funzione \func{getopt}
 762 che ha il seguente prototipo:
 763 \begin{prototype}{unistd.h}
 764 {int getopt(int argc, char * const argv[], const char * optstring)}
 765 La funzione esegue il parsing degli argomenti passati da linea di comando
 766 riconoscendo le possibili opzioni segnalate con \var{optstring}.
 767
 768 Ritorna il carattere che segue l'opzione, \cmd{':'} se manca un parametro
 769 all'opzione, \cmd{'?'} se l'opzione è sconosciuta, e -1 se non esistono altre
 770 opzioni.
 771 \end{prototype}
 772
 773 Questa funzione prende come argomenti le due variabili \var{argc} e \var{argv}
 774 passate a \func{main} (vedi \secref{sec:proc_main}) ed una stringa che indica
 775 quali sono le opzioni valide; la funzione effettua la scansione della lista
 776 degli argomenti ricercando ogni stringa che comincia con \cmd{-} e ritorna ogni
 777 volta che trova una opzione valida.
 778
 779 La stringa \var{optstring} indica quali sono le opzioni riconosciute ed è
 780 costituita da tutti i caratteri usati per identificare le singole opzioni, se
 781 l'opzione ha un parametro al carattere deve essere fatto seguire un segno di
 782 due punti \var{':'}, nel caso appena accennato ad esempio la stringa di
 783 opzioni sarebbe \var{"r:m"}.
 784
 785 La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
 786 funzione all'interno di un ciclo fintanto che essa non ritorna il valore -1
 787 che indica che non ci sono più opzioni. Nel caso si incontri un'opzione non
 788 dichiarata in \var{optstring} viene ritornato il carattere \texttt{'?'}
 789 mentre se un opzione che lo richiede non è seguita da un parametro viene
 790 ritornato il carattere \texttt{':'}, infine se viene incontrato il valore
 791 \cmd{--} la scansione viene considerata conclusa, anche se vi sono altri
 792 elementi di \var{argv} che cominciano con il carattere \texttt{'-'}.
 793
 794 \begin{figure}[htbp]
 795   \footnotesize
 796     \begin{lstlisting}{}
 797     opterr = 0;  /* don't want writing to stderr */
 798     while ( (i = getopt(argc, argv, "hp:c:e:")) != -1) {
 799         switch (i) {
 800         /*
 801          * Handling options
 802          */
 803         case 'h':   /* help option */
 804             printf("Wrong -h option use\n");
 805             usage();
 806             return -1;
 807             break;
 808         case 'c':   /* take wait time for childen */
 809             wait_child = strtol(optarg, NULL, 10);    /* convert input */
 810             break;
 811         case 'p':   /* take wait time for childen */
 812             wait_parent = strtol(optarg, NULL, 10);   /* convert input */
 813             break;
 814         case 'e':   /* take wait before parent exit */
 815             wait_end = strtol(optarg, NULL, 10);      /* convert input */
 816             break;
 817         case '?':   /* unrecognized options */
 818             printf("Unrecognized options -%c\n",optopt);
 819             usage();
 820         default:    /* should not reached */
 821             usage();
 822         }
 823     }
 824     debug("Optind %d, argc %d\n",optind,argc);
 825   \end{lstlisting}
 826   \caption{Esempio di codice per la gestione delle opzioni.}
 827   \label{fig:proc_options_code}
 828 \end{figure}
 829
 830 Quando la funzione trova un'opzione essa ritorna il valore numerico del
 831 carattere, in questo modo si possono prendere le azioni relative usando uno
 832 \func{switch}; la funzione inizializza inoltre alcune variabili globali:
 833 \begin{itemize*}
 834 \item \var{char * optarg} contiene il puntatore alla stringa parametro
 835   dell'opzione.
 836 \item \var{int optind} alla fine della scansione restituisce l'indice del
 837   primo elemento di \var{argv} che non è un'opzione.
 838 \item \var{int opterr} previene, se posto a zero, la stampa di un messaggio
 839   di errore in caso di riconoscimento di opzioni non definite.
 840 \item \var{int optopt} contiene il carattere dell'opzione non riconosciuta.
 841 \end{itemize*}
 842
 843 In \figref{fig:proc_options_code} è mostrata la sezione del programma
 844 \file{ForkTest.c} (che useremo nel prossimo capitolo per effettuare dei test
 845 sulla creazione dei processi) deputata alla decodifica delle opzioni a riga di
 846 comando.
 847
 848 Anzitutto si può notare che si è anzitutto (\texttt{\small 1}) disabilitata la
 849 stampa di messaggi di errore per opzioni non riconosciute, per poi passare al
 850 ciclo per la verifica delle opzioni (\texttt{\small 2-27}); per ciascuna delle
 851 opioni possibili si è poi provveduto ad una opportuna azione, ad esempio per
 852 le tre opzioni che prevedono un parametro si è effettuata la decodifica del
 853 medesimo, il cui indirizzo è contenuto nella variabile \var{optarg},
 854 avvalorando la relativa variabile (\texttt{\small 12-14}, \texttt{\small
 855   15-17} e \texttt{\small 18-20}). Completato il ciclo troveremo in
 856 \var{optind} l'indice in \var{argv[]} del primo degli argomenti a linea di
 857 comando restanti.
 858
 859 Normalmente \func{getopt} compie una permutazione degli elementi di \var{argv}
 860 così che alla fine della scansione gli elementi che non sono opzioni sono
 861 spostati in coda al vettore. Oltre a questa esistono altre due modalità di
 862 gestire gli elementi di \var{argv}; se \var{optstring} inizia con il carattere
 863 \texttt{'+'} (o è settata la variabile di ambiente \macro{POSIXLY\_CORRECT})
 864 la scansione viene fermata non appena si incontra un elemento che non è
 865 un'opzione. L'ultima modalità, usata quando un programma può gestire la
 866 mescolanza fra opzioni e argomenti, ma se li aspetta in un ordine definito, si
 867 attiva quando \var{optstring} inizia con il carattere \texttt{'-'}. In questo
 868 caso ogni elemento che non è un'opzione viene considerato comunque un'opzione
 869 e associato ad un valore di ritorno pari ad 1, questo permette di identificare
 870 gli elementi che non sono opzioni, ma non effettua il riordinamento del
 871 vettore \var{argv}.
 872
 873
 874 \subsection{Opzioni in formato esteso}
 875 \label{sec:proc_opt_extended}
 876
 877 Un'estensione di questo schema è costituito dalle cosiddette
 878 \textit{long-options} espresse nella forma \cmd{--option=parameter}, anche la
 879 gestione di queste ultime è stata standardizzata attraverso l'uso di una
 880 versione estesa di \func{getopt}.
 881
 882 (NdA: da finire).
 883
 884
 885 \subsection{Le variabili di ambiente}
 886 \label{sec:proc_environ}
 887
 888 Oltre agli argomenti passati a linea di comando ogni processo riceve dal
 889 sistema un \textsl{ambiente}, nella forma di una lista di variabili
 890 (\textit{environment list}) messa a disposizione dal processo, e costruita
 891 nella chiamata alla funzione \func{exec} quando questo viene lanciato.
 892
 893 Come per la lista dei parametri anche questa lista è un array di puntatori a
 894 caratteri, ciascuno dei quali punta ad una stringa (terminata da un
 895 \macro{NULL}). A differenza di \var{argv[]} però in questo caso non si ha una
 896 lunghezza dell'array data da un equivalente di \var{argc}, ma la lista è
 897 terminata da un puntatore nullo.
 898
 899 L'indirizzo della lista delle variabili di ambiente è passato attraverso la
 900 variabile globale \var{environ}, a cui si può accedere attraverso una semplice
 901 dichiarazione del tipo:
 902 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
 903 extern char ** environ;
 904 \end{lstlisting}
 905 un esempio del contenuto dell'ambiente, in si è riportato un estratto delle
 906 variabili che normalmente sono definite dal sistema, è riportato in \nfig.
 907 \begin{figure}[htb]
 908   \centering
 909   \includegraphics[width=11cm]{img/environ_var.eps}
 910   \caption{Esempio di lista delle variabili di ambiente.}
 911   \label{fig:proc_envirno_list}
 912 \end{figure}
 913
 914 Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
 915 \textsl{\texttt{nome=valore}}. Inoltre alcune variabili, come quelle elencate
 916 in \curfig, sono definite dal sistema per essere usate da diversi programmi e
 917 funzioni: per queste c'è l'ulteriore convezione di usare nomi espressi in
 918 caratteri maiuscoli.
 919
 920 Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
 921 riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
 922 costituiscono un modo comodo per definire un comportamento specifico senza
 923 dover ricorrere all'uso di opzioni a linea di comando o di file di
 924 configurazione.
 925
 926 La shell ad esempio ne usa molte per il suo funzionamento (come \var{PATH} per
 927 la ricerca dei comandi), e alcune di esse (come \var{HOME}, \var{USER}, etc.)
 928 sono definite al login. In genere è cura dell'amministratore definire le
 929 opportune variabili di ambiente in uno script di avvio. Alcune servono poi
 930 come riferimento generico per molti programmi (come \var{EDITOR} che indica
 931 l'editor preferito da invocare in caso di necessità).
 932
 933 Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
 934 comuni), come riportato in \ntab. GNU/Linux le supporta tutte e ne definisce
 935 anche altre: per una lista parziale si può controllare \cmd{man environ}.
 936
 937
 938
 939
 940 \section{Problematiche di programmazione generica}
 941 \label{sec:proc_gen_prog}
 942
 943 Benché questo non sia un libro di C, è opportuno affrontare alcune delle
 944 problematiche generali che possono emergere nella programmazione e di quali
 945 precauzioni o accorgimenti occorre prendere per risolverle. Queste
 946 problematiche non sono specifiche di sistemi unix-like o multitasking, ma
 947 avendo trattato in questo capitolo il comportamento dei processi visti come
 948 entità a se stanti, le riportiamo qui.
 949
 950
 951 \subsection{Il passaggio delle variabili e dei valori di ritorno}
 952 \label{sec:proc_var_passing}
 953
 954 Una delle caratteristiche standard del C è che le variabili vengono passate
 955 alle subroutine attraverso un meccanismo che viene chiamato \textit{by value}
 956 (diverso ad esempio da quanto avviene con il Fortran, dove le variabli sono
 957 passate, come suol dirsi, \textit{by reference}, o dal C++ dove la modalità del
 958 passaggio può essere controllata con l'operatore \cmd{\&}).
 959
 960 Il passaggio di una variabile \textit{by value} significa che in realtà quello
 961 che viene passato alla subroutine è una copia del valore attuale di quella
 962 variabile, copia che la subroutine potrà modificare a piacere, senza che il
 963 valore originale nella routine chiamante venga toccato. In questo modo non
 964 occorre preoccuparsi di eventuali effetti delle operazioni della subroutine.
 965
 966 La maggior parte delle funzioni di libreria e delle system call funziona
 967 esattamente in questo modo restituendo eventuali risultati alla routine
 968 chiamante attraverso il valore di ritorno. Talvolta però è necessario che la
 969 funzione possa restituire indietro alla funzione chiamate un valore relativo
 970 ad uno dei sui parametri.
 971
 972
 973
 974
 975 \subsection{Potenziali problemi con le variabili automatiche}
 976 \label{sec:proc_auto_var}
 977
 978
 979 \subsection{Il controllo di flusso non locale}
 980 \label{sec:proc_longjmp}
 981
 982 Il controllo del flusso di un programma in genere viene effettuato con le
 983 varie istruzioni del linguaggio C, la più bistrattata delle quali è il
 984 \func{goto}, ampiamente deprecato in favore di costrutti più puliti; esiste
 985 però un caso in l'uso di questa istruzione porta all'implementazione più
 986 efficiente, quello dell'uscita in caso di errore.
 987
 988 Il C però non consente di effettuare un salto ad una label definita in
 989 un'altra funzione, per cui se l'errore avviene in funzioni profondamente
 990 annidate occorre usare la funzione \func{longjump}.
 991
 992