c3a801c623fac9ed041d83225c8a023b82824082
[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.
10
11 In genere un programma viene eseguito quando un processo lo fa partire
12 eseguendo una funzione della famiglia \texttt{exec}; torneremo su questo e
13 sulla la creazione e gestione dei processi nel prossimo capitolo, in questo
14 affronteremo l'avvio e il funzionamento di un singolo processo partendo dal
15 punto di vista del programma posto in esecuzione.
16
17
18
19 \section{Esecuzione e conclusione di un programma}
20
21 Una delle concetti base relativi ai processi è che un processo esegue sempre
22 uno ed un solo programma: si possono avere più processi che eseguono lo stesso
23 programma ma ciascun processo vedrà la sua copia del codice (in realtà il
24 kernel fa si che tutte le parti uguali siano condivise) avrà un suo spazio di
25 indirizzi, variabili proprie e sarà eseguito in maniera completamente
26 indipendente da tutti gli altri. 
27
28 Anche quando all'interno di un programma possono essere presenti più
29 \textsl{filoni} di esecuzione (i cosiddetti \textit{thread}), o questo possa
30 essere composto da moduli multipli completamente separati, quando questo sarà
31 posto in esecuzione esso apparirà al sistema come un solo processo (il
32 discorso dei \textit{thread} comunque in Linux necessita di una trattazione a
33 parte per la peculiarità dell'implementazione).
34
35 \section{La funzione \texttt{main}} 
36 \label{sec:proc_main}
37
38 Quando un programma viene lanciato il kernel esegue una opportuna routine di
39 avvio, usando il programma \texttt{ld-linux.so}, è questo programma che prima
40 carica le librerie condivise che servono al programma, effettua il link
41 dinamico del codice e poi alla fine lo esegue. Infatti, a meno di non aver
42 specificato il flag \texttt{-static} durante la compilazione, tutti i
43 programmi in Linux sono incompleti e necessitano di essere linkati alle
44 librerie condivise quando vengono avviati.  La procedura è controllata da
45 alcune variabili di ambiente e dal contenuto di \texttt{/etc/ld.so.conf}, i
46 dettagli sono riportati nella man page di \texttt{ld.so}.
47
48 Il sistema fa partire qualunque programma chiamando la funzione \texttt{main};
49 sta al programmatore chiamare così la funzione principale del programma da cui
50 si suppone iniziale l'esecuzione; in ogni caso senza questa funzione lo stesso
51 linker darebbe luogo ad errori.
52
53 Lo standard ISO C specifica che la funzione \texttt{main} può o non avere
54 argomenti o prendere due argomenti che rappresentano gli argomenti passati da
55 linea di comando, in sostanza un prototipo che va sempre bene è il seguente:
56 \begin{verbatim}
57      int main (int argc, char *argv[])
58 \end{verbatim}
59
60 In realtà nei sistemi unix esiste un'altro modo per definire la funzione
61 \texttt{main}, che prevede la presenza di un terzo parametro, \texttt{char
62   *envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{proc_environ}) del
63 programma; questa forma però non è prevista dallo standard POSIX.1 per cui se
64 si vogliono scrivere programmi portabili è meglio evitarla.
65
66
67 \subsection{Come chiudere un programma}
68 \label{sec:proc_termination}
69
70 La via normale per la quale un programma finisce è quando la funzione main
71 ritorna, una modalità equivalente di conclusione è quella di chiamare
72 direttamente la funzione \texttt{exit} (che viene comunque chiamata dalla
73 routine di avvio del programma quando la funzione main ritorna). Una forma
74 alternativa è quella di chiamare direttamente la system call \texttt{\_exit}
75 che passa il controllo direttamente al kernel.
76
77 Oltre alla conclusione ``normale'' esiste anche la possibilità di una
78 conclusione ``anomala'' del programma a causa di segnali o della chiamata alla
79 funzione \texttt{abort} (che comunque genera un segnale che termina il
80 programma); torneremo su questo in \secref{sec:sig_abort}.
81
82 Il valore di ritorno della funzione main, o quello usato nelle chiamate ad
83 \texttt{exit} e \texttt{\_exit}, viene chiamato \textit{exit status} e passato
84 al processo padre che aveva lanciato il programma (in genere la shell). In
85 generale si usa questo valore per fornire un'informazione generica sulla
86 riuscita o il fallimento del programma; l'informazione è necessariamente
87 generica, ed il valore deve essere compreso fra 0 e 255.
88
89 In generale si usa la convenzione di restituire 0 in caso di successo e 1 in
90 caso di fallimento, i programmi che effettuano dei confronti (come
91 \texttt{diff}) usano invece una notazione leggermente diversa, usando 0 per
92 indicare la corrispondenza, 1 per indicare la non corrispondenza e 2 per
93 indicare l'incapacità di effettuare il confronto. È opportuno adottare una di
94 queste convenzioni a seconda dei casi. Si tenga presente che se si raggiunge
95 la fine della funzione \texttt{main} senza ritornare esplicitamente si ha un
96 valore di uscita indefinito, è pertanto consigliabile di concludere sempre in
97 maniera esplicita detta funzione.
98
99 Una altra convenzione riserva i valori da 128 in su per usi speciali, ad
100 esempio 128 viene usato per indicare l'incapacità di eseguire un altro
101 programma in un sottoprocesso. Benché anche questa convenzione non sia
102 universalmente seguita è una buona idea tenerne conto.
103
104 Si tenga presente inoltre che non è una buona idea usare il valore dell'errore
105 restituito dalla variabile \texttt{errno} come stato di uscita, in generale
106 una shell non si cura di tutto questo e comunque il valore dello stato di
107 uscita è sempre troncato ad 8 bit, per cui si potrebbe incorrere nel caso in
108 cui l'errore 256, diventando zero, verrebbe interpretato come un successo. In
109 \texttt{stdlib.h} sono definite due macro \texttt{EXIT\_SUCCESS} e
110 \texttt{EXIT\_FAILURE}, che in Linux sono poste rispettivamente ai valori 0 e
111 1 (di tipo \texttt{int}), seguendo lo standard POSIX.
112
113 Infine occorre distinguere fra lo stato di uscita di un programma
114 (l'\textit{exit status}) e lo stato di conclusione di un processo (il
115 \textit{termination status}), abbiamo già accennato infatti che è comunque
116 possibile un processo possa essere terminato (da un segnale) prima che il
117 programma in esecuzione si sia concluso. In caso di conclusione normale del
118 programma però lo stato di uscita diventa parte dello stato di conclusione del
119 processo (vedi \secref{sec:prochand_XXX}).
120
121
122 \subsection{Le funzioni \texttt{exit} e \texttt{\_exit}}
123 \label{sec:proc_exit}
124
125 Come accennato funzioni per l'uscita ``normale'' da un programma sono due, la
126 prima è la funzione \texttt{exit} che è definita dallo standard ANSI C, il
127 prototipo della funzione è il seguente:
128 \begin{prototype}{stdlib.h}{void exit(int status)}
129   Causa la conclusione ordinaria del programma restituendo il valore
130   \texttt{status} al processo padre.
131
132   La funzione non ritorna. Il processo viene terminato
133 \end{prototype}
134
135 La funzione \texttt{exit} è pensata per una conclusione pulita di un programma
136 che usa le librerie standard del C; essa esegue tutte le funzioni che sono
137 state registrate con \texttt{atexit} e \texttt{on\_exit} (vedi
138 \secref{sec:proc_atexit}), e chiude tutti gli stream di I/O effettuando il
139 salvataggio dei dati sospesi (chiamando \texttt{fclose}, vedi
140 \secref{sec:filestd_close}), infine ripassa il controllo al kernel chiamando
141 \texttt{\_exit} e passando il valore \texttt{status} come stato di uscita.
142
143 La system call \texttt{\_exit} restituisce direttamente il controllo al
144 kernel, concludendo immediatamente il processo, le eventuali funzioni
145 registrate con \texttt{atexit} e \texttt{on\_exit} non vengono eseguite. Il
146 prototipo della funzione è il seguente:
147 \begin{prototype}{unistd.h}{void \_exit(int status)}
148   Causa la conclusione immediata del programma restituendo il valore
149   \texttt{status} al processo padre.
150
151   La funzione non ritorna. Il processo viene terminato.
152 \end{prototype}
153
154 La funzione chiude tutti i file descriptor appartenenti al processo (sui tenga
155 presente che questo non comporta il salvataggio dei dati bufferizzati degli
156 stream), fa si che ogni figlio del processo sia ereditato da \texttt{init}
157 (vedi \secref{cha:process_handling}), manda un segnale \texttt{SIGCHLD} al
158 processo padre (vedi \ref{sec:sig_sigchild}) ed infine ritorna lo stato di
159 uscita specificato in \texttt{status} che può essere raccolto usando la
160 funzione \texttt{wait} (vedi \secref{sec:prochand_wait}).
161
162
163 \subsection{Le funzioni \texttt{atexit} e \texttt{on\_exit}}
164 \label{sec:proc_atexit}
165
166 Come accennato l'uso di \texttt{exit} al posto della \texttt{\_exit} è fatto
167 principalmente per permettere una uscita pulita dalle funzioni delle librerie
168 standard del C (in particolare per quel che riguarda la chiusura degli
169 stream). 
170
171 Quando si realizza una libreria da usare in varie applicazioni può essere
172 perciò utile evitare di richiedere di chiamare esplicitamente un funzione di
173 uscita che esegua tutte le operazioni di pulizia prima di uscire (come quella
174 di salvare eventuali dati sospesi). È invece molto meno soggetto ad errori e
175 completamente trasparente all'utente poter effettuare una chiamata automatica
176 di una funzione che effettui tali operazioni all'uscita dal programma.
177
178 A questo scopo lo standard ANSI C prevede la possibilità di registrare un
179 certo numero funzioni che verranno eseguite all'uscita dal programma (sia per
180 la chiamata ad \textit{exit} che per il ritorno di \texttt{main}). La prima
181 funzione che si può utilizzare a tal fine è:
182 \begin{prototype}{stdlib.h}{void atexit(void (*function)(void))}
183   Registra la funzione \texttt{function} per essere chiamata all'uscita dal
184   programma. 
185
186   La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
187   \texttt{errno} non viene settata.
188 \end{prototype}
189
190 La funzione richiede come argomento l'indirizzo della opportuna da chiamare
191 all'uscita che non deve prendere argomenti e non deve ritornare niente. Una
192 estensione di \texttt{atexit} è la funzione \texttt{on\_exit} (che la glibc
193 include per compatibilità con SunOS e che non è detta sia definita su altri
194 sistemi), il cui prototipo è:
195 \begin{prototype}{stdlib.h}
196 {void on\_exit(void (*function)(int status, void *arg), void *arg)}
197   Registra la funzione \texttt{function} per essere chiamata all'uscita dal
198   programma. Tutte le funzioni registrate vengono chiamate in ordine inverso
199   rispetto a quello di registrazione.
200
201   La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
202   \texttt{errno} non viene settata.
203 \end{prototype}
204
205 In questo caso la funzione da chiamare prende due parametri, il primo dei
206 quali sarà inizializzato allo stato di uscita con cui è stata chiamata
207 \texttt{exit} ed il secondo al puntatore generico specificato come secondo
208 argomento nella chiamata di \texttt{on\_exit}.
209
210 Tutte le funzioni registrate vengono chiamate in ordine inverso rispetto a
211 quello di registrazione (ed una stessa funzione registrata più volte sarà
212 chiamata più volte); poi vengono chiusi tutti gli stream aperti, infine viene
213 chiamata \texttt{\_exit}.
214
215
216 \subsection{Conclusioni}
217 \label{sec:proc_term_conclusion}
218
219 Data l'importanza dell'argomento è opportuno sottolineare ancora una volta che
220 in un sistema unix l'unico modo in cui un programma può essere eseguito dal
221 kernel è attraverso la chiamata alla system call \texttt{execve} (in genere
222 attraveso una delle funzioni \texttt{exec} che vedremo in
223 \secref{sec:prochand_exec}).
224
225 Allo stesso modo l'unico modo in cui un programma può concludere
226 volontariamente la sua esecuzione è attraverso una chiamata alla system call
227 \texttt{\_exec} sia esplicitamente o che in maniera indiretta attraverso l'uso
228 di \texttt{exit} o il ritorno della funzione \texttt{main}.
229
230 Lo schema delle modalità con cui si avvia e conclude normalmente un programma
231 è riportato in \nfig.
232
233 \begin{figure}[htb]
234   \centering
235   
236   \caption{Schema dell'avvio e della conclusione di un programma.}
237   \label{fig:proc_prog_start_stop}
238 \end{figure}
239
240 Si ricordi infine che un programma può anche essere interrotto dall'esterno
241 attraverso l'uso di un segnale (modalità di conclusione non mostrata in
242 \curfig); torneremo su questo aspetto in \secref{cha:signals}.
243
244
245
246 \section{I processi e l'uso della memoria}
247 \label{sec:proc_memory}
248
249 Una delle risorse base che ciascun processo ha a disposizione è la memoria, ed
250 uno degli aspetti più complessi di un sistema unix (ed in particolar modo di
251 Linux) è appunto la gestione della memoria. Qui ci occuperemo però di come la
252 memoria viene vista dal punto di vista di un programma in esecuzione in un
253 processo.
254
255
256 \subsection{I concetti generali}
257 \label{sec:proc_mem_gen}
258
259 Ci sono vari modi in cui i vari sistemi organizzano la memoria (ed i dettagli
260 di basso livello dipendono in maniera diretta dall'architettura
261 dell'hardware), ma quello più tipico, usato da unix (e da Linux) è quello di
262 assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare in
263 cui gli indirizzi vanno da zero ad un qualche valore massimo (nel caso di
264 Linux fino al kernel 2.2 detto massimo era per macchine a 32bit di 2Gb, con il
265 kernel 2.4 il limite è stato esteso).
266
267 Come accennato nell'introduzione questo spazio di indirizzi è virtuale e non
268 corrisponde all'effettiva posizione dei dati nella RAM del computer; in genere
269 detto spazio non è neanche continuo (cioè non tutti gli indirizzi sono
270 utilizzabili e/o utilizzati).
271
272 La memoria virtuale viene divisa in pagine (che ad esempio sono di 4kb su
273 macchine a 32 bit e 8kb sulle alpha, valori strettamente connessi all'hardware
274 di gestione della memoria) di dimensione fissa, e ciascuna pagina della
275 memoria virtuale è associata ad un supporto che può essere una pagina di
276 memoria reale o ad un dispositivo di stoccaggio secondario (in genere lo spazio
277 disco riservato alla swap, o i file che contengono il codice).
278
279 Lo stesso pezzo di memoria reale (o di spazio disco) può fare da supporto a
280 diverse pagine di memoria virtuale appartenenti a processi diversi (come
281 accade in genere per le pagine che contengono il codice delle librerie
282 condivise). Ad esempio il codice della funzione \texttt{printf} starà su una
283 sola pagina di memoria reale che farà da supporto a tutte le pagine di memoria
284 virtuale di tutti i processi hanno detta funzione nel loro codice. 
285
286 La corrispondenza fra le pagine della memoria virtuale e quelle della memoria
287 fisica della macchina viene gestita in maniera trasparente dall'hardware di
288 gestione della memoria (dalla \textit{Memory Management Unit} del processore),
289 ma poiché in genere quest'ultima è solo una piccola frazione della memoria
290 virtuale è necessario un meccanismo che permetta di trasferire le pagine
291 virtuali che servono dal supporto su cui si trovano in memoria eliminando
292 quelle che non servono. Questo meccanismo è detto \textit{paging}, ed è uno
293 dei compiti principali del kernel.
294
295 Quando un processo cerca di accedere ad una pagina che non è nella memoria
296 reale avviene quello che viene chiamato un \textit{page fault}, l'hardware di
297 gestione della memoria (la MMU del processore) genera una interruzione e passa
298 il controllo al kernel il quale sospende il processo e si incarica di mettere
299 in RAM la pagina richiesta (effettuando tutte le operazioni necessarie per
300 reperire lo spazio necessario), per poi restituire il controllo al
301 processo. 
302
303 Dal punto di vista di un processo questo meccanismo è completamente
304 trasparente e tutto avviene come se tutte le pagine fossero sempre disponibili
305 in memoria.  L'unica differenza avvertibile è quella dei tempi di esecuzione,
306 che passano dai pochi nanosecondi necessari per l'accesso a tempi molto più
307 lunghi, dovuti all'intervento del kernel. Normalmente questo è il prezzo da
308 pagare per avere un multitasking reale, ed in genere il sistema è molto
309 efficiente in questo lavoro; quando però ci siano esigenze specifiche di
310 prestazioni è possibile usare delle funzioni che permettono di bloccare il
311 meccanismo del paging e mantenere fisse delle pagine in memoria (vedi
312 \ref{sec:proc_mem_lock}).
313
314
315 \subsection{La struttura della memoria di un processo}
316 \label{sec:proc_mem_layout}
317
318 Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
319 una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
320 tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
321 commette quando si è manipolato male un puntatore e genera quello che viene
322 chiamato un \textit{segmentation fault}, si tenta cioè di leggere e scrivere
323 da un indirizzo per il quale non esiste una associazione della pagina virtuale
324 ed il kernel risponde al relativo \textit{page fault} mandando un segnale
325 \texttt{SIGSEGV} al processo, che normalmente ne causa la terminazione
326 immediata.
327
328 È pertanto importante capire come viene strutturata la memoria virtuale di un
329 processo; essa viene divisa in \textsl{segmenti}, cioè un insieme contiguo di
330 indirizzi virtuali ai quali il processo può accedere. Solitamente un
331 programma C viene suddiviso nei seguenti segmenti:
332
333 \begin{enumerate}
334 \item Il segmento di testo (\textit{text segment}). Contiene il codice
335   macchina del programma e le costanti statiche. Normalmente viene condiviso
336   così che più processi (anche diversi nel caso di librerie) possano
337   utilizzarlo e viene marcato in sola lettura per evitare sovrascritture
338   accidentali (o maliziose) che ne modifichino le istruzioni.
339   
340   Viene allocato da \texttt{exec} all'avvio del programma e resta invariato
341   per tutto il tempo dell'esecuzione.
342   
343 \item Il segmento dei dati (\textit{data segment}). Contiene le variabili
344   globali (cioè quelle definite al di fuori di tutte le funzioni). Di norma è
345   diviso in due parti.
346   
347   La prima parte è il segmento dei dati inizializzati, che contiene le
348   variabili globali il cui valore è stato assegnato esplicitamente. Ad esempio
349   se si definisce:
350 \begin{verbatim}
351     double pi = 3.14;
352 \end{verbatim}
353   questo valore sarà immagazzinato in questo segmento. La memoria di questo
354   segmento viene preallocato dalla \texttt{exec} e inizializzata ai valori
355   specificati.
356   
357   La seconda parte è il segmento dei dati non inizializzati, che contiene le
358   variabili globali il cui valore è stato non è assegnato esplicitamente. Ad
359   esempio se si definisce:
360 \begin{verbatim}
361     int vect[100];
362 \end{verbatim}
363   questo valore sarà immagazzinato in questo segmento. Anch'esso viene
364   allocato all'avvio, e tutte le variabili vengono inizializzate a
365   zero (ed i puntatori a \texttt{NULL}). 
366   
367   Storicamente questo segmento viene chiamato BBS (da \textit{block started by
368     symbol}. La sua dimensione è fissa.
369   
370 \item Lo \textit{heap}. Tecnicamente lo si può considerare l'estensione del
371   segmento dati, a cui di solito è posto giusto di seguito. È qui che avviene
372   l'allocazione dinamica della memoria; può essere ridimensionato allocando e
373   disallocando la memoria dinamica con le apposite funzioni (vedi
374   \secref{sec:proc_mem_alloc}), ma il suo limite inferiore (quello adiacente
375   al segmento dati) ha una posizione fissa.
376   
377 \item Il segmento di \textit{stack}, che contiene lo \textit{stack} del
378   programma.  Tutte le volte che si effettua una chiamata ad una funzione è
379   qui che viene salvato l'indirizzo di ritorno e le informazioni dello stato
380   del chiamante (tipo il contenuto di alcuni registri della CPU); poi la
381   funzione chiamata alloca qui lo spazio per le sue variabili locali, in
382   questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
383   della funzione lo spazio è automaticamente rilasciato.
384   
385   La dimensione di questo segmento aumenta seguendo la crescita dello stack
386   del programma, ma non viene ridotta quando quest'ultimo si restringe.
387 \end{enumerate}
388
389 \begin{figure}[htb]
390   \centering
391   
392   \caption{Disposizione tipica dei segmenti di memoria di un processo}
393   \label{fig:proc_mem_layout}
394 \end{figure}
395
396 Una disposizione tipica di questi segmenti è riportata in \nfig. Usando il
397 comando \texttt{size} su un programma se ne può stampare le dimensioni dei
398 segmenti di testo e di dati (inizializzati e BSS); il BSS però non è mai
399 salvato sul file, in quanto viene inizializzato a zero al caricamento del
400 programma.
401
402
403 \subsection{Allocazione della memoria per i programmi C}
404 \label{sec:proc_mem_alloc}
405
406 Il C supporta due tipi di allocazione della memoria, l'allocazione statica è
407 quella in cui vanno le variabili globali e le variabili statiche (e viene
408 effettuata nel segmento dei dati), lo spazio per queste variabili viene
409 allocati all'avvio del programma (come parte delle operazioni svolte da
410 \texttt{exec}) e non viene liberato fino alla sua conclusione.
411
412 L'allocazione automatica è quella che avviene per le cosiddette variabili
413 automatiche, cioè gli argomenti delle funzioni o le variabili locali. Lo
414 spazio per queste variabili viene allocato nello stack quando viene eseguito
415 comando di invocazione della funzione e liberato quando si esce dalla
416 medesima.
417
418 Esiste però un terzo tipo di allocazione, che non è prevista dal linguaggio C,
419 che è l'allocazione dinamica della memoria, necessaria quando il quantitativo
420 di memoria che serve è determinabile solo in corso di esecuzione del
421 programma. 
422
423 Il C non consente di usare variabili allocate dinamicamente, non è possibile
424 cioè definire in fase di programmazione una variabile le cui dimensioni
425 possano essere modificate durante l'esecuzione del programma; però le librerie
426 del C forniscono una serie opportuna di funzioni per permettere l'allocazione
427 dinamica di spazio in memoria (in genere nello heap, usando la system call
428 \texttt{sbrk}), solo che a questo punto detto spazio sarà accessibile solo in
429 maniera indiretta attraverso dei puntatori.
430
431
432 \subsection{Le funzioni \texttt{malloc}, \texttt{calloc}, \texttt{realloc} e
433   \texttt{free}}  
434 \label{sec:proc_mem_malloc}
435
436 Le funzioni previste dallo standard ANSI C per la gestione della memoria sono
437 quattro, i prototipi sono i seguenti:
438 \begin{prototype}{stdlib.h}{void *calloc(size\_t size)}
439   Alloca \texttt{size} bytes nello heap. La memoria viene inizializzata a 0.
440   
441   La funzione restituisce il puntatore alla zona di memoria allocata in caso
442   di successo e \texttt{NULL} in caso di fallimento, nel qual caso
443   \texttt{errno} viene settata a \texttt{ENOMEM}.
444 \end{prototype}
445 \begin{prototype}{stdlib.h}{void *malloc(size\_t size)}
446   Alloca \texttt{size} bytes nello heap. La memoria non viene inizializzata.
447
448   La funzione restituisce il puntatore alla zona di memoria allocata in caso
449   di successo e \texttt{NULL} in caso di fallimento, nel qual caso
450   \texttt{errno} viene settata a \texttt{ENOMEM}.
451 \end{prototype}
452 \begin{prototype}{stdlib.h}{void free(void *ptr)}
453   Disalloca lo spazio di memoria puntato da \texttt{ptr}.
454
455   La funzione non ritorna nulla.
456 \end{prototype}
457 \begin{prototype}{stdlib.h}{void *realloc(void *ptr, size\_t size)}
458   Cambia la dimensione del blocco allocato all'indirizzo \texttt{ptr}
459   portandola a \texttt{size}.
460
461   La funzione restituisce il puntatore alla zona di memoria allocata in caso
462   di successo e \texttt{NULL} in caso di fallimento, nel qual caso
463   \texttt{errno} viene settata a \texttt{ENOMEM}.
464 \end{prototype}
465
466 Il puntatore che le funzioni di allocazione ritornano è garantito essere
467 sempre correttamente allineato per tutti i tipi di dati; ad esempio sulle
468 macchine a 32 bit in genere è allineato a multipli di 4 bytes e sulle macchine
469 a 64 bit a multipli di 8 bytes. 
470
471 In genere su usano le funzioni \texttt{malloc} e \texttt{calloc} per allocare
472 dinamicamente la memoria necessaria al programma, siccome i puntatori
473 ritornati sono di tipo generico non è necessario effettuare un cast per
474 assegnarli a puntatori al tipo di variabile per la quale si effettua la
475 allocazione.
476
477 La memoria allocata dinamicamente deve essere esplicitamente rilasciata usando
478 \texttt{free}\footnote{le glibc provvedono anche una funzione \texttt{cfree}
479   defininita per compatibilità con SunOS, che è deprecata} una volta che non
480 sia più necessaria. Questa funzione vuole come parametro un puntatore
481 restituito da una precedente chiamata a una qualunque delle funzioni di
482 allocazione e che non sia già stato liberato da un'altra chiamata a
483 \texttt{free}, in caso contrario il comportamento della funzione è indefinito.
484
485 La funzione \texttt{realloc} si usa invece per cambiare (in genere aumentare)
486 la dimensione di un'area di memoria precedentemente allocata, la funzione
487 vuole in ingresso il puntatore restituito dalla precedente chiamata ad una
488 \texttt{malloc} (se è passato un valore \texttt{NULL} allora la funzione si
489 comporta come \texttt{malloc}\footnote{questo è vero per linux e
490   l'implementazione secondo lo standard ANSI C, ma non è vero per alcune
491   vecchie implementazioni, inoltre alcune versioni delle librerie del C
492   consentivano di usare \texttt{realloc} anche per un puntatore liberato con
493   \texttt{free} purché non ci fossero state altre chiamate a funzioni di
494   allocazione, questa funzionalità è totalmente deprecata e non è consentita
495   sotto linux}), ad esempio quando si deve far crescere la dimensione di un
496 vettore; in questo caso se è disponibile dello spazio adiacente al precedente
497 la funzione lo utilzza, altrimenti rialloca altrove un blocco della dimensione
498 voluta copiandoci automaticamente il contenuto, lo spazio in più non viene
499 inizializzato. 
500
501 Il fatto che il blocco di memoria restituito da \texttt{realloc} possa
502 camabiare comporta che si deve sempre riassegnare al puntatore passato per il
503 ridimensionamento il valore di ritorno della funzione, e che non ci devono
504 essere altri puntatori che puntino all'interno di un'area che si vuole
505 ridimensionare.
506
507
508 Uno degli errori più comuni (specie se si ha a che fare con array di
509 puntatori) è infatti quello di chiamare \texttt{free} più di una volta sullo
510 stesso puntatore; per evitare questo problema una soluzione di ripiego è
511 quella di assegnare sempre a \texttt{NULL} ogni puntatore liberato con
512 \texttt{free}, dato che, quando il parametro è un puntatore nullo,
513 \texttt{free} non esegue nessuna operazione. 
514
515 Linux e le glibc hanno una implementazione delle routine di allocazione che è
516 controllabile dall'utente attraverso alcune variabili di ambiente, in
517 particolare diventa possibile tracciare questo tipo di errori usando la
518 variabile \texttt{MALLOC\_CHECK\_} che quando viene settata mette in uso una
519 versione meno efficiente delle funzioni, che però è più tollerante nei
520 confronti di piccoli errori come quello di chiamate doppie a \texttt{free}; in
521 pparticolare se la variabile è posta a zero gli errori vengono ignorati, se è
522 posta ad 1 viene stampato un avviso sullo standard error e se 
523
524
525 Il problema più comune e più difficile da tracciare che si incontra con
526 l'allocazione della memoria è però quando la memoria non più utilizzata non
527 viene opportunamente liberata (quello che in inglese viene chiamato
528 \textit{memory-leak}, traducibile come \textsl{perdita di memoria}).
529
530 Un caso tipico è quando l'allocazione viene fatta da una subroutine per un uso
531 locale, ma la memoria non viene liberata una volta usata; chiamate ripetute
532 alla stessa suubroutine causeranno a lungo andare un esaurimento della memoria
533 disponibile, con un conseguente crash dell'applicazione che può avvenire in
534 qualunque momento senza nessuna relazione con la subroutine che contiene
535 l'errore. 
536
537 Per questo motivo l'implementazione delle routine di allocazione delle glibc
538 mette a disposizione una serie di funzionalità (su cui torneremo in
539 \secref{sec:proc_mem_advanced}) che permettono di tracciare le allocazioni e
540 le disallocazione, e definisce anche una serie di possibili agganci che
541 permettono di sostituire alle funzioni di libreria una propria versione (che
542 può essere più o meno specializzata per il debugging).
543
544 \subsection{La funzione \texttt{alloca}}  
545 \label{sec:proc_mem_alloca}
546
547 Una alternativa possibile all'uso di \texttt{malloc}, che non soffre del tipo
548 di problemi di memomry leak descritti in precedenza è la funzione
549 \texttt{alloca} che invece che allocare la memoria nello heap usa lo il
550 segmento di stack della funzione corrente. La sintassi è identica:
551 \begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
552   Alloca \texttt{size} bytes nel segmento di stack della funzione chiamante.
553   La memoria non viene inizializzata.
554
555   La funzione restituisce il puntatore alla zona di memoria allocata in caso
556   di successo e \texttt{NULL} in caso di fallimento, nel qual caso
557   \texttt{errno} viene settata a \texttt{ENOMEM}.
558 \end{prototype}
559 ma in questo caso non è più necessario liberare la memoria in quanto questa
560 viene rilasciata automaticamente al ritorno della funzione.
561
562 Come è evidente questa funzione ha molti vantaggi, e permette di evitare i
563 problemi di memory leak non essendo più necessaria la deallocazione esplicita;
564 una delle ragioni principali per usarla è però che funziona anche quando si
565 usa \texttt{longjump} per uscire con un salto non locale da una funzione (vedi
566 \secref{sec:proc_longjmp}), 
567
568 Un altro vantaggio e che in Linux la funzione è molto veloce e non viene
569 sprecato spazio, infatti non è necessario gestire un pool di memoria da
570 riservare e si evitano anche problemi di frammentazione.
571
572 Gli svantaggi sono che la funzione non è disponibile su tutti gli unix quando
573 non è possibile aumentare le dimensioni dello stack una volta chiamata una
574 funzione e quindi l'uso limita la portabilità dei programmi, inoltre se si
575 cerca di allocare troppa memoria non si ottiene un messaggio di errore, ma un
576 segnale di \textit{segmentation violation} analogo a quello che si avrebbe da
577 una ricorsione infinita.
578
579
580 \subsection{Le funzioni \texttt{brk} e \texttt{sbrk}}  
581 \label{sec:proc_mem_sbrk}
582
583 L'uso di queste funzioni è necessario solo quando si voglia accedere alle
584 analoghe system call a cui fanno da interfaccia (ad esempio per implementare
585 una propria versione di \texttt{malloc}. Le  funzione sono:
586 \begin{prototype}{unistd.h}{int *brk(void end_data_segment)}
587   Sposta la fine del segmento dei dati all'indirizzo specificato da
588   \texttt{end_data_segment}.
589   
590   La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
591   nel qual caso \texttt{errno} viene settata a \texttt{ENOMEM}.
592 \end{prototype}
593 \begin{prototype}{unistd.h}{int *sbrk(ptrdiff\_t increment)}
594   Incrementa lo spazio dati di un programma di \texttt{increment}. 
595   
596   La funzione restituisce il puntatore all'inzio della nuova zona di memoria
597   allocata in caso di successo e \texttt{NULL} in caso di fallimento, nel qual
598   caso \texttt{errno} viene settata a \texttt{ENOMEM}.
599 \end{prototype}
600
601 Queste funzioni sono state deliberatamente escluse dallo standard POSIX.1 e
602 per i programmi normali è opportuno usare le funzioni di allocazione standard
603 descritte in precedenza, che sono costruite su di esse.  In genere si usa
604 \texttt{sbrk} con un valore zero per ottenere l'attuale posizione della fine
605 del segmento dati. 
606
607
608 \subsection{La personalizzazione delle funzioni di allocazione} 
609 \label{sec:proc_mem_malloc_custom}
610
611
612 \subsection{Il controllo della memoria virtuale}  
613 \label{sec:proc_mem_mlock}
614
615
616 \section{Il controllo di flusso non locale}
617 \label{sec:proc_longjmp}
618
619
620 \section{La gestione di parametri e opzioni}
621 \label{sec:proc_options}
622
623 Il passaggio dei parametri e delle variabili di ambiente dalla riga di comando
624 al singolo programma quando viene lanciato è effettuato attraverso le
625 variabili \texttt{argc}, \texttt{argv} che vengono passate al programma
626 come argomenti della funzione principale.
627
628 \subsection{Il formato dei parametri}
629 \label{sec:proc_par_format}
630 In genere passaggio dei parametri al programma viene effettuato dalla shell,
631 che si incarica di leggere la linea di comando e di effettuarne la scansione
632 (il cosiddetto \textit{parsing}) per individuare le parole che la compongono,
633 ciascuna delle quali viene considerata un parametro; di default per
634 individuare le parole viene usato come separatore lo spazio (comportamento
635 modificabile attraverso il settaggio della variabile di ambiente IFS).
636
637 Nella scansione viene costruito il vettore di puntatori \texttt{argv} inserendo
638 in successione il puntatore alla stringa costituente l'$n$-simo parametro; la
639 variabile \texttt{argc} viene inizializzata al numero di parametri trovati, in
640 questo modo il primo parametro è sempre il nome del programma (vedi \nfig).
641
642 \subsection{La gestione delle opzioni}
643 \label{sec:proc_opt_handling}
644
645 In generale un programma unix riceve da linea di comando sia i parametri che
646 le opzioni, queste ultime sono standardizzate per essere riconosciute come
647 tali: un elemento di \texttt{argv} che inizia con \texttt{-} e che non sia un
648 singolo \texttt{-} o \texttt{--} viene considerato un'opzione.  In in genere
649 le opzioni sono costituite da una lettera preceduta dal meno e possono avere o
650 no un parametro associato; un comando tipico può essere cioè qualcosa del
651 tipo:
652 \begin{verbatim}
653 touch -r riferimento.txt -m questofile.txt
654 \end{verbatim}
655 ed in questo caso le opzioni sono \texttt{m} ed \texttt{r}.
656
657 Per gestire le opzioni all'interno dei parametri passati in \texttt{argv} le
658 librerie standard del C forniscono la funzione \texttt{getopt} (accessibile
659 includendo \texttt{unistd.h}), che ha il prototipo:
660 \begin{verbatim}
661 int getopt(int argc, char * const argv[], const char * optstring);
662 \end{verbatim}
663
664 Questa funzione prende come argomenti le due variabili \texttt{argc} e
665 \texttt{argv} ed una stringa che indica quali sono le opzioni valide; la
666 funzione effettua la scansione della lista dei parametri ricercando ogni
667 stringa che comincia con \texttt{-} e ritorna ogni volta che trova una opzione
668 valida.
669
670 La stringa \texttt{optstring} indica quali sono le opzioni riconosciute ed è
671 costituita da tutti i caratteri usati per identificare le singole opzioni, se
672 l'opzione ha un parametro al carattere deve essere fatto seguire un segno di
673 due punti \texttt{:} nel caso appena accennato ad esempio la stringa di
674 opzioni sarebbe \texttt{"r:m"}.
675
676 La modalità di uso è pertanto quella di chiamare più volte la funzione
677 all'interno di un ciclo di while fintanto che essa non ritorna il valore
678 \texttt{-1} che indica che non ci sono più opzioni. Nel caso si incontri
679 un'opzione non dichiarata in \texttt{optstring} viene ritornato un \texttt{?}
680 mentre se l'opzione non è seguita da un parametro viene ritornato un
681 \texttt{:} infine se viene incontrato il valore \texttt{--} la scansione viene
682 considerata conclusa.
683
684 Quando la funzione trova un'opzione essa ritorna il valore numerico del
685 carattere, in questo modo si possono prendere le azioni relative usando un
686 case; la funzione inizializza inoltre alcune variabili globali:
687 \begin{itemize}
688 \item \texttt{char * optarg} contiene il puntatore alla stringa argomento
689   dell'opzione.
690 \item \texttt{int optind} alla fine della scansione restituisce l'indice del
691   primo argomento che non è un'opzione.
692 \item \texttt{int opterr} previene, se posto a zero, la stampa di un messaggio
693   di errore in caso di riconoscimento di opzioni non definite.
694 \item \texttt{int optopt} contiene il carattere dell'opzione non riconosciuta.
695 \end{itemize}
696
697 In \nfig\ è mostrato un programma di esempio, 
698
699 \begin{figure}[htbp]
700   \footnotesize
701     \begin{lstlisting}{}
702     opterr = 0;  /* don't want writing to stderr */
703     while ( (i = getopt(argc, argv, "o:a:i:hve")) != -1) {
704         switch (i) {
705         case 'i':   /* input file */
706             in_file=open(optarg,O_RDONLY);
707             if (in_file<0) {
708                 perror("Cannot open input file");
709                 exit(1);
710             }
711             break;
712         case 'o':   /* output file (overwrite) */
713             out_file=open(optarg,O_WRONLY|O_CREAT);
714             if (out_file<0) {
715                 perror("Cannot open output file");
716                 exit(1);
717             }
718             break;
719             break;
720         case 'a':   /* output file (append) */
721             out_file=open(optarg,O_WRONLY|O_CREAT|O_APPEND);
722             break;
723         case 'h':   /* print help usage */
724             usage();
725             break;
726         case 'v':   /* set verbose mode */
727             debug("Option -v active\n");
728             verbose=1;
729             break;
730         case '?':   /* unrecognized options */
731             printf("Unrecognized options -%c\n",optopt);
732             usage();
733         default:    /* should not reached */
734             debug("default option\n");
735             usage();
736         }
737     }
738     debug("Optind %d, argc %d\n",optind,argc);
739   \end{lstlisting}
740   \caption{Esempio di codice per la gestione delle opzioni.}
741   \label{fig:proc_options_code}
742 \end{figure}
743
744 \subsection{Opzioni in formato esteso}
745 \label{sec:proc_opt_extended}
746
747 Un'estensione di questo schema è costituito dalle cosiddette
748 \textit{long-options} espresse nella forma \texttt{--option=parameter}, anche
749 la gestione di queste ultime è stata standardizzata attraverso l'uso di una
750 versione estesa di \texttt{getopt}.
751
752
753 \subsection{Le variabili di ambiente}
754 \label{sec:proc_env_var}
755