3 %% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
11 \chapter{L'interfaccia base con i processi}
12 \label{cha:process_interface}
14 Come accennato nell'introduzione il \textsl{processo} è l'unità di base con
15 cui un sistema unix-like alloca ed utilizza le risorse. Questo capitolo
16 tratterà l'interfaccia base fra il sistema e i processi, come vengono passati
17 gli argomenti, come viene gestita e allocata la memoria, come un processo può
18 richiedere servizi al sistema e cosa deve fare quando ha finito la sua
19 esecuzione. Nella sezione finale accenneremo ad alcune problematiche generiche
22 In genere un programma viene eseguito quando un processo lo fa partire
23 eseguendo una funzione della famiglia \func{exec}; torneremo su questo e sulla
24 creazione e gestione dei processi nel prossimo capitolo. In questo
25 affronteremo l'avvio e il funzionamento di un singolo processo partendo dal
26 punto di vista del programma che viene messo in esecuzione.
29 \section{Esecuzione e conclusione di un programma}
31 Uno dei concetti base di Unix è che un processo esegue sempre uno ed un solo
32 programma: si possono avere più processi che eseguono lo stesso programma ma
33 ciascun processo vedrà la sua copia del codice (in realtà il kernel fa sì che
34 tutte le parti uguali siano condivise), avrà un suo spazio di indirizzi,
35 variabili proprie e sarà eseguito in maniera completamente indipendente da
36 tutti gli altri.\footnote{questo non è del tutto vero nel caso di un programma
37 \textit{multi-thread}, ma la gestione dei \textit{thread} in Linux sarà
41 \subsection{La funzione \func{main}}
44 Quando un programma viene lanciato il kernel esegue un'opportuna routine di
45 avvio, usando il programma \cmd{ld-linux.so}. Questo programma prima carica
46 le librerie condivise che servono al programma, poi effettua il collegamento
47 dinamico del codice e alla fine lo esegue. Infatti, a meno di non aver
48 specificato il flag \texttt{-static} durante la compilazione, tutti i
49 programmi in Linux sono incompleti e necessitano di essere \textsl{collegati}
50 alle librerie condivise quando vengono avviati. La procedura è controllata da
51 alcune variabili di ambiente e dal contenuto di \file{/etc/ld.so.conf}. I
52 dettagli sono riportati nella man page di \cmd{ld.so}.
54 Il sistema fa partire qualunque programma chiamando la funzione \func{main};
55 sta al programmatore chiamare così la funzione principale del programma da cui
56 si suppone iniziare l'esecuzione; in ogni caso senza questa funzione lo stesso
57 \textit{linker} (si chiama così il programma che effettua i collegamenti di
58 cui sopra) darebbe luogo ad errori. Lo standard ISO C specifica che la
59 funzione \func{main} può non avere argomenti o prendere due argomenti che
60 rappresentano gli argomenti passati da linea di comando, in sostanza un
61 prototipo che va sempre bene è il seguente:
62 \includecodesnip{listati/main_def.c}
64 In realtà nei sistemi Unix esiste un altro modo per definire la funzione
65 \func{main}, che prevede la presenza di un terzo argomento, \code{char
66 *envp[]}, che fornisce (vedi sez.~\ref{sec:proc_environ})
67 l'\textsl{ambiente} del programma; questa forma però non è prevista dallo
68 standard POSIX.1 per cui se si vogliono scrivere programmi portabili è meglio
72 \subsection{Come chiudere un programma}
73 \label{sec:proc_conclusion}
75 Normalmente un programma finisce quando la funzione \func{main} ritorna, una
76 modalità equivalente di chiudere il programma è quella di chiamare
77 direttamente la funzione \func{exit} (che viene comunque chiamata
78 automaticamente quando \func{main} ritorna). Una forma alternativa è quella
79 di chiamare direttamente la system call \func{\_exit}, che restituisce il
80 controllo direttamente alla routine di conclusione dei processi del kernel.
82 Oltre alla conclusione ``\textsl{normale}'' esiste anche la possibilità di una
83 conclusione ``\textsl{anomala}'' del programma a causa della ricezione di un
84 segnale (si veda cap.~\ref{cha:signals}) o della chiamata alla funzione
85 \func{abort}; torneremo su questo in sez.~\ref{sec:proc_termination}.
87 Il valore di ritorno della funzione \func{main}, o quello usato nelle chiamate
88 ad \func{exit} e \func{\_exit}, viene chiamato \textsl{stato di uscita} (o
89 \textit{exit status}) e passato al processo che aveva lanciato il programma
90 (in genere la shell). In generale si usa questo valore per fornire
91 informazioni sulla riuscita o il fallimento del programma; l'informazione è
92 necessariamente generica, ed il valore deve essere compreso fra 0 e 255.
94 La convenzione in uso pressoché universale è quella di restituire 0 in caso di
95 successo e 1 in caso di fallimento; l'unica eccezione è per i programmi che
96 effettuano dei confronti (come \cmd{diff}), che usano 0 per indicare la
97 corrispondenza, 1 per indicare la non corrispondenza e 2 per indicare
98 l'incapacità di effettuare il confronto. È opportuno adottare una di queste
99 convenzioni a seconda dei casi. Si tenga presente che se si raggiunge la fine
100 della funzione \func{main} senza ritornare esplicitamente si ha un valore di
101 uscita indefinito, è pertanto consigliabile di concludere sempre in maniera
102 esplicita detta funzione.
104 Un'altra convenzione riserva i valori da 128 a 256 per usi speciali: ad
105 esempio 128 viene usato per indicare l'incapacità di eseguire un altro
106 programma in un sottoprocesso. Benché questa convenzione non sia
107 universalmente seguita è una buona idea tenerne conto.
109 Si tenga presente inoltre che non è una buona idea usare il codice di errore
110 restituito dalla variabile \var{errno} (per i dettagli si veda
111 sez.~\ref{sec:sys_errors}) come stato di uscita. In generale infatti una shell
112 non si cura del valore se non per vedere se è diverso da zero; inoltre il
113 valore dello stato di uscita è sempre troncato ad 8 bit, per cui si potrebbe
114 incorrere nel caso in cui restituendo un codice di errore 256, si otterrebbe
115 uno stato di uscita uguale a zero, che verrebbe interpretato come un successo.
117 In \file{stdlib.h} sono definite, seguendo lo standard POSIX, le due costanti
118 \const{EXIT\_SUCCESS} e \const{EXIT\_FAILURE}, da usare sempre per specificare
119 lo stato di uscita di un processo. In Linux esse sono poste rispettivamente ai
120 valori di tipo \ctyp{int} 0 e 1.
123 \subsection{Le funzioni \func{exit} e \func{\_exit}}
124 \label{sec:proc_exit}
126 Come accennato le funzioni usate per effettuare un'uscita ``\textit{normale}''
127 da un programma sono due, la prima è la funzione \funcd{exit}, che è definita
128 dallo standard ANSI C ed il cui prototipo è:
129 \begin{prototype}{stdlib.h}{void exit(int status)}
130 Causa la conclusione ordinaria del programma.
132 \bodydesc{La funzione non ritorna. Il processo viene terminato.}
135 La funzione \func{exit} è pensata per eseguire una conclusione pulita di un
136 programma che usi le librerie standard del C; essa esegue tutte le funzioni
137 che sono state registrate con \func{atexit} e \func{on\_exit} (vedi
138 sez.~\ref{sec:proc_atexit}), e chiude tutti gli stream effettuando il
139 salvataggio dei dati sospesi (chiamando \func{fclose}, vedi
140 sez.~\ref{sec:file_fopen}), infine passa il controllo al kernel chiamando
141 \func{\_exit} e restituendo il valore di \param{status} come stato di uscita.
143 La system call \funcd{\_exit} restituisce direttamente il controllo al kernel,
144 concludendo immediatamente il processo; i dati sospesi nei buffer degli stream
145 non vengono salvati e le eventuali funzioni registrate con \func{atexit} e
146 \func{on\_exit} non vengono eseguite. Il prototipo della funzione è:
147 \begin{prototype}{unistd.h}{void \_exit(int status)}
148 Causa la conclusione immediata del programma.
150 \bodydesc{La funzione non ritorna. Il processo viene terminato.}
153 La funzione chiude tutti i file descriptor appartenenti al processo (si tenga
154 presente che questo non comporta il salvataggio dei dati bufferizzati degli
155 stream), fa sì che ogni figlio del processo sia adottato da \cmd{init} (vedi
156 cap.~\ref{cha:process_handling}), manda un segnale \const{SIGCHLD} al processo
157 padre (vedi sez.~\ref{sec:sig_job_control}) ed infine ritorna lo stato di
158 uscita specificato in \param{status} che può essere raccolto usando la
159 funzione \func{wait} (vedi sez.~\ref{sec:proc_wait}).
162 \subsection{Le funzioni \func{atexit} e \func{on\_exit}}
163 \label{sec:proc_atexit}
165 Un'esigenza comune che si incontra nella programmazione è quella di dover
166 effettuare una serie di operazioni di pulizia (ad esempio salvare dei dati,
167 ripristinare delle impostazioni, eliminare dei file temporanei, ecc.) prima
168 della conclusione di un programma. In genere queste operazioni vengono fatte
169 in un'apposita sezione del programma, ma quando si realizza una libreria
170 diventa antipatico dover richiedere una chiamata esplicita ad una funzione di
171 pulizia al programmatore che la utilizza.
173 È invece molto meno soggetto ad errori, e completamente trasparente
174 all'utente, avere la possibilità di effettuare automaticamente la chiamata ad
175 una funzione che effettui tali operazioni all'uscita dal programma. A questo
176 scopo lo standard ANSI C prevede la possibilità di registrare un certo numero
177 di funzioni che verranno eseguite all'uscita dal programma (sia per la
178 chiamata ad \func{exit} che per il ritorno di \func{main}). La prima funzione
179 che si può utilizzare a tal fine è \funcd{atexit} il cui prototipo è:
180 \begin{prototype}{stdlib.h}{void atexit(void (*function)(void))}
181 Registra la funzione \param{function} per la chiamata all'uscita dal
184 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
185 fallimento, \var{errno} non viene modificata.}
187 \noindent la funzione richiede come argomento l'indirizzo di una opportuna
188 funzione di pulizia da chiamare all'uscita del programma, che non deve
189 prendere argomenti e non deve ritornare niente (deve essere cioè definita come
190 \code{void function(void)}).
192 Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che le
193 \acr{glibc} includono per compatibilità con SunOS, ma che non è detto sia
194 definita su altri sistemi; il suo prototipo è:
195 \begin{prototype}{stdlib.h}
196 {void on\_exit(void (*function)(int , void *), void *arg)}
197 Registra la funzione \param{function} per la chiamata all'uscita dal
200 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
201 fallimento, \var{errno} non viene modificata.}
204 In questo caso la funzione da chiamare all'uscita prende i due argomenti
205 specificati nel prototipo, dovrà cioè essere definita come \code{void
206 function(int status, void *argp)}. Il primo argomento sarà inizializzato
207 allo stato di uscita con cui è stata chiamata \func{exit} ed il secondo al
208 puntatore \param{arg} passato come secondo argomento di \func{on\_exit}. Così
209 diventa possibile passare dei dati alla funzione di chiusura.
211 Nella sequenza di chiusura tutte le funzioni registrate verranno chiamate in
212 ordine inverso rispetto a quello di registrazione (ed una stessa funzione
213 registrata più volte sarà chiamata più volte); poi verranno chiusi tutti gli
214 stream aperti, infine verrà chiamata \func{\_exit}.
217 \subsection{Conclusioni}
218 \label{sec:proc_term_conclusion}
220 Data l'importanza dell'argomento è opportuno sottolineare ancora una volta che
221 in un sistema Unix l'unico modo in cui un programma può essere eseguito dal
222 kernel è attraverso la chiamata alla system call \func{execve} (o attraverso
223 una delle funzioni della famiglia \func{exec} che vedremo in
224 sez.~\ref{sec:proc_exec}).
226 Allo stesso modo l'unico modo in cui un programma può concludere
227 volontariamente la sua esecuzione è attraverso una chiamata alla system call
228 \func{\_exit}, o esplicitamente, o in maniera indiretta attraverso l'uso di
229 \func{exit} o il ritorno di \func{main}.
231 Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
232 normalmente un programma è riportato in fig.~\ref{fig:proc_prog_start_stop}.
236 \includegraphics[width=14cm]{img/proc_beginend}
237 \caption{Schema dell'avvio e della conclusione di un programma.}
238 \label{fig:proc_prog_start_stop}
241 Si ricordi infine che un programma può anche essere interrotto dall'esterno
242 attraverso l'uso di un segnale (modalità di conclusione non mostrata in
243 fig.~\ref{fig:proc_prog_start_stop}); torneremo su questo aspetto in
244 cap.~\ref{cha:signals}.
248 \section{I processi e l'uso della memoria}
249 \label{sec:proc_memory}
251 Una delle risorse base che ciascun processo ha a disposizione è la memoria, e
252 la gestione della memoria è appunto uno degli aspetti più complessi di un
253 sistema unix-like. In questa sezione, dopo una breve introduzione ai concetti
254 base, esamineremo come la memoria viene vista da parte di un programma in
255 esecuzione, e le varie funzioni utilizzabili per la sua gestione.
258 \subsection{I concetti generali}
259 \label{sec:proc_mem_gen}
261 Ci sono vari modi in cui i vari sistemi organizzano la memoria (ed i dettagli
262 di basso livello dipendono spesso in maniera diretta dall'architettura
263 dell'hardware), ma quello più tipico, usato dai sistemi unix-like come Linux è
264 la cosiddetta \textsl{memoria virtuale}\index{memoria~virtuale} che consiste
265 nell'assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare,
266 in cui gli indirizzi vanno da zero ad un qualche valore massimo.\footnote{nel
267 caso di Linux fino al kernel 2.2 detto massimo era, per macchine a 32bit, di
268 2Gb. Con il kernel 2.4 ed il supporto per la \textit{high-memory} il limite
269 è stato esteso anche per macchine a 32 bit.}
271 Come accennato in cap.~\ref{cha:intro_unix} questo spazio di indirizzi è
272 virtuale e non corrisponde all'effettiva posizione dei dati nella RAM del
273 computer; in genere detto spazio non è neppure continuo (cioè non tutti gli
274 indirizzi possibili sono utilizzabili, e quelli usabili non sono
275 necessariamente adiacenti).
277 Per la gestione da parte del kernel la memoria virtuale viene divisa in pagine
278 di dimensione fissa (che ad esempio sono di 4kb su macchine a 32 bit e 8kb
279 sulle alpha, valori strettamente connessi all'hardware di gestione della
280 memoria),\footnote{con le versioni più recenti del kernel è possibile anche
281 utilizzare pagine di dimensioni maggiori, per sistemi con grandi
282 quantitativi di memoria in cui l'uso di pagine troppo piccole comporta una
283 perdita di prestazioni.} e ciascuna pagina della memoria virtuale è
284 associata ad un supporto che può essere una pagina di memoria reale o ad un
285 dispositivo di stoccaggio secondario (in genere lo spazio disco riservato alla
286 swap, o i file che contengono il codice).
288 Lo stesso pezzo di memoria reale (o di spazio disco) può fare da supporto a
289 diverse pagine di memoria virtuale appartenenti a processi diversi (come
290 accade in genere per le pagine che contengono il codice delle librerie
291 condivise). Ad esempio il codice della funzione \func{printf} starà su una
292 sola pagina di memoria reale che farà da supporto a tutte le pagine di memoria
293 virtuale di tutti i processi che hanno detta funzione nel loro codice.
295 La corrispondenza fra le pagine della \index{memoria~virtuale}memoria virtuale
296 e quelle della memoria fisica della macchina viene gestita in maniera
297 trasparente dal kernel con l'ausilio dell'hardware di gestione della memoria
298 (la \textit{Memory Management Unit} del processore). Poiché in genere la
299 memoria fisica è solo una piccola frazione della memoria virtuale, è
300 necessario un meccanismo che permetta di trasferire le pagine che servono dal
301 supporto su cui si trovano in memoria, eliminando quelle che non servono.
302 Questo meccanismo è detto \textsl{paginazione}\index{paginazione} (o
303 \textit{paging}), ed è uno dei compiti principali del kernel.
305 Quando un processo cerca di accedere ad una pagina che non è nella memoria
306 reale, avviene quello che viene chiamato un \textit{page
307 fault}\itindex{page~fault}; la gestione della memoria genera un'interruzione
308 e passa il controllo al kernel il quale sospende il processo e si incarica di
309 mettere in RAM la pagina richiesta (effettuando tutte le operazioni necessarie
310 per reperire lo spazio necessario), per poi restituire il controllo al
313 Dal punto di vista di un processo questo meccanismo è completamente
314 trasparente, e tutto avviene come se tutte le pagine fossero sempre
315 disponibili in memoria. L'unica differenza avvertibile è quella dei tempi di
316 esecuzione, che passano dai pochi nanosecondi necessari per l'accesso in RAM,
317 a tempi molto più lunghi, dovuti all'intervento del kernel.
319 Normalmente questo è il prezzo da pagare per avere un multitasking reale, ed
320 in genere il sistema è molto efficiente in questo lavoro; quando però ci siano
321 esigenze specifiche di prestazioni è possibile usare delle funzioni che
322 permettono di bloccare il meccanismo della paginazione\index{paginazione} e
323 mantenere fisse delle pagine in memoria (vedi sez.~\ref{sec:proc_mem_lock}).
326 \subsection{La struttura della memoria di un processo}
327 \label{sec:proc_mem_layout}
329 Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
330 una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
331 tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
332 commette quando si è manipolato male un puntatore e genera quello che viene
333 chiamato un \textit{segmentation fault}. Se si tenta cioè di leggere o
334 scrivere da un indirizzo per il quale non esiste un'associazione della pagina
335 virtuale, il kernel risponde al relativo \textit{page
336 fault}\itindex{page~fault} mandando un segnale \const{SIGSEGV} al processo,
337 che normalmente ne causa la terminazione immediata.
339 È pertanto importante capire come viene strutturata \textsl{la memoria
340 virtuale}\index{memoria~virtuale} di un processo. Essa viene divisa in
341 \textsl{segmenti}, cioè un insieme contiguo di indirizzi virtuali ai quali il
342 processo può accedere. Solitamente un programma C viene suddiviso nei
346 \item Il segmento di testo o \textit{text segment}. Contiene il codice del
347 programma, delle funzioni di librerie da esso utilizzate, e le costanti.
348 Normalmente viene condiviso fra tutti i processi che eseguono lo stesso
349 programma (e anche da processi che eseguono altri programmi nel caso delle
350 librerie). Viene marcato in sola lettura per evitare sovrascritture
351 accidentali (o maliziose) che ne modifichino le istruzioni.
353 Viene allocato da \func{exec} all'avvio del programma e resta invariato
354 per tutto il tempo dell'esecuzione.
356 \item Il segmento dei dati o \textit{data segment}. Contiene le variabili
357 globali (cioè quelle definite al di fuori di tutte le funzioni che
358 compongono il programma) e le variabili statiche (cioè quelle dichiarate con
359 l'attributo \ctyp{static}). Di norma è diviso in due parti.
361 La prima parte è il segmento dei dati inizializzati, che contiene le
362 variabili il cui valore è stato assegnato esplicitamente. Ad esempio
364 \includecodesnip{listati/pi.c}
365 questo valore sarà immagazzinato in questo segmento. La memoria di questo
366 segmento viene preallocata all'avvio del programma e inizializzata ai valori
369 La seconda parte è il segmento dei dati non inizializzati, che contiene le
370 variabili il cui valore non è stato assegnato esplicitamente. Ad esempio se
372 \includecodesnip{listati/vect.c}
373 questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
374 allocato all'avvio, e tutte le variabili vengono inizializzate a zero (ed i
375 puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
376 variabili che vanno nel segmento dati, e non è affatto vero in generale.}
378 Storicamente questa seconda parte del segmento dati viene chiamata BSS (da
379 \textit{Block Started by Symbol}). La sua dimensione è fissa.
381 \item Lo \textit{heap}. Tecnicamente lo si può considerare l'estensione del
382 segmento dati, a cui di solito è posto giusto di seguito. È qui che avviene
383 l'allocazione dinamica della memoria; può essere ridimensionato allocando e
384 disallocando la memoria dinamica con le apposite funzioni (vedi
385 sez.~\ref{sec:proc_mem_alloc}), ma il suo limite inferiore (quello adiacente
386 al segmento dati) ha una posizione fissa.
388 \item Il segmento di \textit{stack}, che contiene lo \textit{stack} del
389 programma. Tutte le volte che si effettua una chiamata ad una funzione è
390 qui che viene salvato l'indirizzo di ritorno e le informazioni dello stato
391 del chiamante (tipo il contenuto di alcuni registri della CPU). Poi la
392 funzione chiamata alloca qui lo spazio per le sue variabili locali: in
393 questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
394 della funzione lo spazio è automaticamente rilasciato e
395 ``\textsl{ripulito}''. La pulizia in C e C++ viene fatta dal
396 chiamante.\footnote{a meno che non sia stato specificato l'utilizzo di una
397 calling convention diversa da quella standard.}
399 La dimensione di questo segmento aumenta seguendo la crescita dello stack
400 del programma, ma non viene ridotta quando quest'ultimo si restringe.
405 \includegraphics[height=11cm]{img/memory_layout}
406 \caption{Disposizione tipica dei segmenti di memoria di un processo.}
407 \label{fig:proc_mem_layout}
410 Una disposizione tipica di questi segmenti è riportata in
411 fig.~\ref{fig:proc_mem_layout}. Usando il comando \cmd{size} su un programma se
412 ne può stampare le dimensioni dei segmenti di testo e di dati (inizializzati e
413 BSS); si tenga presente però che il BSS non è mai salvato sul file che
414 contiene l'eseguibile, dato che viene sempre inizializzato a zero al
415 caricamento del programma.
418 \subsection{Allocazione della memoria per i programmi C}
419 \label{sec:proc_mem_alloc}
421 Il C supporta, a livello di linguaggio, soltanto due modalità di allocazione
422 della memoria: l'\textsl{allocazione statica} e l'\textsl{allocazione
425 L'\textsl{allocazione statica} è quella con cui sono memorizzate le variabili
426 globali e le variabili statiche, cioè le variabili il cui valore deve essere
427 mantenuto per tutta la durata del programma. Come accennato queste variabili
428 vengono allocate nel segmento dei dati all'avvio del programma (come parte
429 delle operazioni svolte da \func{exec}) e lo spazio da loro occupato non viene
430 liberato fino alla sua conclusione.
432 L'\textsl{allocazione automatica} è quella che avviene per gli argomenti di
433 una funzione e per le sue variabili locali (le cosiddette \textsl{variabili
434 automatiche}), che esistono solo per la durata della funzione. Lo spazio
435 per queste variabili viene allocato nello stack quando viene eseguita la
436 funzione e liberato quando si esce dalla medesima.
438 Esiste però un terzo tipo di allocazione, l'\textsl{allocazione dinamica}
439 della memoria, che non è prevista direttamente all'interno del linguaggio C,
440 ma che è necessaria quando il quantitativo di memoria che serve è
441 determinabile solo durante il corso dell'esecuzione del programma.
443 Il C non consente di usare variabili allocate dinamicamente, non è possibile
444 cioè definire in fase di programmazione una variabile le cui dimensioni
445 possano essere modificate durante l'esecuzione del programma. Per questo le
446 librerie del C forniscono una serie opportuna di funzioni per eseguire
447 l'allocazione dinamica di memoria (in genere nello heap). Le variabili il
448 cui contenuto è allocato in questo modo non potranno essere usate direttamente
449 come le altre, ma l'accesso sarà possibile solo in maniera indiretta,
450 attraverso dei puntatori.
453 \subsection{Le funzioni \func{malloc}, \func{calloc}, \func{realloc} e
455 \label{sec:proc_mem_malloc}
457 Le funzioni previste dallo standard ANSI C per la gestione della memoria sono
458 quattro: \funcd{malloc}, \funcd{calloc}, \funcd{realloc} e \funcd{free}, i
459 loro prototipi sono i seguenti:
462 \funcdecl{void *calloc(size\_t size)}
463 Alloca \param{size} byte nello heap. La memoria viene inizializzata a 0.
465 La funzione restituisce il puntatore alla zona di memoria allocata in caso
466 di successo e \val{NULL} in caso di fallimento, nel qual caso
467 \var{errno} assumerà il valore \errval{ENOMEM}.
468 \funcdecl{void *malloc(size\_t size)}
469 Alloca \param{size} byte nello heap. La memoria non viene inizializzata.
471 La funzione restituisce il puntatore alla zona di memoria allocata in caso
472 di successo e \val{NULL} in caso di fallimento, nel qual caso
473 \var{errno} assumerà il valore \errval{ENOMEM}.
474 \funcdecl{void *realloc(void *ptr, size\_t size)}
475 Cambia la dimensione del blocco allocato all'indirizzo \param{ptr}
476 portandola a \param{size}.
478 La funzione restituisce il puntatore alla zona di memoria allocata in caso
479 di successo e \val{NULL} in caso di fallimento, nel qual caso
480 \var{errno} assumerà il valore \errval{ENOMEM}.
481 \funcdecl{void free(void *ptr)}
482 Disalloca lo spazio di memoria puntato da \param{ptr}.
484 La funzione non ritorna nulla e non riporta errori.
486 Il puntatore ritornato dalle funzioni di allocazione è garantito essere sempre
487 allineato correttamente per tutti i tipi di dati; ad esempio sulle macchine a
488 32 bit in genere è allineato a multipli di 4 byte e sulle macchine a 64 bit a
491 In genere si usano le funzioni \func{malloc} e \func{calloc} per allocare
492 dinamicamente la quantità di memoria necessaria al programma indicata da
493 \param{size},\footnote{queste funzioni presentano un comportamento diverso fra
494 le \acr{glibc} e le \acr{uClib} quando il valore di \param{size} è nullo.
495 Nel primo caso viene comunque restituito un puntatore valido, anche se non è
496 chiaro a cosa esso possa fare riferimento, nel secondo caso viene restituito
497 \val{NULL}. Il comportamento è analogo con \code{realloc(NULL, 0)}.} e
498 siccome i puntatori ritornati sono di tipo generico non è necessario
499 effettuare un cast per assegnarli a puntatori al tipo di variabile per la
500 quale si effettua l'allocazione.
502 La memoria allocata dinamicamente deve essere esplicitamente rilasciata usando
503 \func{free}\footnote{le glibc provvedono anche una funzione \func{cfree}
504 definita per compatibilità con SunOS, che è deprecata.} una volta che non
505 sia più necessaria. Questa funzione vuole come argomento un puntatore
506 restituito da una precedente chiamata a una qualunque delle funzioni di
507 allocazione che non sia già stato liberato da un'altra chiamata a \func{free},
508 in caso contrario il comportamento della funzione è indefinito.
510 La funzione \func{realloc} si usa invece per cambiare (in genere aumentare) la
511 dimensione di un'area di memoria precedentemente allocata, la funzione vuole
512 in ingresso il puntatore restituito dalla precedente chiamata ad una
513 \func{malloc} (se è passato un valore \val{NULL} allora la funzione si
514 comporta come \func{malloc})\footnote{questo è vero per Linux e
515 l'implementazione secondo lo standard ANSI C, ma non è vero per alcune
516 vecchie implementazioni, inoltre alcune versioni delle librerie del C
517 consentivano di usare \func{realloc} anche per un puntatore liberato con
518 \func{free} purché non ci fossero state nel frattempo altre chiamate a
519 funzioni di allocazione, questa funzionalità è totalmente deprecata e non è
520 consentita sotto Linux.} ad esempio quando si deve far crescere la
521 dimensione di un vettore. In questo caso se è disponibile dello spazio
522 adiacente al precedente la funzione lo utilizza, altrimenti rialloca altrove
523 un blocco della dimensione voluta, copiandoci automaticamente il contenuto; lo
524 spazio aggiunto non viene inizializzato.
526 Si deve sempre avere ben presente il fatto che il blocco di memoria restituito
527 da \func{realloc} può non essere un'estensione di quello che gli si è passato
528 in ingresso; per questo si dovrà \emph{sempre} eseguire la riassegnazione di
529 \param{ptr} al valore di ritorno della funzione, e reinizializzare o provvedere
530 ad un adeguato aggiornamento di tutti gli altri puntatori all'interno del
531 blocco di dati ridimensionato.
533 Un errore abbastanza frequente (specie se si ha a che fare con vettori di
534 puntatori) è quello di chiamare \func{free} più di una volta sullo stesso
535 puntatore; per evitare questo problema una soluzione di ripiego è quella di
536 assegnare sempre a \val{NULL} ogni puntatore liberato con \func{free}, dato
537 che, quando l'argomento è un puntatore nullo, \func{free} non esegue nessuna
540 Le \acr{glibc} hanno un'implementazione delle routine di allocazione che è
541 controllabile dall'utente attraverso alcune variabili di ambiente, in
542 particolare diventa possibile tracciare questo tipo di errori usando la
543 variabile di ambiente \val{MALLOC\_CHECK\_} che quando viene definita mette in
544 uso una versione meno efficiente delle funzioni suddette, che però è più
545 tollerante nei confronti di piccoli errori come quello di chiamate doppie a
546 \func{free}. In particolare:
548 \item se la variabile è posta a zero gli errori vengono ignorati;
549 \item se è posta ad 1 viene stampato un avviso sullo \textit{standard error}
550 (vedi sez.~\ref{sec:file_std_stream});
551 \item se è posta a 2 viene chiamata \func{abort}, che in genere causa
552 l'immediata conclusione del programma.
555 Il problema più comune e più difficile da risolvere che si incontra con le
556 routine di allocazione è quando non viene opportunamente liberata la memoria
557 non più utilizzata, quello che in inglese viene chiamato \textit{memory
558 leak}\itindex{memory~leak}, cioè una \textsl{perdita di memoria}.
560 Un caso tipico che illustra il problema è quello in cui in una subroutine si
561 alloca della memoria per uso locale senza liberarla prima di uscire. La
562 memoria resta così allocata fino alla terminazione del processo. Chiamate
563 ripetute alla stessa subroutine continueranno ad effettuare altre allocazioni,
564 causando a lungo andare un esaurimento della memoria disponibile (e la
565 probabile impossibilità di proseguire l'esecuzione del programma).
567 Il problema è che l'esaurimento della memoria può avvenire in qualunque
568 momento, in corrispondenza ad una qualunque chiamata di \func{malloc}, che può
569 essere in una sezione del codice che non ha alcuna relazione con la subroutine
570 che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
571 \textit{memory leak}\itindex{memory~leak}.
573 In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
574 programmazione ad oggetti, il problema dei \textit{memory
575 leak}\itindex{memory~leak} è notevolmente ridimensionato attraverso l'uso
576 accurato di appositi oggetti come gli \textit{smartpointers}. Questo però in
577 genere va a scapito delle prestazioni dell'applicazione in esecuzione.
579 % In altri linguaggi come il java e recentemente il C\# il problema non si pone
580 % nemmeno perché la gestione della memoria viene fatta totalmente in maniera
581 % automatica, ovvero il programmatore non deve minimamente preoccuparsi di
582 % liberare la memoria allocata precedentemente quando non serve più, poiché
583 % l'infrastruttura del linguaggio gestisce automaticamente la cosiddetta
584 % \index{\textit{garbage~collection}}\textit{garbage collection}. In tal caso,
585 % attraverso meccanismi simili a quelli del \textit{reference counting}, quando
586 % una zona di memoria precedentemente allocata non è più riferita da nessuna
587 % parte del codice in esecuzione, può essere deallocata automaticamente in
588 % qualunque momento dall'infrastruttura.
590 % Anche questo va a scapito delle prestazioni dell'applicazione in esecuzione
591 % (inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
592 % eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
593 % la presenza di una infrastruttura per la loro interpretazione e pertanto hanno
594 % di per sé delle prestazioni più scadenti rispetto alle stesse applicazioni
595 % compilate direttamente). Questo comporta però il problema della non
596 % predicibilità del momento in cui viene deallocata la memoria precedentemente
597 % allocata da un oggetto.
599 Per limitare l'impatto di questi problemi, e semplificare la ricerca di
600 eventuali errori, l'implementazione delle routine di allocazione delle
601 \acr{glibc} mette a disposizione una serie di funzionalità che permettono di
602 tracciare le allocazioni e le disallocazioni, e definisce anche una serie di
603 possibili \textit{hook} (\textsl{ganci}) che permettono di sostituire alle
604 funzioni di libreria una propria versione (che può essere più o meno
605 specializzata per il debugging). Esistono varie librerie che forniscono dei
606 sostituti opportuni delle routine di allocazione in grado, senza neanche
607 ricompilare il programma,\footnote{esempi sono \textit{Dmalloc}
608 \href{http://dmalloc.com/}{\textsf{http://dmalloc.com/}} di Gray Watson ed
609 \textit{Electric Fence} di Bruce Perens.} di eseguire diagnostiche anche
610 molto complesse riguardo l'allocazione della memoria.
613 \subsection{Le funzioni \func{alloca}, \func{brk} e \func{sbrk}}
614 \label{sec:proc_mem_sbrk_alloca}
616 Una possibile alternativa all'uso di \func{malloc}, che non soffre dei
617 problemi di \textit{memory leak}\itindex{memory~leak} descritti in precedenza,
618 è la funzione \funcd{alloca}, che invece di allocare la memoria nello heap usa
619 il segmento di stack della funzione corrente. La sintassi è identica a quella
620 di \func{malloc}, il suo prototipo è:
621 \begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
622 Alloca \param{size} byte nello stack.
624 \bodydesc{La funzione restituisce il puntatore alla zona di memoria allocata
625 in caso di successo e \val{NULL} in caso di fallimento, nel qual caso
626 \var{errno} assumerà il valore \errval{ENOMEM}.}
629 La funzione alloca la quantità di memoria (non inizializzata) richiesta
630 dall'argomento \param{size} nel segmento di stack della funzione chiamante.
631 Con questa funzione non è più necessario liberare la memoria allocata (e
632 quindi non esiste un analogo della \func{free}) in quanto essa viene
633 rilasciata automaticamente al ritorno della funzione.
635 Come è evidente questa funzione ha molti vantaggi, anzitutto permette di
636 evitare alla radice i problemi di \textit{memory leak}\itindex{memory~leak},
637 dato che non serve più la deallocazione esplicita; inoltre la deallocazione
638 automatica funziona anche quando si usa \func{longjmp} per uscire da una
639 subroutine con un salto non locale da una funzione (vedi
640 sez.~\ref{sec:proc_longjmp}).
642 Un altro vantaggio è che in Linux la funzione è molto più veloce di
643 \func{malloc} e non viene sprecato spazio, infatti non è necessario gestire un
644 pool di memoria da riservare e si evitano così anche i problemi di
645 frammentazione di quest'ultimo, che comportano inefficienze sia
646 nell'allocazione della memoria che nell'esecuzione dell'allocazione.
648 Gli svantaggi sono che questa funzione non è disponibile su tutti gli Unix, e
649 non è inserita né nello standard POSIX né in SUSv3 (ma è presente in BSD), il
650 suo utilizzo quindi limita la portabilità dei programmi. Inoltre la funzione
651 non può essere usata nella lista degli argomenti di una funzione, perché lo
652 spazio verrebbe allocato nel mezzo degli stessi.
654 % Questo è riportato solo dal manuale delle glibc, nelle pagine di manuale non c'è
655 % traccia di tutto ciò
658 %cerca di allocare troppa memoria non si ottiene un messaggio di errore, ma un
659 %segnale di \textit{segment violation} analogo a quello che si avrebbe da una
660 %ricorsione infinita.
662 Inoltre non è chiaramente possibile usare \func{alloca} per allocare memoria
663 che deve poi essere usata anche al di fuori della funzione in cui essa viene
664 chiamata, dato che all'uscita dalla funzione lo spazio allocato diventerebbe
665 libero, e potrebbe essere sovrascritto all'invocazione di nuove funzioni.
666 Questo è lo stesso problema che si può avere con le variabili automatiche, su
667 cui torneremo in sez.~\ref{sec:proc_auto_var}.
670 Le due funzioni seguenti vengono utilizzate soltanto quando è necessario
671 effettuare direttamente la gestione della memoria associata allo spazio dati
672 di un processo, ad esempio qualora si debba implementare la propria versione
673 delle routine di allocazione della memoria viste in
674 sez.~\ref{sec:proc_mem_malloc}. La prima funzione è \funcd{brk}, ed il suo
676 \begin{prototype}{unistd.h}{int brk(void *end\_data\_segment)}
677 Sposta la fine del segmento dei dati.
679 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
680 fallimento, nel qual caso \var{errno} assumerà il valore \errval{ENOMEM}.}
683 La funzione è un'interfaccia diretta all'omonima system call ed imposta
684 l'indirizzo finale del segmento dati di un processo all'indirizzo specificato
685 da \param{end\_data\_segment}. Quest'ultimo deve essere un valore ragionevole,
686 ed inoltre la dimensione totale del segmento non deve comunque eccedere un
687 eventuale limite (si veda sez.~\ref{sec:sys_resource_limit}) imposto sulle
688 dimensioni massime dello spazio dati del processo.
690 La seconda funzione per la manipolazione delle dimensioni del segmento
691 dati\footnote{in questo caso si tratta soltanto di una funzione di libreria, e
692 non di una system call.} è \funcd{sbrk}, ed il suo prototipo è:
693 \begin{prototype}{unistd.h}{void *sbrk(ptrdiff\_t increment)}
694 Incrementa la dimensione dello spazio dati.
696 \bodydesc{La funzione restituisce il puntatore all'inizio della nuova zona
697 di memoria allocata in caso di successo e \val{NULL} in caso di
698 fallimento, nel qual caso \var{errno} assumerà il valore \errval{ENOMEM}.}
700 \noindent la funzione incrementa la dimensione lo spazio dati di un programma
701 di \param{increment} byte, restituendo il nuovo indirizzo finale dello stesso.
702 Un valore nullo permette di ottenere l'attuale posizione della fine del
705 Queste funzioni sono state deliberatamente escluse dallo standard POSIX.1 e
706 per i programmi normali è sempre opportuno usare le funzioni di allocazione
707 standard descritte in precedenza, che sono costruite su di esse.
710 % \subsection{La personalizzazione delle funzioni di allocazione}
711 % \label{sec:proc_mem_malloc_custom}
713 % TODO documentare \func{madvise}
714 % TODO documentare \func{mincore}
715 % TODO documentare \func{mprotect} forse da mettere insieme a mmap
717 \subsection{Il controllo della memoria virtuale}
718 \label{sec:proc_mem_lock}
720 \index{memoria~virtuale|(}
721 Come spiegato in sez.~\ref{sec:proc_mem_gen} il kernel gestisce la memoria
722 virtuale in maniera trasparente ai processi, decidendo quando rimuovere pagine
723 dalla memoria per metterle nello swap, sulla base dell'utilizzo corrente da
724 parte dei vari processi.
726 Nell'uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il
727 meccanismo della paginazione\index{paginazione} riporta in RAM, ed in maniera
728 trasparente, tutte le pagine che gli occorrono; esistono però esigenze
729 particolari in cui non si vuole che questo meccanismo si attivi. In generale i
730 motivi per cui si possono avere di queste necessità sono due:
732 \item \textsl{La velocità}. Il processo della paginazione\index{paginazione} è
733 trasparente solo se il programma in esecuzione non è sensibile al tempo che
734 occorre a riportare la pagina in memoria; per questo motivo processi critici
735 che hanno esigenze di tempo reale o tolleranze critiche nelle risposte (ad
736 esempio processi che trattano campionamenti sonori) possono non essere in
737 grado di sopportare le variazioni della velocità di accesso dovuta alla
740 In certi casi poi un programmatore può conoscere meglio dell'algoritmo di
741 allocazione delle pagine le esigenze specifiche del suo programma e decidere
742 quali pagine di memoria è opportuno che restino in memoria per un aumento
743 delle prestazioni. In genere queste sono esigenze particolari e richiedono
744 anche un aumento delle priorità in esecuzione del processo (vedi
745 sez.~\ref{sec:proc_real_time}).
747 \item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro
748 in memoria queste possono essere portate su disco dal meccanismo della
749 paginazione\index{paginazione}. Questo rende più lungo il periodo di tempo
750 in cui detti segreti sono presenti in chiaro e più complessa la loro
751 cancellazione (un processo può cancellare la memoria su cui scrive le sue
752 variabili, ma non può toccare lo spazio disco su cui una pagina di memoria
753 può essere stata salvata). Per questo motivo di solito i programmi di
754 crittografia richiedono il blocco di alcune pagine di memoria.
757 \itindbeg{memory~locking}
759 Il meccanismo che previene la paginazione\index{paginazione} di parte della
760 memoria virtuale di un processo è chiamato \textit{memory locking} (o
761 \textsl{blocco della memoria}). Il blocco è sempre associato alle pagine della
762 memoria virtuale del processo, e non al segmento reale di RAM su cui essa
763 viene mantenuta. La regola è che se un segmento di RAM fa da supporto ad
764 almeno una pagina bloccata allora esso viene escluso dal meccanismo della
765 paginazione\index{paginazione}. I blocchi non si accumulano, se si blocca due
766 volte la stessa pagina non è necessario sbloccarla due volte, una pagina o è
769 Il \textit{memory lock} persiste fintanto che il processo che detiene la
770 memoria bloccata non la sblocca. Chiaramente la terminazione del processo
771 comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
772 tutti i suoi \textit{memory lock}. Infine i \textit{memory lock} non sono
773 ereditati dai processi figli,\footnote{ma siccome Linux usa il
774 \itindex{copy~on~write}\textit{copy on write} (vedi
775 sez.~\ref{sec:proc_fork}) gli indirizzi virtuali del figlio sono mantenuti
776 sullo stesso segmento di RAM del padre, quindi fintanto che un figlio non
777 scrive su un segmento, può usufruire del \textit{memory lock} del padre.} e
778 vengono automaticamente rimossi se si pone in esecuzione un altro programma
779 con \func{exec} (vedi sez.~\ref{sec:proc_exec}).
781 Siccome la richiesta di un \textit{memory lock} da parte di un processo riduce
782 la memoria fisica disponibile nel sistema, questo ha un evidente impatto su
783 tutti gli altri processi, per cui fino al kernel 2.6.9 solo un processo con i
784 privilegi opportuni (la \itindex{capability}\textit{capability}
785 \const{CAP\_IPC\_LOCK}, vedi sez.~\ref{sec:proc_capabilities}) aveva la
786 capacità di bloccare una pagina.
788 Il sistema pone dei limiti all'ammontare di memoria di un processo che può
789 essere bloccata e al totale di memoria fisica che si può dedicare a questo, lo
790 standard POSIX.1 richiede che sia definita in \file{unistd.h} la macro
791 \macro{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
792 \textit{memory locking}. Inoltre in alcuni sistemi è definita la costante
793 \const{PAGE\_SIZE} in \file{limits.h} per indicare la dimensione di una pagina
794 in byte.\footnote{con Linux questo non avviene e si deve ricorrere alla
795 funzione \func{getpagesize}, vedi sez.~\ref{sec:sys_memory_res}.}
798 Con il kernel 2.6.9 anche un processo normale può bloccare la propria
799 memoria\footnote{la funzionalità è stata introdotta per non essere costretti a
800 dare privilegi eccessivi a programmi di crittografia, che necessitano di
801 questa funzionalità, ma che devono essere usati da utenti normali.} ma
802 mentre un processo privilegiato non ha limiti sulla quantità di memoria che
803 può bloccare, un processo normale è soggetto al limite della risorsa
804 \const{RLIMIT\_MEMLOCK} (vedi sez.~\ref{sec:sys_resource_limit}). In generale
805 poi ogni processo può sbloccare le pagine relative alla propria memoria, se
806 però diversi processi bloccano la stessa pagina questa resterà bloccata
807 fintanto che ci sarà almeno un processo che la blocca.
809 Le funzioni per bloccare e sbloccare la paginazione\index{paginazione} di
810 singole sezioni di memoria sono \funcd{mlock} e \funcd{munlock}; i loro
813 \headdecl{sys/mman.h}
815 \funcdecl{int mlock(const void *addr, size\_t len)}
816 Blocca la paginazione su un intervallo di memoria.
818 \funcdecl{int munlock(const void *addr, size\_t len)}
819 Rimuove il blocco della paginazione su un intervallo di memoria.
822 \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 in
823 caso di errore, nel qual caso \var{errno} assumerà uno dei
826 \item[\errcode{ENOMEM}] alcuni indirizzi dell'intervallo specificato non
827 corrispondono allo spazio di indirizzi del processo o si è ecceduto
828 il numero massimo consentito di pagine bloccate.
829 \item[\errcode{EINVAL}] \param{len} non è un valore positivo.
830 \item[\errcode{EPERM}] con un kernel successivo al 2.6.9 il processo non è
831 privilegiato e si un limite nullo per \const{RLIMIT\_MEMLOCK}.
833 e, per \func{mlock}, anche \errval{EPERM} quando il processo non ha i
834 privilegi richiesti per l'operazione.}
837 Le due funzioni permettono rispettivamente di bloccare e sbloccare la
838 paginazione\index{paginazione} per l'intervallo di memoria specificato dagli
839 argomenti, che ne indicano nell'ordine l'indirizzo iniziale e la lunghezza.
840 Tutte le pagine che contengono una parte dell'intervallo bloccato sono
841 mantenute in RAM per tutta la durata del blocco.\footnote{con altri kernel si
842 può ottenere un errore di \errcode{EINVAL} se \param{addr} non è un multiplo
843 della dimensione delle pagine di memoria.}
845 Altre due funzioni, \funcd{mlockall} e \funcd{munlockall}, consentono di
846 bloccare genericamente la paginazione\index{paginazione} per l'intero spazio
847 di indirizzi di un processo. I prototipi di queste funzioni sono:
849 \headdecl{sys/mman.h}
851 \funcdecl{int mlockall(int flags)}
852 Blocca la paginazione per lo spazio di indirizzi del processo corrente.
854 \funcdecl{int munlockall(void)}
855 Sblocca la paginazione per lo spazio di indirizzi del processo corrente.
857 \bodydesc{Codici di ritorno ed errori sono gli stessi di \func{mlock} e
858 \func{munlock}, con un kernel successivo al 2.6.9 l'uso di
859 func{munlockall} senza la la \itindex{capability}\textit{capability}
860 \const{CAP\_IPC\_LOCK} genera un errore di \errcode{EPERM}.}
863 L'argomento \param{flags} di \func{mlockall} permette di controllarne il
864 comportamento; esso può essere specificato come l'OR aritmetico delle due
866 \begin{basedescript}{\desclabelwidth{2.5cm}}
867 \item[\const{MCL\_CURRENT}] blocca tutte le pagine correntemente mappate nello
868 spazio di indirizzi del processo.
869 \item[\const{MCL\_FUTURE}] blocca tutte le pagine che verranno mappate nello
870 spazio di indirizzi del processo.
873 Con \func{mlockall} si possono bloccare tutte le pagine mappate nello spazio
874 di indirizzi del processo, sia che comprendano il segmento di testo, di dati,
875 lo stack, lo heap e pure le funzioni di libreria chiamate, i file mappati in
876 memoria, i dati del kernel mappati in user space, la memoria condivisa. L'uso
877 dei flag permette di selezionare con maggior finezza le pagine da bloccare, ad
878 esempio limitandosi a tutte le pagine allocate a partire da un certo momento.
880 In ogni caso un processo real-time che deve entrare in una sezione critica
881 deve provvedere a riservare memoria sufficiente prima dell'ingresso, per
882 scongiurare l'occorrenza di un eventuale \textit{page
883 fault}\itindex{page~fault} causato dal meccanismo di \textit{copy on
884 write}\itindex{copy~on~write}. Infatti se nella sezione critica si va ad
885 utilizzare memoria che non è ancora stata riportata in RAM si potrebbe avere
886 un \itindex{page~fault}\textit{page fault} durante l'esecuzione della stessa,
887 con conseguente rallentamento (probabilmente inaccettabile) dei tempi di
890 In genere si ovvia a questa problematica chiamando una funzione che ha
891 allocato una quantità sufficientemente ampia di variabili automatiche, in modo
892 che esse vengano mappate in RAM dallo stack, dopo di che, per essere sicuri
893 che esse siano state effettivamente portate in memoria, ci si scrive sopra.
894 \index{memoria~virtuale|)}
895 \itindend{memory~locking}
899 \section{Argomenti, opzioni ed ambiente di un processo}
900 \label{sec:proc_options}
902 Tutti i programmi hanno la possibilità di ricevere argomenti e opzioni quando
903 vengono lanciati. Il passaggio degli argomenti è effettuato attraverso gli
904 argomenti \param{argc} e \param{argv} della funzione \func{main}, che vengono
905 passati al programma dalla shell (o dal processo che esegue la \func{exec},
906 secondo le modalità che vedremo in sez.~\ref{sec:proc_exec}) quando questo
907 viene messo in esecuzione.
909 Oltre al passaggio degli argomenti, un'altra modalità che permette di passare
910 delle informazioni che modifichino il comportamento di un programma è quello
911 dell'uso del cosiddetto \textit{environment} (cioè l'uso delle
912 \textsl{variabili di ambiente}). In questa sezione esamineremo le funzioni che
913 permettono di gestire argomenti ed opzioni, e quelle che consentono di
914 manipolare ed utilizzare le variabili di ambiente.
917 \subsection{Il formato degli argomenti}
918 \label{sec:proc_par_format}
919 In genere il passaggio degli argomenti al programma viene effettuato dalla
920 shell, che si incarica di leggere la linea di comando e di effettuarne la
921 scansione (il cosiddetto \textit{parsing}) per individuare le parole che la
922 compongono, ciascuna delle quali viene considerata un argomento. Di norma per
923 individuare le parole viene usato come carattere di separazione lo spazio o il
924 tabulatore, ma il comportamento è modificabile attraverso l'impostazione della
925 variabile di ambiente \cmd{IFS}.
929 \includegraphics[width=13cm]{img/argv_argc}
930 \caption{Esempio dei valori di \param{argv} e \param{argc} generati nella
931 scansione di una riga di comando.}
932 \label{fig:proc_argv_argc}
935 Nella scansione viene costruito il vettore di puntatori \param{argv} inserendo
936 in successione il puntatore alla stringa costituente l'$n$-simo argomento; la
937 variabile \param{argc} viene inizializzata al numero di argomenti trovati, in
938 questo modo il primo argomento è sempre il nome del programma; un esempio di
939 questo meccanismo è mostrato in fig.~\ref{fig:proc_argv_argc}.
942 \subsection{La gestione delle opzioni}
943 \label{sec:proc_opt_handling}
945 In generale un programma Unix riceve da linea di comando sia gli argomenti che
946 le opzioni, queste ultime sono standardizzate per essere riconosciute come
947 tali: un elemento di \param{argv} che inizia con il carattere \texttt{'-'} e
948 che non sia un singolo \texttt{'-'} o un \texttt{'-{}-'} viene considerato
949 un'opzione. In genere le opzioni sono costituite da una lettera singola
950 (preceduta dal carattere \cmd{'-'}) e possono avere o no un parametro
951 associato; un comando tipico può essere quello mostrato in
952 fig.~\ref{fig:proc_argv_argc}. In quel caso le opzioni sono \cmd{-r} e \cmd{-m}
953 e la prima vuole un parametro mentre la seconda no (\cmd{questofile.txt} è un
954 argomento del programma, non un parametro di \cmd{-m}).
956 Per gestire le opzioni all'interno dei argomenti a linea di comando passati in
957 \param{argv} le librerie standard del C forniscono la funzione \funcd{getopt},
958 che ha il seguente prototipo:
959 \begin{prototype}{unistd.h}
960 {int getopt(int argc, char *const argv[], const char *optstring)}
961 Esegue il parsing degli argomenti passati da linea di comando
962 riconoscendo le possibili opzioni segnalate con \param{optstring}.
964 \bodydesc{Ritorna il carattere che segue l'opzione, \cmd{':'} se manca un
965 parametro all'opzione, \cmd{'?'} se l'opzione è sconosciuta, e -1 se non
966 esistono altre opzioni.}
969 Questa funzione prende come argomenti le due variabili \param{argc} e
970 \param{argv} passate a \func{main} ed una stringa che indica quali sono le
971 opzioni valide; la funzione effettua la scansione della lista degli argomenti
972 ricercando ogni stringa che comincia con \cmd{-} e ritorna ogni volta che
973 trova un'opzione valida.
975 La stringa \param{optstring} indica quali sono le opzioni riconosciute ed è
976 costituita da tutti i caratteri usati per identificare le singole opzioni, se
977 l'opzione ha un parametro al carattere deve essere fatto seguire un segno di
978 due punti \texttt{':'}; nel caso di fig.~\ref{fig:proc_argv_argc} ad esempio la
979 stringa di opzioni avrebbe dovuto contenere \texttt{"r:m"}.
981 La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
982 funzione all'interno di un ciclo, fintanto che essa non ritorna il valore -1
983 che indica che non ci sono più opzioni. Nel caso si incontri un'opzione non
984 dichiarata in \param{optstring} viene ritornato il carattere \texttt{'?'}
985 mentre se un'opzione che lo richiede non è seguita da un parametro viene
986 ritornato il carattere \texttt{':'}, infine se viene incontrato il valore
987 \texttt{'-{}-'} la scansione viene considerata conclusa, anche se vi sono altri
988 elementi di \param{argv} che cominciano con il carattere \texttt{'-'}.
991 \footnotesize \centering
992 \begin{minipage}[c]{15.6cm}
993 \includecodesample{listati/option_code.c}
996 \caption{Esempio di codice per la gestione delle opzioni.}
997 \label{fig:proc_options_code}
1000 Quando la funzione trova un'opzione essa ritorna il valore numerico del
1001 carattere, in questo modo si possono eseguire azioni specifiche usando uno
1002 \code{switch}; \func{getopt} inoltre inizializza alcune variabili globali:
1004 \item \var{char *optarg} contiene il puntatore alla stringa parametro
1006 \item \var{int optind} alla fine della scansione restituisce l'indice del
1007 primo elemento di \param{argv} che non è un'opzione.
1008 \item \var{int opterr} previene, se posto a zero, la stampa di un messaggio
1009 di errore in caso di riconoscimento di opzioni non definite.
1010 \item \var{int optopt} contiene il carattere dell'opzione non riconosciuta.
1013 In fig.~\ref{fig:proc_options_code} è mostrata la sezione del programma
1014 \file{ForkTest.c} (che useremo nel prossimo capitolo per effettuare dei test
1015 sulla creazione dei processi) deputata alla decodifica delle opzioni a riga di
1018 Si può notare che si è anzitutto (\texttt{\small 1}) disabilitata la stampa di
1019 messaggi di errore per opzioni non riconosciute, per poi passare al ciclo per
1020 la verifica delle opzioni (\texttt{\small 2-27}); per ciascuna delle opzioni
1021 possibili si è poi provveduto ad un'azione opportuna, ad esempio per le tre
1022 opzioni che prevedono un parametro si è effettuata la decodifica del medesimo
1023 (il cui indirizzo è contenuto nella variabile \var{optarg}) avvalorando la
1024 relativa variabile (\texttt{\small 12-14}, \texttt{\small 15-17} e
1025 \texttt{\small 18-20}). Completato il ciclo troveremo in \var{optind} l'indice
1026 in \code{argv[]} del primo degli argomenti rimanenti nella linea di comando.
1028 Normalmente \func{getopt} compie una permutazione degli elementi di
1029 \param{argv} cosicché alla fine della scansione gli elementi che non sono
1030 opzioni sono spostati in coda al vettore. Oltre a questa esistono altre due
1031 modalità di gestire gli elementi di \param{argv}; se \param{optstring} inizia
1032 con il carattere \texttt{'+'} (o è impostata la variabile di ambiente
1033 \macro{POSIXLY\_CORRECT}) la scansione viene fermata non appena si incontra un
1034 elemento che non è un'opzione. L'ultima modalità, usata quando un programma
1035 può gestire la mescolanza fra opzioni e argomenti, ma se li aspetta in un
1036 ordine definito, si attiva quando \param{optstring} inizia con il carattere
1037 \texttt{'-'}. In questo caso ogni elemento che non è un'opzione viene
1038 considerato comunque un'opzione e associato ad un valore di ritorno pari ad 1,
1039 questo permette di identificare gli elementi che non sono opzioni, ma non
1040 effettua il riordinamento del vettore \param{argv}.
1043 \subsection{Opzioni in formato esteso}
1044 \label{sec:proc_opt_extended}
1046 Un'estensione di questo schema è costituita dalle cosiddette
1047 \textit{long-options} espresse nella forma \cmd{-{}-option=parameter}, anche
1048 la gestione di queste ultime è stata standardizzata attraverso l'uso di una
1049 versione estesa di \func{getopt}.
1051 (NdA: questa parte verrà inserita in seguito).
1054 \subsection{Le variabili di ambiente}
1055 \label{sec:proc_environ}
1057 Oltre agli argomenti passati a linea di comando ogni processo riceve dal
1058 sistema un \textsl{ambiente}, nella forma di una lista di variabili (detta
1059 \textit{environment list}) messa a disposizione dal processo, e costruita
1060 nella chiamata alla funzione \func{exec} quando questo viene lanciato.
1062 Come per la lista degli argomenti anche questa lista è un vettore di puntatori
1063 a caratteri, ciascuno dei quali punta ad una stringa, terminata da un
1064 \val{NULL}. A differenza di \code{argv[]} in questo caso non si ha una
1065 lunghezza del vettore data da un equivalente di \param{argc}, ma la lista è
1066 terminata da un puntatore nullo.
1068 L'indirizzo della lista delle variabili di ambiente è passato attraverso la
1069 variabile globale \var{environ}, a cui si può accedere attraverso una semplice
1070 dichiarazione del tipo:
1071 \includecodesnip{listati/env_ptr.c}
1072 un esempio della struttura di questa lista, contenente alcune delle variabili
1073 più comuni che normalmente sono definite dal sistema, è riportato in
1074 fig.~\ref{fig:proc_envirno_list}.
1077 \includegraphics[width=13cm]{img/environ_var}
1078 \caption{Esempio di lista delle variabili di ambiente.}
1079 \label{fig:proc_envirno_list}
1082 Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
1083 \textsl{\texttt{nome=valore}}. Inoltre alcune variabili, come quelle elencate
1084 in fig.~\ref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
1085 da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
1086 usare nomi espressi in caratteri maiuscoli.\footnote{la convenzione vuole che
1087 si usino dei nomi maiuscoli per le variabili di ambiente di uso generico, i
1088 nomi minuscoli sono in genere riservati alle variabili interne degli script
1091 Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
1092 riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
1093 costituiscono un modo comodo per definire un comportamento specifico senza
1094 dover ricorrere all'uso di opzioni a linea di comando o di file di
1095 configurazione. É di norma cura della shell, quando esegue un comando, passare
1096 queste variabili al programma messo in esecuzione attraverso un uso opportuno
1097 delle relative chiamate (si veda sez.~\ref{sec:proc_exec}).
1099 La shell ad esempio ne usa molte per il suo funzionamento (come \texttt{PATH}
1100 per la ricerca dei comandi, o \texttt{IFS} per la scansione degli argomenti),
1101 e alcune di esse (come \texttt{HOME}, \texttt{USER}, ecc.) sono definite al
1102 login (per i dettagli si veda sez.~\ref{sec:sess_login}). In genere è cura
1103 dell'amministratore definire le opportune variabili di ambiente in uno script
1104 di avvio. Alcune servono poi come riferimento generico per molti programmi
1105 (come \texttt{EDITOR} che indica l'editor preferito da invocare in caso di
1108 Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
1109 comuni), come riportato in tab.~\ref{tab:proc_env_var}. GNU/Linux le supporta
1110 tutte e ne definisce anche altre: per una lista più completa si può
1111 controllare \cmd{man 5 environ}.
1116 \begin{tabular}[c]{|l|c|c|c|p{7cm}|}
1118 \textbf{Variabile} & \textbf{POSIX} & \textbf{XPG3}
1119 & \textbf{Linux} & \textbf{Descrizione} \\
1122 \texttt{USER} &$\bullet$&$\bullet$&$\bullet$& Nome utente\\
1123 \texttt{LOGNAME}&$\bullet$&$\bullet$&$\bullet$& Nome di login\\
1124 \texttt{HOME} &$\bullet$&$\bullet$&$\bullet$& Directory base
1126 \texttt{LANG} &$\bullet$&$\bullet$&$\bullet$& Localizzazione\\
1127 \texttt{PATH} &$\bullet$&$\bullet$&$\bullet$& Elenco delle directory
1129 \texttt{PWD} &$\bullet$&$\bullet$&$\bullet$& Directory corrente\\
1130 \texttt{SHELL} &$\bullet$&$\bullet$&$\bullet$& Shell in uso\\
1131 \texttt{TERM} &$\bullet$&$\bullet$&$\bullet$& Tipo di terminale\\
1132 \texttt{PAGER} &$\bullet$&$\bullet$&$\bullet$& Programma per vedere i
1134 \texttt{EDITOR} &$\bullet$&$\bullet$&$\bullet$& Editor preferito\\
1135 \texttt{BROWSER}&$\bullet$&$\bullet$&$\bullet$& Browser preferito\\
1136 \texttt{TMPDIR} &$\bullet$&$\bullet$&$\bullet$& Directory dei file
1140 \caption{Esempi delle variabili di ambiente più comuni definite da vari
1142 \label{tab:proc_env_var}
1145 Lo standard ANSI C prevede l'esistenza di un ambiente, e pur non entrando
1146 nelle specifiche di come sono strutturati i contenuti, definisce la funzione
1147 \funcd{getenv} che permette di ottenere i valori delle variabili di ambiente;
1149 \begin{prototype}{stdlib.h}{char *getenv(const char *name)}
1150 Esamina l'ambiente del processo cercando una stringa che corrisponda a
1151 quella specificata da \param{name}.
1153 \bodydesc{La funzione ritorna \val{NULL} se non trova nulla, o il
1154 puntatore alla stringa che corrisponde (di solito nella forma
1155 \cmd{NOME=valore}).}
1158 Oltre a questa funzione di lettura, che è l'unica definita dallo standard ANSI
1159 C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
1160 utilizzare per impostare e per cancellare le variabili di ambiente. Uno schema
1161 delle funzioni previste nei vari standard e disponibili in Linux è riportato
1162 in tab.~\ref{tab:proc_env_func}.
1167 \begin{tabular}[c]{|l|c|c|c|c|c|c|}
1169 \textbf{Funzione} & \textbf{ANSI C} & \textbf{POSIX.1} & \textbf{XPG3} &
1170 \textbf{SVr4} & \textbf{BSD} & \textbf{Linux} \\
1173 \func{getenv} & $\bullet$ & $\bullet$ & $\bullet$
1174 & $\bullet$ & $\bullet$ & $\bullet$ \\
1175 \func{setenv} & -- & -- & --
1176 & -- & $\bullet$ & $\bullet$ \\
1177 \func{unsetenv}& -- & -- & --
1178 & -- & $\bullet$ & $\bullet$ \\
1179 \func{putenv} & -- & opz. & $\bullet$
1180 & -- & $\bullet$ & $\bullet$ \\
1181 \func{clearenv}& -- & opz. & --
1182 & -- & -- & $\bullet$ \\
1185 \caption{Funzioni per la gestione delle variabili di ambiente.}
1186 \label{tab:proc_env_func}
1189 In Linux\footnote{in realtà nelle libc4 e libc5 sono definite solo le prime
1190 quattro, \func{clearenv} è stata introdotta con le \acr{glibc} 2.0.} sono
1191 definite tutte le funzioni elencate in tab.~\ref{tab:proc_env_func}. La prima,
1192 \func{getenv}, l'abbiamo appena esaminata; delle restanti le prime due,
1193 \funcd{putenv} e \funcd{setenv}, servono per assegnare nuove variabili di
1194 ambiente, i loro prototipi sono i seguenti:
1198 \funcdecl{int setenv(const char *name, const char *value, int overwrite)}
1199 Imposta la variabile di ambiente \param{name} al valore \param{value}.
1201 \funcdecl{int putenv(char *string)} Aggiunge la stringa \param{string}
1204 \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 per un
1205 errore, che è sempre \errval{ENOMEM}.}
1207 \noindent la terza, \funcd{unsetenv}, serve a cancellare una variabile di
1208 ambiente; il suo prototipo è:
1212 \funcdecl{void unsetenv(const char *name)} Rimuove la variabile di ambiente
1215 \noindent questa funzione elimina ogni occorrenza della variabile specificata;
1216 se essa non esiste non succede nulla. Non è prevista (dato che la funzione è
1217 \ctyp{void}) nessuna segnalazione di errore.
1219 Per modificare o aggiungere una variabile di ambiente si possono usare sia
1220 \func{setenv} che \func{putenv}. La prima permette di specificare
1221 separatamente nome e valore della variabile di ambiente, inoltre il valore di
1222 \param{overwrite} specifica il comportamento della funzione nel caso la
1223 variabile esista già, sovrascrivendola se diverso da zero, lasciandola
1224 immutata se uguale a zero.
1226 La seconda funzione prende come argomento una stringa analoga a quella
1227 restituita da \func{getenv}, e sempre nella forma \code{NOME=valore}. Se la
1228 variabile specificata non esiste la stringa sarà aggiunta all'ambiente, se
1229 invece esiste il suo valore sarà impostato a quello specificato da
1230 \param{string}. Si tenga presente che, seguendo lo standard SUSv2, le
1231 \acr{glibc} successive alla versione 2.1.2 aggiungono\footnote{il
1232 comportamento è lo stesso delle vecchie \acr{libc4} e \acr{libc5}; nelle
1233 \acr{glibc}, dalla versione 2.0 alla 2.1.1, veniva invece fatta una copia,
1234 seguendo il comportamento di BSD4.4; dato che questo può dar luogo a perdite
1235 di memoria e non rispetta lo standard. Il comportamento è stato modificato a
1236 partire dalle 2.1.2, eliminando anche, sempre in conformità a SUSv2,
1237 l'attributo \direct{const} dal prototipo.} \param{string} alla lista delle
1238 variabili di ambiente; pertanto ogni cambiamento alla stringa in questione si
1239 riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
1240 questa funzione una variabile automatica (per evitare i problemi esposti in
1241 sez.~\ref{sec:proc_auto_var}).
1243 Si tenga infine presente che se si passa a \func{putenv} solo il nome di una
1244 variabile (cioè \param{string} è nella forma \texttt{NAME} e non contiene un
1245 carattere \texttt{'='}) allora questa viene cancellata dall'ambiente. Infine
1246 se la chiamata di \func{putenv} comporta la necessità di allocare una nuova
1247 versione del vettore \var{environ} questo sarà allocato, ma la versione
1248 corrente sarà deallocata solo se anch'essa è risultante da un'allocazione
1249 fatta in precedenza da un'altra \func{putenv}. Questo perché il vettore delle
1250 variabili di ambiente iniziale, creato dalla chiamata ad \func{exec} (vedi
1251 sez.~\ref{sec:proc_exec}) è piazzato al di sopra dello stack, (vedi
1252 fig.~\ref{fig:proc_mem_layout}) e non nello heap e non può essere deallocato.
1253 Inoltre la memoria associata alle variabili di ambiente eliminate non viene
1256 L'ultima funzione è \funcd{clearenv}, che viene usata per cancellare
1257 completamente tutto l'ambiente; il suo prototipo è:
1261 \funcdecl{int clearenv(void)}
1262 Cancella tutto l'ambiente.
1264 \bodydesc{la funzione restituisce 0 in caso di successo e un valore diverso
1265 da zero per un errore.}
1268 In genere si usa questa funzione in maniera precauzionale per evitare i
1269 problemi di sicurezza connessi nel trasmettere ai programmi che si invocano un
1270 ambiente che può contenere dei dati non controllati. In tal caso si provvede
1271 alla cancellazione di tutto l'ambiente per costruirne una versione
1272 ``\textsl{sicura}'' da zero.
1275 \section{Problematiche di programmazione generica}
1276 \label{sec:proc_gen_prog}
1278 Benché questo non sia un libro di C, è opportuno affrontare alcune delle
1279 problematiche generali che possono emergere nella programmazione e di quali
1280 precauzioni o accorgimenti occorre prendere per risolverle. Queste
1281 problematiche non sono specifiche di sistemi unix-like o multitasking, ma
1282 avendo trattato in questo capitolo il comportamento dei processi visti come
1283 entità a sé stanti, le riportiamo qui.
1286 \subsection{Il passaggio delle variabili e dei valori di ritorno}
1287 \label{sec:proc_var_passing}
1289 Una delle caratteristiche standard del C è che le variabili vengono passate
1290 alle subroutine attraverso un meccanismo che viene chiamato \textit{by value}
1291 (diverso ad esempio da quanto avviene con il Fortran, dove le variabili sono
1292 passate, come suol dirsi, \textit{by reference}, o dal C++ dove la modalità
1293 del passaggio può essere controllata con l'operatore \cmd{\&}).
1295 Il passaggio di una variabile \textit{by value} significa che in realtà quello
1296 che viene passato alla subroutine è una copia del valore attuale di quella
1297 variabile, copia che la subroutine potrà modificare a piacere, senza che il
1298 valore originale nella routine chiamante venga toccato. In questo modo non
1299 occorre preoccuparsi di eventuali effetti delle operazioni della subroutine
1300 sulla variabile passata come argomento.
1302 Questo però va inteso nella maniera corretta. Il passaggio \textit{by value}
1303 vale per qualunque variabile, puntatori compresi; quando però in una
1304 subroutine si usano dei puntatori (ad esempio per scrivere in un buffer) in
1305 realtà si va a modificare la zona di memoria a cui essi puntano, per cui anche
1306 se i puntatori sono copie, i dati a cui essi puntano sono sempre gli stessi, e
1307 le eventuali modifiche avranno effetto e saranno visibili anche nella routine
1310 Nella maggior parte delle funzioni di libreria e delle system call i puntatori
1311 vengono usati per scambiare dati (attraverso buffer o strutture) e le
1312 variabili semplici vengono usate per specificare argomenti; in genere le
1313 informazioni a riguardo dei risultati vengono passate alla routine chiamante
1314 attraverso il valore di ritorno. È buona norma seguire questa pratica anche
1315 nella programmazione normale.
1317 Talvolta però è necessario che la funzione possa restituire indietro alla
1318 funzione chiamante un valore relativo ad uno dei suoi argomenti. Per far
1319 questo si usa il cosiddetto \itindex{value~result~argument}\textit{value
1320 result argument}, si passa cioè, invece di una normale variabile, un
1321 puntatore alla stessa; vedremo alcuni esempi di questa modalità nelle funzioni
1322 che gestiscono i socket (in sez.~\ref{sec:TCP_functions}), in cui, per
1323 permettere al kernel di restituire informazioni sulle dimensioni delle
1324 strutture degli indirizzi utilizzate, viene usato questo meccanismo.
1327 \subsection{Il passaggio di un numero variabile di argomenti}
1328 \label{sec:proc_variadic}
1330 Come vedremo nei capitoli successivi, non sempre è possibile specificare un
1331 numero fisso di argomenti per una funzione. Lo standard ISO C prevede nella
1332 sua sintassi la possibilità di definire delle \textit{variadic
1333 function}\index{variadic} che abbiano un numero variabile di argomenti,
1334 attraverso l'uso nella dichiarazione della funzione dello speciale costrutto
1335 ``\texttt{\textellipsis}'', che viene chiamato \textit{ellipsis}.
1337 Lo standard però non provvede a livello di linguaggio alcun meccanismo con cui
1338 dette funzioni possono accedere ai loro argomenti. L'accesso viene pertanto
1339 realizzato a livello delle librerie standard del C che provvedono gli
1340 strumenti adeguati. L'uso di una \textit{variadic function} prevede quindi
1343 \item \textsl{Dichiarare} la funzione come \textit{variadic} usando un
1344 prototipo che contenga una \textit{ellipsis}.
1345 \item \textsl{Definire} la funzione come \textit{variadic} usando la stessa
1346 \textit{ellipsis}, ed utilizzare le apposite macro che consentono la
1347 gestione di un numero variabile di argomenti.
1348 \item \textsl{Invocare} la funzione specificando prima gli argomenti fissi, ed
1349 a seguire quelli addizionali.
1352 Lo standard ISO C prevede che una \textit{variadic function}\index{variadic}
1353 abbia sempre almeno un argomento fisso; prima di effettuare la dichiarazione
1354 deve essere incluso l'apposito header file \file{stdarg.h}; un esempio di
1355 dichiarazione è il prototipo della funzione \func{execl} che vedremo in
1356 sez.~\ref{sec:proc_exec}:
1357 \includecodesnip{listati/exec_sample.c}
1358 in questo caso la funzione prende due argomenti fissi ed un numero variabile
1359 di altri argomenti (che verranno a costituire gli elementi successivi al primo
1360 del vettore \param{argv} passato al nuovo processo). Lo standard ISO C
1361 richiede inoltre che l'ultimo degli argomenti fissi sia di tipo
1362 \textit{self-promoting}\footnote{il linguaggio C prevede che quando si
1363 mescolano vari tipi di dati, alcuni di essi possano essere \textsl{promossi}
1364 per compatibilità; ad esempio i tipi \ctyp{float} vengono convertiti
1365 automaticamente a \ctyp{double} ed i \ctyp{char} e gli \ctyp{short} ad
1366 \ctyp{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
1367 a sé stesso.} il che esclude vettori, puntatori a funzioni e interi di tipo
1368 \ctyp{char} o \ctyp{short} (con segno o meno). Una restrizione ulteriore di
1369 alcuni compilatori è di non dichiarare l'ultimo argomento fisso come
1372 Una volta dichiarata la funzione il secondo passo è accedere ai vari argomenti
1373 quando la si va a definire. Gli argomenti fissi infatti hanno un loro nome, ma
1374 quelli variabili vengono indicati in maniera generica dalla \textit{ellipsis}.
1376 L'unica modalità in cui essi possono essere recuperati è pertanto quella
1377 sequenziale; essi verranno estratti dallo stack secondo l'ordine in cui sono
1378 stati scritti. Per fare questo in \file{stdarg.h} sono definite delle apposite
1379 macro; la procedura da seguire è la seguente:
1381 \item Inizializzare un puntatore alla lista degli argomenti di tipo
1382 \macro{va\_list} attraverso la macro \macro{va\_start}.
1383 \item Accedere ai vari argomenti opzionali con chiamate successive alla macro
1384 \macro{va\_arg}, la prima chiamata restituirà il primo argomento, la seconda
1385 il secondo e così via.
1386 \item Dichiarare la conclusione dell'estrazione degli argomenti invocando la
1387 macro \macro{va\_end}.
1389 In generale è perfettamente legittimo richiedere meno argomenti di quelli che
1390 potrebbero essere stati effettivamente forniti, e nella esecuzione delle
1391 \macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
1392 saranno ignorati; se invece si richiedono più argomenti di quelli forniti si
1393 otterranno dei valori indefiniti. Nel caso del \cmd{gcc} l'uso della macro
1394 \macro{va\_end} è inutile, ma si consiglia di usarlo ugualmente per
1397 Le definizioni delle tre macro sono le seguenti:
1401 \funcdecl{void va\_start(va\_list ap, last)} Inizializza il puntatore alla
1402 lista di argomenti \param{ap}; il parametro \param{last} \emph{deve} essere
1403 l'ultimo degli argomenti fissi.
1405 \funcdecl{type va\_arg(va\_list ap, type)} Restituisce il valore del
1406 successivo argomento opzionale, modificando opportunamente \param{ap}; la
1407 macro richiede che si specifichi il tipo dell'argomento attraverso il
1408 parametro \param{type} che deve essere il nome del tipo dell'argomento in
1409 questione. Il tipo deve essere \textit{self-promoting}.
1411 \funcdecl{void va\_end(va\_list ap)} Conclude l'uso di \param{ap}.
1414 In generale si possono avere più puntatori alla lista degli argomenti,
1415 ciascuno andrà inizializzato con \macro{va\_start} e letto con \macro{va\_arg}
1416 e ciascuno potrà scandire la lista degli argomenti per conto suo.
1418 Dopo l'uso di \macro{va\_end} la variabile \param{ap} diventa indefinita e
1419 successive chiamate a \macro{va\_arg} non funzioneranno. Si avranno risultati
1420 indefiniti anche chiamando \macro{va\_arg} specificando un tipo che non
1421 corrisponde a quello dell'argomento.
1423 Un altro limite delle macro è che i passi 1) e 3) devono essere eseguiti nel
1424 corpo principale della funzione, il passo 2) invece può essere eseguito anche
1425 in una subroutine passandole il puntatore alla lista di argomenti; in questo
1426 caso però si richiede che al ritorno della funzione il puntatore non venga più
1427 usato (lo standard richiederebbe la chiamata esplicita di \macro{va\_end}),
1428 dato che il valore di \param{ap} risulterebbe indefinito.
1430 Esistono dei casi in cui è necessario eseguire più volte la scansione degli
1431 argomenti e poter memorizzare una posizione durante la stessa. La cosa più
1432 naturale in questo caso sembrerebbe quella di copiarsi il puntatore alla lista
1433 degli argomenti con una semplice assegnazione. Dato che una delle
1434 realizzazioni più comuni di \macro{va\_list} è quella di un puntatore nello
1435 stack all'indirizzo dove sono stati salvati gli argomenti, è assolutamente
1436 normale pensare di poter effettuare questa operazione.
1438 In generale però possono esistere anche realizzazioni diverse, per questo
1439 motivo \macro{va\_list} è definito come \textsl{tipo opaco}\index{tipo!opaco}
1440 e non può essere assegnato direttamente ad un'altra variabile dello stesso
1441 tipo. Per risolvere questo problema lo standard ISO C99\footnote{alcuni
1442 sistemi che non hanno questa macro provvedono al suo posto
1443 \macro{\_\_va\_copy} che era il nome proposto in una bozza dello standard.}
1444 ha previsto una macro ulteriore che permette di eseguire la copia di un
1445 puntatore alla lista degli argomenti:
1446 \begin{prototype}{stdarg.h}{void va\_copy(va\_list dest, va\_list src)}
1447 Copia l'attuale valore \param{src} del puntatore alla lista degli argomenti
1450 \noindent anche in questo caso è buona norma chiudere ogni esecuzione di una
1451 \macro{va\_copy} con una corrispondente \macro{va\_end} sul nuovo puntatore
1452 alla lista degli argomenti.
1454 La chiamata di una funzione con un numero variabile di argomenti, posto che la
1455 si sia dichiarata e definita come tale, non prevede nulla di particolare;
1456 l'invocazione è identica alle altre, con gli argomenti, sia quelli fissi che
1457 quelli opzionali, separati da virgole. Quello che però è necessario tenere
1458 presente è come verranno convertiti gli argomenti variabili.
1460 In Linux gli argomenti dello stesso tipo sono passati allo stesso modo, sia
1461 che siano fissi sia che siano opzionali (alcuni sistemi trattano diversamente
1462 gli opzionali), ma dato che il prototipo non può specificare il tipo degli
1463 argomenti opzionali, questi verranno sempre promossi, pertanto nella ricezione
1464 dei medesimi occorrerà tenerne conto (ad esempio un \ctyp{char} verrà visto da
1465 \macro{va\_arg} come \ctyp{int}).
1467 Uno dei problemi che si devono affrontare con le funzioni con un numero
1468 variabile di argomenti è che non esiste un modo generico che permetta di
1469 stabilire quanti sono gli argomenti passati effettivamente in una chiamata.
1471 Esistono varie modalità per affrontare questo problema; una delle più
1472 immediate è quella di specificare il numero degli argomenti opzionali come uno
1473 degli argomenti fissi. Una variazione di questo metodo è l'uso di un argomento
1474 per specificare anche il tipo degli argomenti (come fa la stringa di formato
1477 Una modalità diversa, che può essere applicata solo quando il tipo degli
1478 argomenti lo rende possibile, è quella che prevede di usare un valore speciale
1479 come ultimo argomento (come fa ad esempio \func{execl} che usa un puntatore
1480 \val{NULL} per indicare la fine della lista degli argomenti).
1483 \subsection{Potenziali problemi con le variabili automatiche}
1484 \label{sec:proc_auto_var}
1486 Uno dei possibili problemi che si possono avere con le subroutine è quello di
1487 restituire alla funzione chiamante dei dati che sono contenuti in una
1488 variabile automatica. Ovviamente quando la subroutine ritorna la sezione
1489 dello stack che conteneva la variabile automatica potrà essere riutilizzata da
1490 una nuova funzione, con le immaginabili conseguenze di sovrapposizione e
1491 sovrascrittura dei dati.
1493 Per questo una delle regole fondamentali della programmazione in C è che
1494 all'uscita di una funzione non deve restare nessun riferimento alle variabili
1495 locali; qualora sia necessario utilizzare variabili che possano essere viste
1496 anche dalla funzione chiamante queste devono essere allocate esplicitamente, o
1497 in maniera statica (usando variabili di tipo \ctyp{static} o \ctyp{extern}), o
1498 dinamicamente con una delle funzioni della famiglia \func{malloc}.
1501 \subsection{Il controllo di flusso non locale}
1502 \label{sec:proc_longjmp}
1504 Il controllo del flusso di un programma in genere viene effettuato con le
1505 varie istruzioni del linguaggio C; fra queste la più bistrattata è il
1506 \code{goto}, che viene deprecato in favore dei costrutti della programmazione
1507 strutturata, che rendono il codice più leggibile e mantenibile. Esiste però un
1508 caso in cui l'uso di questa istruzione porta all'implementazione più
1509 efficiente e più chiara anche dal punto di vista della struttura del
1510 programma: quello dell'uscita in caso di errore.
1512 \index{salto~non-locale|(}
1514 Il C però non consente di effettuare un salto ad una etichetta definita in
1515 un'altra funzione, per cui se l'errore avviene in una funzione, e la sua
1516 gestione ordinaria è in un'altra, occorre usare quello che viene chiamato un
1517 \textsl{salto non-locale}. Il caso classico in cui si ha questa necessità,
1518 citato sia in \cite{APUE} che in \cite{glibc}, è quello di un programma nel
1519 cui corpo principale vengono letti dei dati in ingresso sui quali viene
1520 eseguita, tramite una serie di funzioni di analisi, una scansione dei
1521 contenuti, da cui si ottengono le indicazioni per l'esecuzione di opportune
1524 Dato che l'analisi può risultare molto complessa, ed opportunamente suddivisa
1525 in fasi diverse, la rilevazione di un errore nei dati in ingresso può accadere
1526 all'interno di funzioni profondamente annidate l'una nell'altra. In questo
1527 caso si dovrebbe gestire, per ciascuna fase, tutta la casistica del passaggio
1528 all'indietro di tutti gli errori rilevabili dalle funzioni usate nelle fasi
1529 successive. Questo comporterebbe una notevole complessità, mentre sarebbe
1530 molto più comodo poter tornare direttamente al ciclo di lettura principale,
1531 scartando l'input come errato.\footnote{a meno che, come precisa \cite{glibc},
1532 alla chiusura di ciascuna fase non siano associate operazioni di pulizia
1533 specifiche (come deallocazioni, chiusure di file, ecc.), che non potrebbero
1534 essere eseguite con un salto non-locale.}
1536 Tutto ciò può essere realizzato proprio con un salto non-locale; questo di
1537 norma viene realizzato salvando il contesto dello stack nel punto in cui si
1538 vuole tornare in caso di errore, e ripristinandolo, in modo da tornare nella
1539 funzione da cui si era partiti, quando serve. La funzione che permette di
1540 salvare il contesto dello stack è \funcd{setjmp}, il cui prototipo è:
1543 \funcdecl{int setjmp(jmp\_buf env)}
1545 Salva il contesto dello stack.
1547 \bodydesc{La funzione ritorna zero quando è chiamata direttamente e un
1548 valore diverso da zero quando ritorna da una chiamata di \func{longjmp}
1549 che usa il contesto salvato in precedenza.}
1552 Quando si esegue la funzione il contesto corrente dello stack viene salvato
1553 nell'argomento \param{env}, una variabile di tipo
1554 \type{jmp\_buf}\footnote{questo è un classico esempio di variabile di
1555 \textsl{tipo opaco}\index{tipo!opaco}. Si definiscono così strutture ed
1556 altri oggetti usati da una libreria, la cui struttura interna non deve
1557 essere vista dal programma chiamante (da cui il nome) che li devono
1558 utilizzare solo attraverso dalle opportune funzioni di gestione.} che deve
1559 essere stata definita in precedenza. In genere le variabili di tipo
1560 \type{jmp\_buf} vengono definite come variabili globali in modo da poter
1561 essere viste in tutte le funzioni del programma.
1563 Quando viene eseguita direttamente la funzione ritorna sempre zero, un valore
1564 diverso da zero viene restituito solo quando il ritorno è dovuto ad una
1565 chiamata di \func{longjmp} in un'altra parte del programma che ripristina lo
1566 stack effettuando il salto non-locale. Si tenga conto che il contesto salvato
1567 in \param{env} viene invalidato se la routine che ha chiamato \func{setjmp}
1568 ritorna, nel qual caso un successivo uso di \func{longjmp} può comportare
1569 conseguenze imprevedibili (e di norma fatali) per il processo.
1571 Come accennato per effettuare un salto non-locale ad
1572 un punto precedentemente stabilito con \func{setjmp} si usa la funzione
1573 \funcd{longjmp}; il suo prototipo è:
1576 \funcdecl{void longjmp(jmp\_buf env, int val)}
1578 Ripristina il contesto dello stack.
1580 \bodydesc{La funzione non ritorna.}
1583 La funzione ripristina il contesto dello stack salvato da una chiamata a
1584 \func{setjmp} nell'argomento \param{env}. Dopo l'esecuzione della funzione il
1585 programma prosegue nel codice successivo al ritorno della \func{setjmp} con
1586 cui si era salvato \param{env}, che restituirà il valore \param{val} invece di
1587 zero. Il valore di \param{val} specificato nella chiamata deve essere diverso
1588 da zero, se si è specificato 0 sarà comunque restituito 1 al suo posto.
1590 In sostanza un \func{longjmp} è analogo ad un \code{return}, solo che invece
1591 di ritornare alla riga successiva della funzione chiamante, il programma
1592 ritorna alla posizione della relativa \func{setjmp}, l'altra differenza è che
1593 il ritorno può essere effettuato anche attraverso diversi livelli di funzioni
1596 L'implementazione di queste funzioni comporta alcune restrizioni dato che esse
1597 interagiscono direttamente con la gestione dello stack ed il funzionamento del
1598 compilatore stesso. In particolare \func{setjmp} è implementata con una macro,
1599 pertanto non si può cercare di ottenerne l'indirizzo, ed inoltre delle
1600 chiamate a questa funzione sono sicure solo in uno dei seguenti casi:
1602 \item come espressione di controllo in un comando condizionale, di selezione
1603 o di iterazione (come \code{if}, \code{switch} o \code{while});
1604 \item come operando per un operatore di uguaglianza o confronto in una
1605 espressione di controllo di un comando condizionale, di selezione o di
1607 \item come operando per l'operatore di negazione (\code{!}) in una espressione
1608 di controllo di un comando condizionale, di selezione o di iterazione;
1609 \item come espressione a sé stante.
1612 In generale, dato che l'unica differenza fra la chiamata diretta e quella
1613 ottenuta da un \func{longjmp} è costituita dal valore di ritorno di
1614 \func{setjmp}, essa è usualmente chiamata all'interno di un comando \code{if}.
1616 Uno dei punti critici dei salti non-locali è quello del valore delle
1617 variabili, ed in particolare quello delle variabili automatiche della funzione
1618 a cui si ritorna. In generale le variabili globali e statiche mantengono i
1619 valori che avevano al momento della chiamata di \func{longjmp}, ma quelli
1620 delle variabili automatiche (o di quelle dichiarate
1621 \direct{register}\footnote{la direttiva \direct{register} del compilatore
1622 chiede che la variabile dichiarata tale sia mantenuta, nei limiti del
1623 possibile, all'interno di un registro del processore. Questa direttiva è
1624 originaria dell'epoca dai primi compilatori, quando stava al programmatore
1625 scrivere codice ottimizzato, riservando esplicitamente alle variabili più
1626 usate l'uso dei registri del processore. Oggi questa direttiva è in disuso
1627 dato che tutti i compilatori sono normalmente in grado di valutare con
1628 maggior efficacia degli stessi programmatori quando sia il caso di eseguire
1629 questa ottimizzazione.}) sono in genere indeterminati.
1631 Quello che succede infatti è che i valori delle variabili che sono tenute in
1632 memoria manterranno il valore avuto al momento della chiamata di
1633 \func{longjmp}, mentre quelli tenuti nei registri del processore (che nella
1634 chiamata ad un'altra funzione vengono salvati nel contesto nello stack)
1635 torneranno al valore avuto al momento della chiamata di \func{setjmp}; per
1636 questo quando si vuole avere un comportamento coerente si può bloccare
1637 l'ottimizzazione che porta le variabili nei registri dichiarandole tutte come
1638 \direct{volatile}\footnote{la direttiva \direct{volatile} informa il
1639 compilatore che la variabile che è dichiarata può essere modificata, durante
1640 l'esecuzione del nostro, da altri programmi. Per questo motivo occorre dire
1641 al compilatore che non deve essere mai utilizzata l'ottimizzazione per cui
1642 quanto opportuno essa viene mantenuta in un registro, poiché in questo modo
1643 si perderebbero le eventuali modifiche fatte dagli altri programmi (che
1644 avvengono solo in una copia posta in memoria).}.
1646 \index{salto~non-locale|)}
1648 %%% Local Variables:
1650 %%% TeX-master: "gapil"