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