3 %% Copyright (C) 2000-2007 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
12 \chapter{L'interfaccia base con i processi}
13 \label{cha:process_interface}
15 Come accennato nell'introduzione il \textsl{processo} è l'unità di base con
16 cui un sistema unix-like alloca ed utilizza le risorse. Questo capitolo
17 tratterà l'interfaccia base fra il sistema e i processi, come vengono passati
18 gli argomenti, come viene gestita e allocata la memoria, come un processo può
19 richiedere servizi al sistema e cosa deve fare quando ha finito la sua
20 esecuzione. Nella sezione finale accenneremo ad alcune problematiche generiche
23 In genere un programma viene eseguito quando un processo lo fa partire
24 eseguendo una funzione della famiglia \func{exec}; torneremo su questo e sulla
25 creazione e gestione dei processi nel prossimo capitolo. In questo
26 affronteremo l'avvio e il funzionamento di un singolo processo partendo dal
27 punto di vista del programma che viene messo in esecuzione.
30 \section{Esecuzione e conclusione di un programma}
32 Uno dei concetti base di Unix è che un processo esegue sempre uno ed un solo
33 programma: si possono avere più processi che eseguono lo stesso programma ma
34 ciascun processo vedrà la sua copia del codice (in realtà il kernel fa sì che
35 tutte le parti uguali siano condivise), avrà un suo spazio di indirizzi,
36 variabili proprie e sarà eseguito in maniera completamente indipendente da
37 tutti gli altri.\footnote{questo non è del tutto vero nel caso di un programma
38 \textit{multi-thread}, ma la gestione dei \itindex{thread} \textit{thread}
39 in Linux sarà trattata a parte in cap.~\ref{cha:threads}.}
42 \subsection{La funzione \func{main}}
45 Quando un programma viene lanciato il kernel esegue un opportuno codice di
46 avvio, usando il programma \cmd{ld-linux.so}. Questo programma prima carica
47 le librerie condivise che servono al programma, poi effettua il collegamento
48 dinamico del codice e alla fine lo esegue. Infatti, a meno di non aver
49 specificato il flag \texttt{-static} durante la compilazione, tutti i
50 programmi in Linux sono incompleti e necessitano di essere \textsl{collegati}
51 alle librerie condivise quando vengono avviati. La procedura è controllata da
52 alcune variabili di ambiente e dal contenuto di \conffile{/etc/ld.so.conf}. I
53 dettagli sono riportati nella pagina di manuale di \cmd{ld.so}.
55 Il sistema fa partire qualunque programma chiamando la funzione \func{main};
56 sta al programmatore chiamare così la funzione principale del programma da cui
57 si suppone iniziare l'esecuzione; in ogni caso senza questa funzione lo stesso
58 \textit{linker} (si chiama così il programma che effettua i collegamenti di
59 cui sopra) darebbe luogo ad errori. Lo standard ISO C specifica che la
60 funzione \func{main} può non avere argomenti o prendere due argomenti che
61 rappresentano gli argomenti passati da linea di comando, in sostanza un
62 prototipo che va sempre bene è il seguente:
63 \includecodesnip{listati/main_def.c}
65 In realtà nei sistemi Unix esiste un altro modo per definire la funzione
66 \func{main}, che prevede la presenza di un terzo argomento, \code{char
67 *envp[]}, che fornisce (vedi sez.~\ref{sec:proc_environ})
68 l'\textsl{ambiente} del programma; questa forma però non è prevista dallo
69 standard POSIX.1 per cui se si vogliono scrivere programmi portabili è meglio
73 \subsection{Come chiudere un programma}
74 \label{sec:proc_conclusion}
76 Normalmente un programma finisce quando la funzione \func{main} ritorna, una
77 modalità equivalente di chiudere il programma è quella di chiamare
78 direttamente la funzione \func{exit} (che viene comunque chiamata
79 automaticamente quando \func{main} ritorna). Una forma alternativa è quella
80 di chiamare direttamente la system call \func{\_exit}, che restituisce il
81 controllo direttamente alla funzione di conclusione dei processi del kernel.
83 Oltre alla conclusione ``\textsl{normale}'' esiste anche la possibilità di una
84 conclusione ``\textsl{anomala}'' del programma a causa della ricezione di un
85 segnale (tratteremo i segnali in cap.~\ref{cha:signals}) o della chiamata alla
86 funzione \func{abort}; torneremo su questo in sez.~\ref{sec:proc_termination}.
88 Il valore di ritorno della funzione \func{main}, o quello usato nelle chiamate
89 ad \func{exit} e \func{\_exit}, viene chiamato \textsl{stato di uscita} (o
90 \textit{exit status}) e passato al processo che aveva lanciato il programma
91 (in genere la shell). In generale si usa questo valore per fornire
92 informazioni sulla riuscita o il fallimento del programma; l'informazione è
93 necessariamente generica, ed il valore deve essere compreso fra 0 e 255.
95 La convenzione in uso pressoché universale è quella di restituire 0 in caso di
96 successo e 1 in caso di fallimento; l'unica eccezione è per i programmi che
97 effettuano dei confronti (come \cmd{diff}), che usano 0 per indicare la
98 corrispondenza, 1 per indicare la non corrispondenza e 2 per indicare
99 l'incapacità di effettuare il confronto. È opportuno adottare una di queste
100 convenzioni a seconda dei casi. Si tenga presente che se si raggiunge la fine
101 della funzione \func{main} senza ritornare esplicitamente si ha un valore di
102 uscita indefinito, è pertanto consigliabile di concludere sempre in maniera
103 esplicita detta funzione.
105 Un'altra convenzione riserva i valori da 128 a 256 per usi speciali: ad
106 esempio 128 viene usato per indicare l'incapacità di eseguire un altro
107 programma in un sottoprocesso. Benché questa convenzione non sia
108 universalmente seguita è una buona idea tenerne conto.
110 Si tenga presente inoltre che non è una buona idea usare il codice di errore
111 restituito dalla variabile \var{errno} (per i dettagli si veda
112 sez.~\ref{sec:sys_errors}) come stato di uscita. In generale infatti una shell
113 non si cura del valore se non per vedere se è diverso da zero; inoltre il
114 valore dello stato di uscita è sempre troncato ad 8 bit, per cui si potrebbe
115 incorrere nel caso in cui restituendo un codice di errore 256, si otterrebbe
116 uno stato di uscita uguale a zero, che verrebbe interpretato come un successo.
118 In \file{stdlib.h} sono definite, seguendo lo standard POSIX, le due costanti
119 \const{EXIT\_SUCCESS} e \const{EXIT\_FAILURE}, da usare sempre per specificare
120 lo stato di uscita di un processo. In Linux esse sono poste rispettivamente ai
121 valori di tipo \ctyp{int} 0 e 1.
124 \subsection{Le funzioni \func{exit} e \func{\_exit}}
125 \label{sec:proc_exit}
127 Come accennato le funzioni usate per effettuare un'uscita ``\textit{normale}''
128 da un programma sono due, la prima è la funzione \funcd{exit}, che è definita
129 dallo standard ANSI C ed il cui prototipo è:
130 \begin{prototype}{stdlib.h}{void exit(int status)}
131 Causa la conclusione ordinaria del programma.
133 \bodydesc{La funzione non ritorna. Il processo viene terminato.}
136 La funzione \func{exit} è pensata per eseguire una conclusione pulita di un
137 programma che usi le librerie standard del C; essa esegue tutte le funzioni
138 che sono state registrate con \func{atexit} e \func{on\_exit} (vedi
139 sez.~\ref{sec:proc_atexit}), e chiude tutti gli stream effettuando il
140 salvataggio dei dati sospesi (chiamando \func{fclose}, vedi
141 sez.~\ref{sec:file_fopen}), infine passa il controllo al kernel chiamando
142 \func{\_exit} e restituendo il valore di \param{status} come stato di uscita.
144 La system call \funcd{\_exit} restituisce direttamente il controllo al kernel,
145 concludendo immediatamente il processo; i dati sospesi nei buffer degli stream
146 non vengono salvati e le eventuali funzioni registrate con \func{atexit} e
147 \func{on\_exit} non vengono eseguite. Il prototipo della funzione è:
148 \begin{prototype}{unistd.h}{void \_exit(int status)}
149 Causa la conclusione immediata del programma.
151 \bodydesc{La funzione non ritorna. Il processo viene terminato.}
154 La funzione chiude tutti i file descriptor appartenenti al processo (si tenga
155 presente che questo non comporta il salvataggio dei dati bufferizzati degli
156 stream), fa sì che ogni figlio del processo sia adottato da \cmd{init} (vedi
157 cap.~\ref{cha:process_handling}), manda un segnale \const{SIGCHLD} al processo
158 padre (vedi sez.~\ref{sec:sig_job_control}) ed infine ritorna lo stato di
159 uscita specificato in \param{status} che può essere raccolto usando la
160 funzione \func{wait} (vedi sez.~\ref{sec:proc_wait}).
163 \subsection{Le funzioni \func{atexit} e \func{on\_exit}}
164 \label{sec:proc_atexit}
166 Un'esigenza comune che si incontra nella programmazione è quella di dover
167 effettuare una serie di operazioni di pulizia (ad esempio salvare dei dati,
168 ripristinare delle impostazioni, eliminare dei file temporanei, ecc.) prima
169 della conclusione di un programma. In genere queste operazioni vengono fatte
170 in un'apposita sezione del programma, ma quando si realizza una libreria
171 diventa antipatico dover richiedere una chiamata esplicita ad una funzione di
172 pulizia al programmatore che la utilizza.
174 È invece molto meno soggetto ad errori, e completamente trasparente
175 all'utente, avere la possibilità di effettuare automaticamente la chiamata ad
176 una funzione che effettui tali operazioni all'uscita dal programma. A questo
177 scopo lo standard ANSI C prevede la possibilità di registrare un certo numero
178 di funzioni che verranno eseguite all'uscita dal programma (sia per la
179 chiamata ad \func{exit} che per il ritorno di \func{main}). La prima funzione
180 che si può utilizzare a tal fine è \funcd{atexit} il cui prototipo è:
181 \begin{prototype}{stdlib.h}{void atexit(void (*function)(void))}
182 Registra la funzione \param{function} per la chiamata all'uscita dal
185 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
186 fallimento, \var{errno} non viene modificata.}
188 \noindent la funzione richiede come argomento l'indirizzo di una opportuna
189 funzione di pulizia da chiamare all'uscita del programma, che non deve
190 prendere argomenti e non deve ritornare niente (deve essere cioè definita come
191 \code{void function(void)}).
193 Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che le
194 \acr{glibc} includono per compatibilità con SunOS, ma che non è detto sia
195 definita su altri sistemi; il suo prototipo è:
196 \begin{prototype}{stdlib.h}
197 {void on\_exit(void (*function)(int , void *), void *arg)}
198 Registra la funzione \param{function} per la chiamata all'uscita dal
201 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
202 fallimento, \var{errno} non viene modificata.}
205 In questo caso la funzione da chiamare all'uscita prende i due argomenti
206 specificati nel prototipo, dovrà cioè essere definita come \code{void
207 function(int status, void *argp)}. Il primo argomento sarà inizializzato
208 allo stato di uscita con cui è stata chiamata \func{exit} ed il secondo al
209 puntatore \param{arg} passato come secondo argomento di \func{on\_exit}. Così
210 diventa possibile passare dei dati alla funzione di chiusura.
212 Nella sequenza di chiusura tutte le funzioni registrate verranno chiamate in
213 ordine inverso rispetto a quello di registrazione (ed una stessa funzione
214 registrata più volte sarà chiamata più volte); poi verranno chiusi tutti gli
215 stream aperti, infine verrà chiamata \func{\_exit}.
218 \subsection{Conclusioni}
219 \label{sec:proc_term_conclusion}
221 Data l'importanza dell'argomento è opportuno sottolineare ancora una volta che
222 in un sistema Unix l'unico modo in cui un programma può essere eseguito dal
223 kernel è attraverso la chiamata alla system call \func{execve} (o attraverso
224 una delle funzioni della famiglia \func{exec} che vedremo in
225 sez.~\ref{sec:proc_exec}).
227 Allo stesso modo l'unico modo in cui un programma può concludere
228 volontariamente la sua esecuzione è attraverso una chiamata alla system call
229 \func{\_exit}, o esplicitamente, o in maniera indiretta attraverso l'uso di
230 \func{exit} o il ritorno di \func{main}.
232 Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
233 normalmente un programma è riportato in fig.~\ref{fig:proc_prog_start_stop}.
237 % \includegraphics[width=9cm]{img/proc_beginend}
238 \begin{tikzpicture}[>=stealth]
239 \filldraw[fill=black!35] (-0.3,0) rectangle (12,1);
240 \draw(5.5,0.5) node {\large{kernel}};
242 \filldraw[fill=black!15] (1.5,2) rectangle (4,3);
243 \draw (2.75,2.5) node {\texttt{ld-linux.so}};
244 \draw [->] (2.75,1) -- (2.75,2);
245 \draw (2.75,1.5) node [anchor=west]{\texttt{exec}};
247 \filldraw[fill=black!15,rounded corners] (1.5,4) rectangle (4,5);
248 \draw (2.75,4.5) node {\texttt{main}};
250 \draw [<->, dashed] (2.75,3) -- (2.75,4);
251 \draw [->] (1.5,4.5) -- (0.3,4.5) -- (0.3,1);
252 \draw (0.9,4.5) node [anchor=south] {\texttt{\_exit}};
254 \filldraw[fill=black!15,rounded corners] (1.5,6) rectangle (4,7);
255 \draw (2.75,6.5) node {\texttt{funzione}};
257 \draw [<->, dashed] (2.75,5) -- (2.75,6);
258 \draw [->] (1.5,6.5) -- (0.05,6.5) -- (0.05,1);
259 \draw (0.9,6.5) node [anchor=south] {\texttt{\_exit}};
261 \draw (6.75,4.5) node (exit) [rectangle,fill=black!15,minimum width=2.5cm,minimum height=1cm,rounded corners, draw]{\texttt{exit}};
263 \draw[->] (4,6.5) -- node[anchor=south west]{\texttt{exit}} (exit);
264 \draw[->] (4,4.5) -- node[anchor=south]{\texttt{exit}} (exit);
265 \draw[->] (exit) -- node[anchor=east]{\texttt{\_exit}}(6.75,1);
267 \draw (10,4.5) node (exithandler1) [rectangle,fill=black!15,rounded corners, draw]{exit handler};
268 \draw (10,5.5) node (exithandler2) [rectangle,fill=black!15,rounded corners, draw]{exit handler};
269 \draw (10,3.5) node (stream) [rectangle,fill=black!15,rounded corners, draw]{chiusura stream};
271 \draw[<->, dashed] (exithandler1) -- (exit);
272 \draw[<->, dashed] (exithandler2) -- (exit);
273 \draw[<->, dashed] (stream) -- (exit);
275 \caption{Schema dell'avvio e della conclusione di un programma.}
276 \label{fig:proc_prog_start_stop}
279 Si ricordi infine che un programma può anche essere interrotto dall'esterno
280 attraverso l'uso di un segnale (modalità di conclusione non mostrata in
281 fig.~\ref{fig:proc_prog_start_stop}); tratteremo nei dettagli i segnali e la
282 loro gestione nel capitolo \ref{cha:signals}.
286 \section{I processi e l'uso della memoria}
287 \label{sec:proc_memory}
289 Una delle risorse base che ciascun processo ha a disposizione è la memoria, e
290 la gestione della memoria è appunto uno degli aspetti più complessi di un
291 sistema unix-like. In questa sezione, dopo una breve introduzione ai concetti
292 base, esamineremo come la memoria viene vista da parte di un programma in
293 esecuzione, e le varie funzioni utilizzabili per la sua gestione.
296 \subsection{I concetti generali}
297 \label{sec:proc_mem_gen}
299 Ci sono vari modi in cui i sistemi operativi organizzano la memoria, ed i
300 dettagli di basso livello dipendono spesso in maniera diretta
301 dall'architettura dell'hardware, ma quello più tipico, usato dai sistemi
302 unix-like come Linux è la cosiddetta \index{memoria~virtuale} \textsl{memoria
303 virtuale} che consiste nell'assegnare ad ogni processo uno spazio virtuale
304 di indirizzamento lineare, in cui gli indirizzi vanno da zero ad un qualche
305 valore massimo.\footnote{nel caso di Linux fino al kernel 2.2 detto massimo
306 era, per macchine a 32bit, di 2Gb. Con il kernel 2.4 ed il supporto per la
307 \textit{high-memory} il limite è stato esteso anche per macchine a 32 bit.}
309 Come accennato in cap.~\ref{cha:intro_unix} questo spazio di indirizzi è
310 virtuale e non corrisponde all'effettiva posizione dei dati nella RAM del
311 computer; in genere detto spazio non è neppure continuo (cioè non tutti gli
312 indirizzi possibili sono utilizzabili, e quelli usabili non sono
313 necessariamente adiacenti).
315 Per la gestione da parte del kernel la memoria viene divisa in pagine di
316 dimensione fissa,\footnote{inizialmente questi erano di 4kb sulle macchine a
317 32 bit e di 8kb sulle alpha, con le versioni più recenti del kernel è
318 possibile anche utilizzare pagine di dimensioni maggiori (4Mb), per sistemi
319 con grandi quantitativi di memoria in cui l'uso di pagine troppo piccole
320 comporta una perdita di prestazioni.} e ciascuna pagina nello spazio di
321 indirizzi virtuale è associata ad un supporto che può essere una pagina di
322 memoria reale o ad un dispositivo di stoccaggio secondario (come lo spazio
323 disco riservato alla swap, o i file che contengono il codice). Per ciascun
324 processo il kernel si cura di mantenere un mappa di queste corrispondenze
325 nella cosiddetta \itindex{page~table} \textit{page table}.\footnote{questa è
326 una semplificazione brutale, il meccanismo è molto più complesso; una buona
327 trattazione di come Linux gestisce la memoria virtuale si trova su
330 Una stessa pagina di memoria reale può fare da supporto a diverse pagine di
331 memoria virtuale appartenenti a processi diversi (come accade in genere per le
332 pagine che contengono il codice delle librerie condivise). Ad esempio il
333 codice della funzione \func{printf} starà su una sola pagina di memoria reale
334 che farà da supporto a tutte le pagine di memoria virtuale di tutti i processi
335 che hanno detta funzione nel loro codice.
337 La corrispondenza fra le pagine della \index{memoria~virtuale} memoria
338 virtuale di un processo e quelle della memoria fisica della macchina viene
339 gestita in maniera trasparente dal kernel.\footnote{in genere con l'ausilio
340 dell'hardware di gestione della memoria (la \textit{Memory Management Unit}
341 del processore), con i kernel della serie 2.6 è comunque diventato possibile
342 utilizzare Linux anche su architetture che non dispongono di una MMU.}
343 Poiché in genere la memoria fisica è solo una piccola frazione della memoria
344 virtuale, è necessario un meccanismo che permetta di trasferire le pagine che
345 servono dal supporto su cui si trovano in memoria, eliminando quelle che non
346 servono. Questo meccanismo è detto \index{paginazione} \textsl{paginazione}
347 (o \textit{paging}), ed è uno dei compiti principali del kernel.
349 Quando un processo cerca di accedere ad una pagina che non è nella memoria
350 reale, avviene quello che viene chiamato un \itindex{page~fault} \textit{page
351 fault}; la gestione della memoria genera un'interruzione e passa il
352 controllo al kernel il quale sospende il processo e si incarica di mettere in
353 RAM la pagina richiesta (effettuando tutte le operazioni necessarie per
354 reperire lo spazio necessario), per poi restituire il controllo al processo.
356 Dal punto di vista di un processo questo meccanismo è completamente
357 trasparente, e tutto avviene come se tutte le pagine fossero sempre
358 disponibili in memoria. L'unica differenza avvertibile è quella dei tempi di
359 esecuzione, che passano dai pochi nanosecondi necessari per l'accesso in RAM,
360 a tempi molto più lunghi, dovuti all'intervento del kernel.
362 Normalmente questo è il prezzo da pagare per avere un multitasking reale, ed
363 in genere il sistema è molto efficiente in questo lavoro; quando però ci siano
364 esigenze specifiche di prestazioni è possibile usare delle funzioni che
365 permettono di bloccare il meccanismo della \index{paginazione} paginazione e
366 mantenere fisse delle pagine in memoria (vedi sez.~\ref{sec:proc_mem_lock}).
367 Inoltre per certe applicazioni gli algoritmi di gestione della memoria
370 \subsection{La struttura della memoria di un processo}
371 \label{sec:proc_mem_layout}
373 Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
374 una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
375 tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
376 commette quando si è manipolato male un puntatore e genera quella che viene
377 chiamata una \itindex{segment~violation} \textit{segment violation}. Se si
378 tenta cioè di leggere o scrivere da un indirizzo per il quale non esiste
379 un'associazione della pagina virtuale, il kernel risponde al relativo
380 \itindex{page~fault} \textit{page fault} mandando un segnale \const{SIGSEGV}
381 al processo, che normalmente ne causa la terminazione immediata.
383 È pertanto importante capire come viene strutturata \index{memoria~virtuale}
384 \textsl{la memoria virtuale} di un processo. Essa viene divisa in
385 \textsl{segmenti}, cioè un insieme contiguo di indirizzi virtuali ai quali il
386 processo può accedere. Solitamente un programma C viene suddiviso nei
390 \item Il \index{segmento!testo} segmento di testo o \textit{text segment}.
391 Contiene il codice del programma, delle funzioni di librerie da esso
392 utilizzate, e le costanti. Normalmente viene condiviso fra tutti i processi
393 che eseguono lo stesso programma (e anche da processi che eseguono altri
394 programmi nel caso delle librerie). Viene marcato in sola lettura per
395 evitare sovrascritture accidentali (o maliziose) che ne modifichino le
398 Viene allocato da \func{exec} all'avvio del programma e resta invariato
399 per tutto il tempo dell'esecuzione.
401 \item Il \index{segmento!dati} segmento dei dati o \textit{data segment}.
402 Contiene le variabili globali (cioè quelle definite al di fuori di tutte le
403 funzioni che compongono il programma) e le variabili statiche (cioè quelle
404 dichiarate con l'attributo \ctyp{static}). Di norma è diviso in due parti.
406 La prima parte è il segmento dei dati inizializzati, che contiene le
407 variabili il cui valore è stato assegnato esplicitamente. Ad esempio
409 \includecodesnip{listati/pi.c}
410 questo valore sarà immagazzinato in questo segmento. La memoria di questo
411 segmento viene preallocata all'avvio del programma e inizializzata ai valori
414 La seconda parte è il segmento dei dati non inizializzati, che contiene le
415 variabili il cui valore non è stato assegnato esplicitamente. Ad esempio se
417 \includecodesnip{listati/vect.c}
418 questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
419 allocato all'avvio, e tutte le variabili vengono inizializzate a zero (ed i
420 puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
421 variabili che vanno nel segmento dati, e non è affatto vero in generale.}
423 Storicamente questa seconda parte del segmento dati viene chiamata BSS (da
424 \textit{Block Started by Symbol}). La sua dimensione è fissa.
426 \item Lo \itindex{heap} \textit{heap}. Tecnicamente lo si può considerare
427 l'estensione del segmento dati, a cui di solito è posto giusto di seguito. È
428 qui che avviene l'allocazione dinamica della memoria; può essere
429 ridimensionato allocando e disallocando la memoria dinamica con le apposite
430 funzioni (vedi sez.~\ref{sec:proc_mem_alloc}), ma il suo limite inferiore
431 (quello adiacente al segmento dati) ha una posizione fissa.
433 \item Il segmento di \itindex{stack} \textit{stack}, che contiene quello che
434 viene chiamato \textit{stack} del programma. Tutte le volte che si effettua
435 una chiamata ad una funzione è qui che viene salvato l'indirizzo di ritorno
436 e le informazioni dello stato del chiamante (tipo il contenuto di alcuni
437 registri della CPU), poi la funzione chiamata alloca qui lo spazio per le
438 sue variabili locali. Tutti questi dati vengono \textit{impilati} (da questo
439 viene il nome \itindex{stack} \textit{stack}) in sequenza uno sull'altro; in
440 questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
441 della funzione lo spazio è automaticamente rilasciato e
442 ``\textsl{ripulito}''.\footnote{il compilatore si incarica di generare
443 automaticamente il codice necessario, seguendo quella che viene chiamata
444 una \textit{calling convention}; quella standard usata con il C ed il C++
445 è detta \textit{cdecl} e prevede che gli argomenti siano caricati nello
446 \textit{stack} dal chiamante da destra a sinistra, e che si il chiamante
447 stesso ad eseguire la ripulitura dello \textit{stack} al ritorno della
448 funzione, se ne possono però utilizzare di alternative (ad esempio nel
449 pascal gli argomenti sono inseriti da sinistra a destra ed è compito del
450 chiamato ripulire lo \textit{stack}), in genere non ci si deve preoccupare
451 di questo fintanto che non si mescolano funzioni scritte con linguaggi
454 La dimensione di questo segmento aumenta seguendo la crescita dello
455 \itindex{stack} \textit{stack} del programma, ma non viene ridotta quando
456 quest'ultimo si restringe.
461 % \includegraphics[height=12cm]{img/memory_layout}
463 \draw (0,0) rectangle (4,1);
464 \draw (2,0.5) node {text};
465 \draw (0,1) rectangle (4,2.5);
466 \draw (2,1.75) node {dati inizializzati};
467 \draw (0,2.5) rectangle (4,5);
468 \draw (2,3.75) node {dati non inizializzati};
469 \draw (0,5) rectangle (4,9);
470 \draw[dashed] (0,6) -- (4,6);
471 \draw[dashed] (0,8) -- (4,8);
472 \draw (2,5.5) node {heap};
473 \draw (2,8.5) node {stack};
474 \draw [->] (2,6) -- (2,6.5);
475 \draw [->] (2,8) -- (2,7.5);
476 \draw (0,9) rectangle (4,10);
477 \draw (2,9.5) node {environment};
478 \draw (4,0) node [anchor=west] {\texttt{0x08000000}};
479 \draw (4,5) node [anchor=west] {\texttt{0x08xxxxxx}};
480 \draw (4,9) node [anchor=west] {\texttt{0xC0000000}};
482 \caption{Disposizione tipica dei segmenti di memoria di un processo.}
483 \label{fig:proc_mem_layout}
486 Una disposizione tipica dei vari segmenti (testo, \itindex{heap}
487 \textit{heap}, \itindex{stack} \textit{stack}, ecc.) è riportata in
488 fig.~\ref{fig:proc_mem_layout}. Usando il comando \cmd{size} su un programma
489 se ne può stampare le dimensioni dei segmenti di testo e di dati
490 (inizializzati e BSS); si tenga presente però che il BSS non è mai salvato sul
491 file che contiene l'eseguibile, dato che viene sempre inizializzato a zero al
492 caricamento del programma.
495 \subsection{Allocazione della memoria per i programmi C}
496 \label{sec:proc_mem_alloc}
498 Il C supporta direttamente, come linguaggio di programmazione, soltanto due
499 modalità di allocazione della memoria: l'\textsl{allocazione statica} e
500 l'\textsl{allocazione automatica}.
502 L'\textsl{allocazione statica} è quella con cui sono memorizzate le variabili
503 globali e le variabili statiche, cioè le variabili il cui valore deve essere
504 mantenuto per tutta la durata del programma. Come accennato queste variabili
505 vengono allocate nel \index{segmento!dati} segmento dei dati all'avvio del
506 programma (come parte delle operazioni svolte da \func{exec}) e lo spazio da
507 loro occupato non viene liberato fino alla sua conclusione.
509 L'\textsl{allocazione automatica} è quella che avviene per gli argomenti di
510 una funzione e per le sue variabili locali (le cosiddette \textsl{variabili
511 automatiche}), che esistono solo per la durata della funzione. Lo spazio
512 per queste variabili viene allocato nello \itindex{stack} \textit{stack} quando
513 viene eseguita la funzione e liberato quando si esce dalla medesima.
515 Esiste però un terzo tipo di allocazione, l'\textsl{allocazione dinamica}
516 della memoria, che non è prevista direttamente all'interno del linguaggio C,
517 ma che è necessaria quando il quantitativo di memoria che serve è
518 determinabile solo durante il corso dell'esecuzione del programma.
520 Il C non consente di usare variabili allocate dinamicamente, non è possibile
521 cioè definire in fase di programmazione una variabile le cui dimensioni
522 possano essere modificate durante l'esecuzione del programma. Per questo le
523 librerie del C forniscono una serie opportuna di funzioni per eseguire
524 l'allocazione dinamica di memoria (in genere nello \itindex{heap}
527 Le variabili il cui contenuto è allocato in questo modo non potranno essere
528 usate direttamente come le altre (quelle nello \itindex{stack}
529 \textit{stack}), ma l'accesso sarà possibile solo in maniera indiretta,
530 attraverso i puntatori alla memoria loro riservata che si sono ottenuti dalle
531 funzioni di allocazione.
534 Le funzioni previste dallo standard ANSI C per la gestione della memoria sono
535 quattro: \funcd{malloc}, \funcd{calloc}, \funcd{realloc} e \funcd{free}, i
536 loro prototipi sono i seguenti:
539 \funcdecl{void *calloc(size\_t nmemb, size\_t size)}
540 Alloca nello \textit{heap} un'area di memoria per un vettore di
541 \param{nmemb} membri di \param{size} byte di dimensione. La memoria viene
544 La funzione restituisce il puntatore alla zona di memoria allocata in caso
545 di successo e \val{NULL} in caso di fallimento, nel qual caso
546 \var{errno} assumerà il valore \errval{ENOMEM}.
547 \funcdecl{void *malloc(size\_t size)}
548 Alloca \param{size} byte nello \textit{heap}. La memoria non viene
551 La funzione restituisce il puntatore alla zona di memoria allocata in caso
552 di successo e \val{NULL} in caso di fallimento, nel qual caso
553 \var{errno} assumerà il valore \errval{ENOMEM}.
554 \funcdecl{void *realloc(void *ptr, size\_t size)}
555 Cambia la dimensione del blocco allocato all'indirizzo \param{ptr}
556 portandola a \param{size}.
558 La funzione restituisce il puntatore alla zona di memoria allocata in caso
559 di successo e \val{NULL} in caso di fallimento, nel qual caso
560 \var{errno} assumerà il valore \errval{ENOMEM}.
561 \funcdecl{void free(void *ptr)}
562 Disalloca lo spazio di memoria puntato da \param{ptr}.
564 La funzione non ritorna nulla e non riporta errori.
566 Il puntatore ritornato dalle funzioni di allocazione è garantito essere sempre
567 allineato correttamente per tutti i tipi di dati; ad esempio sulle macchine a
568 32 bit in genere è allineato a multipli di 4 byte e sulle macchine a 64 bit a
571 In genere si usano le funzioni \func{malloc} e \func{calloc} per allocare
572 dinamicamente la quantità di memoria necessaria al programma indicata da
573 \param{size},\footnote{queste funzioni presentano un comportamento diverso fra
574 le \acr{glibc} e le \acr{uClib} quando il valore di \param{size} è nullo.
575 Nel primo caso viene comunque restituito un puntatore valido, anche se non è
576 chiaro a cosa esso possa fare riferimento, nel secondo caso viene restituito
577 \val{NULL}. Il comportamento è analogo con \code{realloc(NULL, 0)}.} e
578 siccome i puntatori ritornati sono di tipo generico non è necessario
579 effettuare un cast per assegnarli a puntatori al tipo di variabile per la
580 quale si effettua l'allocazione.
582 La memoria allocata dinamicamente deve essere esplicitamente rilasciata usando
583 \func{free}\footnote{le glibc provvedono anche una funzione \func{cfree}
584 definita per compatibilità con SunOS, che è deprecata.} una volta che non
585 sia più necessaria. Questa funzione vuole come argomento un puntatore
586 restituito da una precedente chiamata a una qualunque delle funzioni di
587 allocazione che non sia già stato liberato da un'altra chiamata a \func{free},
588 in caso contrario il comportamento della funzione è indefinito.
590 La funzione \func{realloc} si usa invece per cambiare (in genere aumentare) la
591 dimensione di un'area di memoria precedentemente allocata, la funzione vuole
592 in ingresso il puntatore restituito dalla precedente chiamata ad una
593 \func{malloc} (se è passato un valore \val{NULL} allora la funzione si
594 comporta come \func{malloc})\footnote{questo è vero per Linux e
595 l'implementazione secondo lo standard ANSI C, ma non è vero per alcune
596 vecchie implementazioni, inoltre alcune versioni delle librerie del C
597 consentivano di usare \func{realloc} anche per un puntatore liberato con
598 \func{free} purché non ci fossero state nel frattempo altre chiamate a
599 funzioni di allocazione, questa funzionalità è totalmente deprecata e non è
600 consentita sotto Linux.} ad esempio quando si deve far crescere la
601 dimensione di un vettore. In questo caso se è disponibile dello spazio
602 adiacente al precedente la funzione lo utilizza, altrimenti rialloca altrove
603 un blocco della dimensione voluta, copiandoci automaticamente il contenuto; lo
604 spazio aggiunto non viene inizializzato.
606 Si deve sempre avere ben presente il fatto che il blocco di memoria restituito
607 da \func{realloc} può non essere un'estensione di quello che gli si è passato
608 in ingresso; per questo si dovrà \emph{sempre} eseguire la riassegnazione di
609 \param{ptr} al valore di ritorno della funzione, e reinizializzare o provvedere
610 ad un adeguato aggiornamento di tutti gli altri puntatori all'interno del
611 blocco di dati ridimensionato.
613 Un errore abbastanza frequente (specie se si ha a che fare con vettori di
614 puntatori) è quello di chiamare \func{free} più di una volta sullo stesso
615 puntatore; per evitare questo problema una soluzione di ripiego è quella di
616 assegnare sempre a \val{NULL} ogni puntatore liberato con \func{free}, dato
617 che, quando l'argomento è un puntatore nullo, \func{free} non esegue nessuna
620 Le \acr{glibc} hanno un'implementazione delle funzioni di allocazione che è
621 controllabile dall'utente attraverso alcune variabili di ambiente, in
622 particolare diventa possibile tracciare questo tipo di errori usando la
623 variabile di ambiente \val{MALLOC\_CHECK\_} che quando viene definita mette in
624 uso una versione meno efficiente delle funzioni suddette, che però è più
625 tollerante nei confronti di piccoli errori come quello di chiamate doppie a
626 \func{free}. In particolare:
628 \item se la variabile è posta a zero gli errori vengono ignorati;
629 \item se è posta ad 1 viene stampato un avviso sullo \textit{standard error}
630 (vedi sez.~\ref{sec:file_std_stream});
631 \item se è posta a 2 viene chiamata \func{abort}, che in genere causa
632 l'immediata conclusione del programma.
635 Il problema più comune e più difficile da risolvere che si incontra con le
636 funzioni di allocazione è quando non viene opportunamente liberata la memoria
637 non più utilizzata, quello che in inglese viene chiamato \itindex{memory~leak}
638 \textit{memory leak}, cioè una \textsl{perdita di memoria}.
640 Un caso tipico che illustra il problema è quello in cui in una subroutine si
641 alloca della memoria per uso locale senza liberarla prima di uscire. La
642 memoria resta così allocata fino alla terminazione del processo. Chiamate
643 ripetute alla stessa subroutine continueranno ad effettuare altre allocazioni,
644 causando a lungo andare un esaurimento della memoria disponibile (e la
645 probabile impossibilità di proseguire l'esecuzione del programma).
647 Il problema è che l'esaurimento della memoria può avvenire in qualunque
648 momento, in corrispondenza ad una qualunque chiamata di \func{malloc}, che può
649 essere in una sezione del codice che non ha alcuna relazione con la subroutine
650 che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
651 \itindex{memory~leak} \textit{memory leak}.
653 In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
654 programmazione ad oggetti, il problema dei \itindex{memory~leak}
655 \textit{memory leak} è notevolmente ridimensionato attraverso l'uso accurato
656 di appositi oggetti come gli \textit{smartpointers}. Questo però in genere va
657 a scapito delle prestazioni dell'applicazione in esecuzione.
659 % TODO decidere cosa fare di questo che segue
660 % In altri linguaggi come il java e recentemente il C\# il problema non si pone
661 % nemmeno perché la gestione della memoria viene fatta totalmente in maniera
662 % automatica, ovvero il programmatore non deve minimamente preoccuparsi di
663 % liberare la memoria allocata precedentemente quando non serve più, poiché
664 % l'infrastruttura del linguaggio gestisce automaticamente la cosiddetta
665 % \index{\textit{garbage~collection}} \textit{garbage collection}. In tal caso,
666 % attraverso meccanismi simili a quelli del \textit{reference counting}, quando
667 % una zona di memoria precedentemente allocata non è più riferita da nessuna
668 % parte del codice in esecuzione, può essere deallocata automaticamente in
669 % qualunque momento dall'infrastruttura.
671 % Anche questo va a scapito delle prestazioni dell'applicazione in esecuzione
672 % (inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
673 % eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
674 % la presenza di una infrastruttura per la loro interpretazione e pertanto hanno
675 % di per sé delle prestazioni più scadenti rispetto alle stesse applicazioni
676 % compilate direttamente). Questo comporta però il problema della non
677 % predicibilità del momento in cui viene deallocata la memoria precedentemente
678 % allocata da un oggetto.
680 Per limitare l'impatto di questi problemi, e semplificare la ricerca di
681 eventuali errori, l'implementazione delle funzioni di allocazione delle
682 \acr{glibc} mette a disposizione una serie di funzionalità che permettono di
683 tracciare le allocazioni e le disallocazioni, e definisce anche una serie di
684 possibili \textit{hook} (\textsl{ganci}) che permettono di sostituire alle
685 funzioni di libreria una propria versione (che può essere più o meno
686 specializzata per il debugging). Esistono varie librerie che forniscono dei
687 sostituti opportuni delle funzioni di allocazione in grado, senza neanche
688 ricompilare il programma,\footnote{esempi sono \textit{Dmalloc}
689 \href{http://dmalloc.com/}{\textsf{http://dmalloc.com/}} di Gray Watson ed
690 \textit{Electric Fence} di Bruce Perens.} di eseguire diagnostiche anche
691 molto complesse riguardo l'allocazione della memoria.
693 Una possibile alternativa all'uso di \func{malloc}, che non soffre dei
694 problemi di \itindex{memory~leak} \textit{memory leak} descritti in
695 precedenza, è la funzione \funcd{alloca}, che invece di allocare la memoria
696 nello \itindex{heap} \textit{heap} usa il segmento di \itindex{stack}
697 \textit{stack} della funzione corrente. La sintassi è identica a quella di
698 \func{malloc}, il suo prototipo è:
699 \begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
700 Alloca \param{size} byte nello \textit{stack}.
702 \bodydesc{La funzione restituisce il puntatore alla zona di memoria
706 La funzione alloca la quantità di memoria (non inizializzata) richiesta
707 dall'argomento \param{size} nel segmento di \itindex{stack} \textit{stack}
708 della funzione chiamante. Con questa funzione non è più necessario liberare
709 la memoria allocata (e quindi non esiste un analogo della \func{free}) in
710 quanto essa viene rilasciata automaticamente al ritorno della funzione.
712 Come è evidente questa funzione ha molti vantaggi, anzitutto permette di
713 evitare alla radice i problemi di \itindex{memory~leak} \textit{memory leak},
714 dato che non serve più la deallocazione esplicita; inoltre la deallocazione
715 automatica funziona anche quando si usa \func{longjmp} per uscire da una
716 subroutine con un salto non locale da una funzione (vedi
717 sez.~\ref{sec:proc_longjmp}).
719 Un altro vantaggio è che in Linux la funzione è molto più veloce di
720 \func{malloc} e non viene sprecato spazio, infatti non è necessario gestire un
721 pool di memoria da riservare e si evitano così anche i problemi di
722 frammentazione di quest'ultimo, che comportano inefficienze sia
723 nell'allocazione della memoria che nell'esecuzione dell'allocazione.
725 Gli svantaggi sono che questa funzione non è disponibile su tutti gli Unix, e
726 non è inserita né nello standard POSIX né in SUSv3 (ma è presente in BSD), il
727 suo utilizzo quindi limita la portabilità dei programmi. Inoltre la funzione
728 non può essere usata nella lista degli argomenti di una funzione, perché lo
729 spazio verrebbe allocato nel mezzo degli stessi.
731 Inoltre non è chiaramente possibile usare \func{alloca} per allocare memoria
732 che deve poi essere usata anche al di fuori della funzione in cui essa viene
733 chiamata, dato che all'uscita dalla funzione lo spazio allocato diventerebbe
734 libero, e potrebbe essere sovrascritto all'invocazione di nuove funzioni.
735 Questo è lo stesso problema che si può avere con le variabili automatiche, su
736 cui torneremo in sez.~\ref{sec:proc_auto_var}.
738 Infine non esiste un modo di sapere se l'allocazione ha avuto successo, la
739 funzione infatti viene realizzata inserendo del codice \textit{inline} nel
740 programma\footnote{questo comporta anche il fatto che non è possibile
741 sostituirla con una propria versione o modificarne il comportamento
742 collegando il proprio programma con un'altra libreria.} che si limita a
743 modificare il puntatore nello \itindex{stack} \textit{stack} e non c'è modo di
744 sapere se se ne sono superate le dimensioni, per cui in caso di fallimento
745 nell'allocazione il comportamento del programma può risultare indefinito,
746 dando luogo ad una \itindex{segment~violation} \textit{segment violation} la
747 prima volta che cercherà di accedere alla memoria non effettivamente
750 Le due funzioni seguenti\footnote{le due funzioni sono state definite con BSD
751 4.3, sono marcate obsolete in SUSv2 e non fanno parte delle librerie
752 standard del C e mentre sono state esplicitamente rimosse dallo standard
753 POSIX/1-2001.} vengono utilizzate soltanto quando è necessario effettuare
754 direttamente la gestione della memoria associata allo spazio dati di un
755 processo, ad esempio qualora si debba implementare la propria versione delle
756 funzioni di allocazione della memoria. Per poterle utilizzare è necessario
757 definire una della macro di funzionalità (vedi
758 sez.~\ref{sec:intro_gcc_glibc_std}) fra \macro{\_BSD\_SOURCE},
759 \macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE} (ad un valore maggiore o
760 ugiale di 500). La prima funzione è \funcd{brk}, ed il suo prototipo è:
761 \begin{prototype}{unistd.h}{int brk(void *end\_data\_segment)}
762 Sposta la fine del segmento dei dati.
764 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
765 fallimento, nel qual caso \var{errno} assumerà il valore \errval{ENOMEM}.}
768 La funzione è un'interfaccia all'omonima system call ed imposta l'indirizzo
769 finale del \index{segmento!dati} segmento dati di un processo all'indirizzo
770 specificato da \param{end\_data\_segment}. Quest'ultimo deve essere un valore
771 ragionevole, ed inoltre la dimensione totale del segmento non deve comunque
772 eccedere un eventuale limite (si veda sez.~\ref{sec:sys_resource_limit})
773 imposto sulle dimensioni massime dello spazio dati del processo.
775 Il valore di ritorno della funzione fa riferimento alla versione fornita dalle
776 \acr{glibc}, in realtà in Linux la \textit{system call} corrispondente
777 restituisce come valore di ritorno il nuovo valore della fine del
778 \index{segmento!dati} segmento dati in caso di successo e quello corrente in
779 caso di fallimento, è la funzione di interfaccia usata dalle \acr{glibc} che
780 fornisce i valori di ritorno appena descritti, questo può non accadere se si
781 usano librerie diverse.
783 Una seconda funzione per la manipolazione diretta delle dimensioni
784 \index{segmento!dati} del segmento dati\footnote{in questo caso si tratta
785 soltanto di una funzione di libreria, e non di una system call.} è
786 \funcd{sbrk}, ed il suo prototipo è:
787 \begin{prototype}{unistd.h}{void *sbrk(ptrdiff\_t increment)}
788 Incrementa la dimensione dello spazio dati.
790 \bodydesc{La funzione restituisce il puntatore all'inizio della nuova zona
791 di memoria allocata in caso di successo e \val{NULL} in caso di
792 fallimento, nel qual caso \var{errno} assumerà il valore \errval{ENOMEM}.}
794 \noindent la funzione incrementa la dimensione lo spazio dati di un programma
795 di \param{increment} byte, restituendo il nuovo indirizzo finale dello stesso.
796 Un valore nullo permette di ottenere l'attuale posizione della fine del
797 \index{segmento!dati} segmento dati.
799 Queste funzioni sono state deliberatamente escluse dallo standard POSIX.1 e
800 per i programmi normali è sempre opportuno usare le funzioni di allocazione
801 standard descritte in precedenza, che sono costruite su di esse.
804 \subsection{Il controllo della memoria virtuale}
805 \label{sec:proc_mem_lock}
807 \index{memoria~virtuale|(}
809 Come spiegato in sez.~\ref{sec:proc_mem_gen} il kernel gestisce la memoria
810 virtuale in maniera trasparente ai processi, decidendo quando rimuovere pagine
811 dalla memoria per metterle nello swap, sulla base dell'utilizzo corrente da
812 parte dei vari processi.
814 Nell'uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il
815 meccanismo della \index{paginazione} paginazione riporta in RAM, ed in maniera
816 trasparente, tutte le pagine che gli occorrono; esistono però esigenze
817 particolari in cui non si vuole che questo meccanismo si attivi. In generale i
818 motivi per cui si possono avere di queste necessità sono due:
820 \item \textsl{La velocità}. Il processo della \index{paginazione} paginazione
821 è trasparente solo se il programma in esecuzione non è sensibile al tempo
822 che occorre a riportare la pagina in memoria; per questo motivo processi
823 critici che hanno esigenze di tempo reale o tolleranze critiche nelle
824 risposte (ad esempio processi che trattano campionamenti sonori) possono non
825 essere in grado di sopportare le variazioni della velocità di accesso dovuta
828 In certi casi poi un programmatore può conoscere meglio dell'algoritmo di
829 allocazione delle pagine le esigenze specifiche del suo programma e decidere
830 quali pagine di memoria è opportuno che restino in memoria per un aumento
831 delle prestazioni. In genere queste sono esigenze particolari e richiedono
832 anche un aumento delle priorità in esecuzione del processo (vedi
833 sez.~\ref{sec:proc_real_time}).
835 \item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro
836 in memoria queste possono essere portate su disco dal meccanismo della
837 \index{paginazione} paginazione. Questo rende più lungo il periodo di tempo
838 in cui detti segreti sono presenti in chiaro e più complessa la loro
839 cancellazione (un processo può cancellare la memoria su cui scrive le sue
840 variabili, ma non può toccare lo spazio disco su cui una pagina di memoria
841 può essere stata salvata). Per questo motivo di solito i programmi di
842 crittografia richiedono il blocco di alcune pagine di memoria.
845 \itindbeg{memory~locking}
847 Il meccanismo che previene la \index{paginazione} paginazione di parte della
848 memoria virtuale di un processo è chiamato \textit{memory locking} (o
849 \textsl{blocco della memoria}). Il blocco è sempre associato alle pagine della
850 memoria virtuale del processo, e non al segmento reale di RAM su cui essa
851 viene mantenuta. La regola è che se un segmento di RAM fa da supporto ad
852 almeno una pagina bloccata allora esso viene escluso dal meccanismo della
853 \index{paginazione} paginazione. I blocchi non si accumulano, se si blocca due
854 volte la stessa pagina non è necessario sbloccarla due volte, una pagina o è
857 Il \textit{memory lock} persiste fintanto che il processo che detiene la
858 memoria bloccata non la sblocca. Chiaramente la terminazione del processo
859 comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
860 tutti i suoi \textit{memory lock}. Infine i \textit{memory lock} non sono
861 ereditati dai processi figli,\footnote{ma siccome Linux usa il
862 \itindex{copy~on~write} \textit{copy on write} (vedi
863 sez.~\ref{sec:proc_fork}) gli indirizzi virtuali del figlio sono mantenuti
864 sullo stesso segmento di RAM del padre, quindi fintanto che un figlio non
865 scrive su un segmento, può usufruire del \textit{memory lock} del padre.} e
866 vengono automaticamente rimossi se si pone in esecuzione un altro programma
867 con \func{exec} (vedi sez.~\ref{sec:proc_exec}).
869 Siccome la richiesta di un \textit{memory lock} da parte di un processo riduce
870 la memoria fisica disponibile nel sistema, questo ha un evidente impatto su
871 tutti gli altri processi, per cui fino al kernel 2.6.9 solo un processo con i
872 privilegi opportuni (la \itindex{capabilities} \textit{capability}
873 \const{CAP\_IPC\_LOCK}, vedi sez.~\ref{sec:proc_capabilities}) aveva la
874 capacità di bloccare una pagina.
876 Il sistema pone dei limiti all'ammontare di memoria di un processo che può
877 essere bloccata e al totale di memoria fisica che si può dedicare a questo, lo
878 standard POSIX.1 richiede che sia definita in \file{unistd.h} la macro
879 \macro{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
880 \textit{memory locking}. Inoltre in alcuni sistemi è definita la costante
881 \const{PAGE\_SIZE} in \file{limits.h} per indicare la dimensione di una pagina
882 in byte.\footnote{con Linux questo non avviene e si deve ricorrere alla
883 funzione \func{getpagesize}, vedi sez.~\ref{sec:sys_memory_res}.}
886 A partire dal kernel 2.6.9 anche un processo normale può bloccare la propria
887 memoria\footnote{la funzionalità è stata introdotta per non essere costretti a
888 dare privilegi eccessivi a programmi di crittografia, che necessitano di
889 questa funzionalità, ma che devono essere usati da utenti normali.} ma
890 mentre un processo privilegiato non ha limiti sulla quantità di memoria che
891 può bloccare, un processo normale è soggetto al limite della risorsa
892 \const{RLIMIT\_MEMLOCK} (vedi sez.~\ref{sec:sys_resource_limit}). In generale
893 poi ogni processo può sbloccare le pagine relative alla propria memoria, se
894 però diversi processi bloccano la stessa pagina questa resterà bloccata
895 fintanto che ci sarà almeno un processo che la blocca.
897 Le funzioni per bloccare e sbloccare la \index{paginazione} paginazione di
898 singole sezioni di memoria sono \funcd{mlock} e \funcd{munlock}; i loro
901 \headdecl{sys/mman.h}
903 \funcdecl{int mlock(const void *addr, size\_t len)}
904 Blocca la paginazione su un intervallo di memoria.
906 \funcdecl{int munlock(const void *addr, size\_t len)}
907 Rimuove il blocco della paginazione su un intervallo di memoria.
909 \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 in
910 caso di errore, nel qual caso \var{errno} assumerà uno dei
913 \item[\errcode{ENOMEM}] alcuni indirizzi dell'intervallo specificato non
914 corrispondono allo spazio di indirizzi del processo o si è ecceduto
915 il numero massimo consentito di pagine bloccate.
916 \item[\errcode{EINVAL}] \param{len} non è un valore positivo.
917 \item[\errcode{EPERM}] con un kernel successivo al 2.6.9 il processo non è
918 privilegiato e si un limite nullo per \const{RLIMIT\_MEMLOCK}.
920 e, per \func{mlock}, anche \errval{EPERM} quando il processo non ha i
921 privilegi richiesti per l'operazione.}
924 Le due funzioni permettono rispettivamente di bloccare e sbloccare la
925 \index{paginazione} paginazione per l'intervallo di memoria specificato dagli
926 argomenti, che ne indicano nell'ordine l'indirizzo iniziale e la lunghezza.
927 Tutte le pagine che contengono una parte dell'intervallo bloccato sono
928 mantenute in RAM per tutta la durata del blocco.\footnote{con altri kernel si
929 può ottenere un errore di \errcode{EINVAL} se \param{addr} non è un multiplo
930 della dimensione delle pagine di memoria.}
932 Altre due funzioni, \funcd{mlockall} e \funcd{munlockall}, consentono di
933 bloccare genericamente la \index{paginazione} paginazione per l'intero spazio
934 di indirizzi di un processo. I prototipi di queste funzioni sono:
936 \headdecl{sys/mman.h}
938 \funcdecl{int mlockall(int flags)}
939 Blocca la paginazione per lo spazio di indirizzi del processo corrente.
941 \funcdecl{int munlockall(void)}
942 Sblocca la paginazione per lo spazio di indirizzi del processo corrente.
944 \bodydesc{Codici di ritorno ed errori sono gli stessi di \func{mlock} e
945 \func{munlock}, con un kernel successivo al 2.6.9 l'uso di
946 \func{munlockall} senza la \itindex{capabilities} \textit{capability}
947 \const{CAP\_IPC\_LOCK} genera un errore di \errcode{EPERM}.}
950 L'argomento \param{flags} di \func{mlockall} permette di controllarne il
951 comportamento; esso può essere specificato come l'OR aritmetico delle due
953 \begin{basedescript}{\desclabelwidth{2.5cm}}
954 \item[\const{MCL\_CURRENT}] blocca tutte le pagine correntemente mappate nello
955 spazio di indirizzi del processo.
956 \item[\const{MCL\_FUTURE}] blocca tutte le pagine che verranno mappate nello
957 spazio di indirizzi del processo.
960 Con \func{mlockall} si possono bloccare tutte le pagine mappate nello spazio
961 di indirizzi del processo, sia che comprendano il \index{segmento!dati}
962 \index{segmento!testo} segmento di testo, di dati, lo \itindex{stack}
963 \textit{stack}, lo \itindex{heap} \textit{heap} e pure le funzioni di libreria
964 chiamate, i file mappati in memoria, i dati del kernel mappati in user space,
965 la memoria condivisa. L'uso dei flag permette di selezionare con maggior
966 finezza le pagine da bloccare, ad esempio limitandosi a tutte le pagine
967 allocate a partire da un certo momento.
969 In ogni caso un processo real-time che deve entrare in una
970 \index{sezione~critica} sezione critica deve provvedere a riservare memoria
971 sufficiente prima dell'ingresso, per scongiurare l'occorrenza di un eventuale
972 \itindex{page~fault} \textit{page fault} causato dal meccanismo di
973 \itindex{copy~on~write} \textit{copy on write}. Infatti se nella
974 \index{sezione~critica} sezione critica si va ad utilizzare memoria che non è
975 ancora stata riportata in RAM si potrebbe avere un \itindex{page~fault}
976 \textit{page fault} durante l'esecuzione della stessa, con conseguente
977 rallentamento (probabilmente inaccettabile) dei tempi di esecuzione.
979 In genere si ovvia a questa problematica chiamando una funzione che ha
980 allocato una quantità sufficientemente ampia di variabili automatiche, in modo
981 che esse vengano mappate in RAM dallo \itindex{stack} \textit{stack}, dopo di
982 che, per essere sicuri che esse siano state effettivamente portate in memoria,
985 \itindend{memory~locking}
988 % TODO documentare \func{madvise}
989 % TODO documentare \func{mincore}
992 \index{memoria~virtuale|)}
995 % \subsection{Gestione avanzata dell'allocazione della memoria}
996 % \label{sec:proc_mem_malloc_custom}
998 % TODO: trattare le funzionalità avanzate di \func{malloc}
999 % TODO: trattare \func{memalign}
1000 % TODO: trattare \func{valloc}
1001 % TODO: trattare \func{posix\_memalign}
1005 \section{Argomenti, opzioni ed ambiente di un processo}
1006 \label{sec:proc_options}
1008 Tutti i programmi hanno la possibilità di ricevere argomenti e opzioni quando
1009 vengono lanciati. Il passaggio degli argomenti è effettuato attraverso gli
1010 argomenti \param{argc} e \param{argv} della funzione \func{main}, che vengono
1011 passati al programma dalla shell (o dal processo che esegue la \func{exec},
1012 secondo le modalità che vedremo in sez.~\ref{sec:proc_exec}) quando questo
1013 viene messo in esecuzione.
1015 Oltre al passaggio degli argomenti, un'altra modalità che permette di passare
1016 delle informazioni che modifichino il comportamento di un programma è quello
1017 dell'uso del cosiddetto \textit{environment} (cioè l'uso delle
1018 \textsl{variabili di ambiente}). In questa sezione esamineremo le funzioni che
1019 permettono di gestire argomenti ed opzioni, e quelle che consentono di
1020 manipolare ed utilizzare le variabili di ambiente.
1023 \subsection{Il formato degli argomenti}
1024 \label{sec:proc_par_format}
1026 In genere il passaggio degli argomenti al programma viene effettuato dalla
1027 shell, che si incarica di leggere la linea di comando e di effettuarne la
1028 scansione (il cosiddetto \textit{parsing}) per individuare le parole che la
1029 compongono, ciascuna delle quali viene considerata un argomento. Di norma per
1030 individuare le parole viene usato come carattere di separazione lo spazio o il
1031 tabulatore, ma il comportamento è modificabile attraverso l'impostazione della
1032 variabile di ambiente \cmd{IFS}.
1036 \includegraphics[width=13cm]{img/argv_argc}
1037 \caption{Esempio dei valori di \param{argv} e \param{argc} generati nella
1038 scansione di una riga di comando.}
1039 \label{fig:proc_argv_argc}
1042 Nella scansione viene costruito il vettore di puntatori \param{argv} inserendo
1043 in successione il puntatore alla stringa costituente l'$n$-simo argomento; la
1044 variabile \param{argc} viene inizializzata al numero di argomenti trovati, in
1045 questo modo il primo argomento è sempre il nome del programma; un esempio di
1046 questo meccanismo è mostrato in fig.~\ref{fig:proc_argv_argc}.
1049 \subsection{La gestione delle opzioni}
1050 \label{sec:proc_opt_handling}
1052 In generale un programma Unix riceve da linea di comando sia gli argomenti che
1053 le opzioni, queste ultime sono standardizzate per essere riconosciute come
1054 tali: un elemento di \param{argv} che inizia con il carattere \texttt{'-'} e
1055 che non sia un singolo \texttt{'-'} o un \texttt{'-{}-'} viene considerato
1056 un'opzione. In genere le opzioni sono costituite da una lettera singola
1057 (preceduta dal carattere \cmd{'-'}) e possono avere o no un parametro
1058 associato; un comando tipico può essere quello mostrato in
1059 fig.~\ref{fig:proc_argv_argc}. In quel caso le opzioni sono \cmd{-r} e \cmd{-m}
1060 e la prima vuole un parametro mentre la seconda no (\cmd{questofile.txt} è un
1061 argomento del programma, non un parametro di \cmd{-m}).
1063 Per gestire le opzioni all'interno dei argomenti a linea di comando passati in
1064 \param{argv} le librerie standard del C forniscono la funzione \funcd{getopt},
1065 che ha il seguente prototipo:
1066 \begin{prototype}{unistd.h}
1067 {int getopt(int argc, char *const argv[], const char *optstring)}
1068 Esegue il parsing degli argomenti passati da linea di comando
1069 riconoscendo le possibili opzioni segnalate con \param{optstring}.
1071 \bodydesc{Ritorna il carattere che segue l'opzione, \cmd{':'} se manca un
1072 parametro all'opzione, \cmd{'?'} se l'opzione è sconosciuta, e -1 se non
1073 esistono altre opzioni.}
1076 Questa funzione prende come argomenti le due variabili \param{argc} e
1077 \param{argv} passate a \func{main} ed una stringa che indica quali sono le
1078 opzioni valide; la funzione effettua la scansione della lista degli argomenti
1079 ricercando ogni stringa che comincia con \cmd{-} e ritorna ogni volta che
1080 trova un'opzione valida.
1082 La stringa \param{optstring} indica quali sono le opzioni riconosciute ed è
1083 costituita da tutti i caratteri usati per identificare le singole opzioni, se
1084 l'opzione ha un parametro al carattere deve essere fatto seguire un segno di
1085 due punti \texttt{':'}; nel caso di fig.~\ref{fig:proc_argv_argc} ad esempio la
1086 stringa di opzioni avrebbe dovuto contenere \texttt{"r:m"}.
1088 La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
1089 funzione all'interno di un ciclo, fintanto che essa non ritorna il valore -1
1090 che indica che non ci sono più opzioni. Nel caso si incontri un'opzione non
1091 dichiarata in \param{optstring} viene ritornato il carattere \texttt{'?'}
1092 mentre se un'opzione che lo richiede non è seguita da un parametro viene
1093 ritornato il carattere \texttt{':'}, infine se viene incontrato il valore
1094 \texttt{'-{}-'} la scansione viene considerata conclusa, anche se vi sono altri
1095 elementi di \param{argv} che cominciano con il carattere \texttt{'-'}.
1098 \footnotesize \centering
1099 \begin{minipage}[c]{15.6cm}
1100 \includecodesample{listati/option_code.c}
1103 \caption{Esempio di codice per la gestione delle opzioni.}
1104 \label{fig:proc_options_code}
1107 Quando la funzione trova un'opzione essa ritorna il valore numerico del
1108 carattere, in questo modo si possono eseguire azioni specifiche usando uno
1109 \code{switch}; \func{getopt} inoltre inizializza alcune variabili globali:
1111 \item \var{char *optarg} contiene il puntatore alla stringa parametro
1113 \item \var{int optind} alla fine della scansione restituisce l'indice del
1114 primo elemento di \param{argv} che non è un'opzione.
1115 \item \var{int opterr} previene, se posto a zero, la stampa di un messaggio
1116 di errore in caso di riconoscimento di opzioni non definite.
1117 \item \var{int optopt} contiene il carattere dell'opzione non riconosciuta.
1120 In fig.~\ref{fig:proc_options_code} è mostrata la sezione del programma
1121 \file{ForkTest.c} (che useremo nel prossimo capitolo per effettuare dei test
1122 sulla creazione dei processi) deputata alla decodifica delle opzioni a riga di
1125 Si può notare che si è anzitutto (\texttt{\small 1}) disabilitata la stampa di
1126 messaggi di errore per opzioni non riconosciute, per poi passare al ciclo per
1127 la verifica delle opzioni (\texttt{\small 2-27}); per ciascuna delle opzioni
1128 possibili si è poi provveduto ad un'azione opportuna, ad esempio per le tre
1129 opzioni che prevedono un parametro si è effettuata la decodifica del medesimo
1130 (il cui indirizzo è contenuto nella variabile \var{optarg}) avvalorando la
1131 relativa variabile (\texttt{\small 12-14}, \texttt{\small 15-17} e
1132 \texttt{\small 18-20}). Completato il ciclo troveremo in \var{optind} l'indice
1133 in \code{argv[]} del primo degli argomenti rimanenti nella linea di comando.
1135 Normalmente \func{getopt} compie una permutazione degli elementi di
1136 \param{argv} cosicché alla fine della scansione gli elementi che non sono
1137 opzioni sono spostati in coda al vettore. Oltre a questa esistono altre due
1138 modalità di gestire gli elementi di \param{argv}; se \param{optstring} inizia
1139 con il carattere \texttt{'+'} (o è impostata la variabile di ambiente
1140 \macro{POSIXLY\_CORRECT}) la scansione viene fermata non appena si incontra un
1141 elemento che non è un'opzione. L'ultima modalità, usata quando un programma
1142 può gestire la mescolanza fra opzioni e argomenti, ma se li aspetta in un
1143 ordine definito, si attiva quando \param{optstring} inizia con il carattere
1144 \texttt{'-'}. In questo caso ogni elemento che non è un'opzione viene
1145 considerato comunque un'opzione e associato ad un valore di ritorno pari ad 1,
1146 questo permette di identificare gli elementi che non sono opzioni, ma non
1147 effettua il riordinamento del vettore \param{argv}.
1150 \subsection{Le variabili di ambiente}
1151 \label{sec:proc_environ}
1153 Oltre agli argomenti passati a linea di comando ogni processo riceve dal
1154 sistema un \textsl{ambiente}, nella forma di una lista di variabili (detta
1155 \textit{environment list}) messa a disposizione dal processo, e costruita
1156 nella chiamata alla funzione \func{exec} quando questo viene lanciato.
1158 Come per la lista degli argomenti anche questa lista è un vettore di puntatori
1159 a caratteri, ciascuno dei quali punta ad una stringa, terminata da un
1160 \val{NULL}. A differenza di \code{argv[]} in questo caso non si ha una
1161 lunghezza del vettore data da un equivalente di \param{argc}, ma la lista è
1162 terminata da un puntatore nullo.
1164 L'indirizzo della lista delle variabili di ambiente è passato attraverso la
1165 variabile globale \var{environ}, a cui si può accedere attraverso una semplice
1166 dichiarazione del tipo:
1167 \includecodesnip{listati/env_ptr.c}
1168 un esempio della struttura di questa lista, contenente alcune delle variabili
1169 più comuni che normalmente sono definite dal sistema, è riportato in
1170 fig.~\ref{fig:proc_envirno_list}.
1173 \includegraphics[width=13cm]{img/environ_var}
1174 \caption{Esempio di lista delle variabili di ambiente.}
1175 \label{fig:proc_envirno_list}
1178 Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
1179 \textsl{\texttt{nome=valore}}. Inoltre alcune variabili, come quelle elencate
1180 in fig.~\ref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
1181 da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
1182 usare nomi espressi in caratteri maiuscoli.\footnote{la convenzione vuole che
1183 si usino dei nomi maiuscoli per le variabili di ambiente di uso generico, i
1184 nomi minuscoli sono in genere riservati alle variabili interne degli script
1187 Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
1188 riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
1189 costituiscono un modo comodo per definire un comportamento specifico senza
1190 dover ricorrere all'uso di opzioni a linea di comando o di file di
1191 configurazione. É di norma cura della shell, quando esegue un comando, passare
1192 queste variabili al programma messo in esecuzione attraverso un uso opportuno
1193 delle relative chiamate (si veda sez.~\ref{sec:proc_exec}).
1195 La shell ad esempio ne usa molte per il suo funzionamento (come \texttt{PATH}
1196 per la ricerca dei comandi, o \texttt{IFS} per la scansione degli argomenti),
1197 e alcune di esse (come \texttt{HOME}, \texttt{USER}, ecc.) sono definite al
1198 login (per i dettagli si veda sez.~\ref{sec:sess_login}). In genere è cura
1199 dell'amministratore definire le opportune variabili di ambiente in uno script
1200 di avvio. Alcune servono poi come riferimento generico per molti programmi
1201 (come \texttt{EDITOR} che indica l'editor preferito da invocare in caso di
1204 Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
1205 comuni), come riportato in tab.~\ref{tab:proc_env_var}. GNU/Linux le supporta
1206 tutte e ne definisce anche altre: per una lista più completa si può
1207 controllare \cmd{man 5 environ}.
1212 \begin{tabular}[c]{|l|c|c|c|p{7cm}|}
1214 \textbf{Variabile} & \textbf{POSIX} & \textbf{XPG3}
1215 & \textbf{Linux} & \textbf{Descrizione} \\
1218 \texttt{USER} &$\bullet$&$\bullet$&$\bullet$& Nome utente\\
1219 \texttt{LOGNAME}&$\bullet$&$\bullet$&$\bullet$& Nome di login\\
1220 \texttt{HOME} &$\bullet$&$\bullet$&$\bullet$& Directory base
1222 \texttt{LANG} &$\bullet$&$\bullet$&$\bullet$& Localizzazione\\
1223 \texttt{PATH} &$\bullet$&$\bullet$&$\bullet$& Elenco delle directory
1225 \texttt{PWD} &$\bullet$&$\bullet$&$\bullet$& Directory corrente\\
1226 \texttt{SHELL} &$\bullet$&$\bullet$&$\bullet$& Shell in uso\\
1227 \texttt{TERM} &$\bullet$&$\bullet$&$\bullet$& Tipo di terminale\\
1228 \texttt{PAGER} &$\bullet$&$\bullet$&$\bullet$& Programma per vedere i
1230 \texttt{EDITOR} &$\bullet$&$\bullet$&$\bullet$& Editor preferito\\
1231 \texttt{BROWSER}&$\bullet$&$\bullet$&$\bullet$& Browser preferito\\
1232 \texttt{TMPDIR} &$\bullet$&$\bullet$&$\bullet$& Directory dei file
1236 \caption{Esempi delle variabili di ambiente più comuni definite da vari
1238 \label{tab:proc_env_var}
1241 Lo standard ANSI C prevede l'esistenza di un ambiente, e pur non entrando
1242 nelle specifiche di come sono strutturati i contenuti, definisce la funzione
1243 \funcd{getenv} che permette di ottenere i valori delle variabili di ambiente;
1245 \begin{prototype}{stdlib.h}{char *getenv(const char *name)}
1246 Esamina l'ambiente del processo cercando una stringa che corrisponda a
1247 quella specificata da \param{name}.
1249 \bodydesc{La funzione ritorna \val{NULL} se non trova nulla, o il
1250 puntatore alla stringa che corrisponde (di solito nella forma
1251 \cmd{NOME=valore}).}
1254 Oltre a questa funzione di lettura, che è l'unica definita dallo standard ANSI
1255 C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
1256 utilizzare per impostare e per cancellare le variabili di ambiente. Uno schema
1257 delle funzioni previste nei vari standard e disponibili in Linux è riportato
1258 in tab.~\ref{tab:proc_env_func}.
1263 \begin{tabular}[c]{|l|c|c|c|c|c|c|}
1265 \textbf{Funzione} & \textbf{ANSI C} & \textbf{POSIX.1} & \textbf{XPG3} &
1266 \textbf{SVr4} & \textbf{BSD} & \textbf{Linux} \\
1269 \func{getenv} & $\bullet$ & $\bullet$ & $\bullet$
1270 & $\bullet$ & $\bullet$ & $\bullet$ \\
1271 \func{setenv} & -- & -- & --
1272 & -- & $\bullet$ & $\bullet$ \\
1273 \func{unsetenv}& -- & -- & --
1274 & -- & $\bullet$ & $\bullet$ \\
1275 \func{putenv} & -- & opz. & $\bullet$
1276 & -- & $\bullet$ & $\bullet$ \\
1277 \func{clearenv}& -- & opz. & --
1278 & -- & -- & $\bullet$ \\
1281 \caption{Funzioni per la gestione delle variabili di ambiente.}
1282 \label{tab:proc_env_func}
1285 In Linux\footnote{in realtà nelle libc4 e libc5 sono definite solo le prime
1286 quattro, \func{clearenv} è stata introdotta con le \acr{glibc} 2.0.} sono
1287 definite tutte le funzioni elencate in tab.~\ref{tab:proc_env_func}. La prima,
1288 \func{getenv}, l'abbiamo appena esaminata; delle restanti le prime due,
1289 \funcd{putenv} e \funcd{setenv}, servono per assegnare nuove variabili di
1290 ambiente, i loro prototipi sono i seguenti:
1294 \funcdecl{int setenv(const char *name, const char *value, int overwrite)}
1295 Imposta la variabile di ambiente \param{name} al valore \param{value}.
1297 \funcdecl{int putenv(char *string)} Aggiunge la stringa \param{string}
1300 \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 per un
1301 errore, che è sempre \errval{ENOMEM}.}
1303 \noindent la terza, \funcd{unsetenv}, serve a cancellare una variabile di
1304 ambiente; il suo prototipo è:
1308 \funcdecl{void unsetenv(const char *name)} Rimuove la variabile di ambiente
1311 \noindent questa funzione elimina ogni occorrenza della variabile specificata;
1312 se essa non esiste non succede nulla. Non è prevista (dato che la funzione è
1313 \ctyp{void}) nessuna segnalazione di errore.
1315 Per modificare o aggiungere una variabile di ambiente si possono usare sia
1316 \func{setenv} che \func{putenv}. La prima permette di specificare
1317 separatamente nome e valore della variabile di ambiente, inoltre il valore di
1318 \param{overwrite} specifica il comportamento della funzione nel caso la
1319 variabile esista già, sovrascrivendola se diverso da zero, lasciandola
1320 immutata se uguale a zero.
1322 La seconda funzione prende come argomento una stringa analoga a quella
1323 restituita da \func{getenv}, e sempre nella forma \code{NOME=valore}. Se la
1324 variabile specificata non esiste la stringa sarà aggiunta all'ambiente, se
1325 invece esiste il suo valore sarà impostato a quello specificato da
1326 \param{string}. Si tenga presente che, seguendo lo standard SUSv2, le
1327 \acr{glibc} successive alla versione 2.1.2 aggiungono\footnote{il
1328 comportamento è lo stesso delle vecchie \acr{libc4} e \acr{libc5}; nelle
1329 \acr{glibc}, dalla versione 2.0 alla 2.1.1, veniva invece fatta una copia,
1330 seguendo il comportamento di BSD4.4; dato che questo può dar luogo a perdite
1331 di memoria e non rispetta lo standard. Il comportamento è stato modificato a
1332 partire dalle 2.1.2, eliminando anche, sempre in conformità a SUSv2,
1333 l'attributo \direct{const} dal prototipo.} \param{string} alla lista delle
1334 variabili di ambiente; pertanto ogni cambiamento alla stringa in questione si
1335 riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
1336 questa funzione una variabile automatica (per evitare i problemi esposti in
1337 sez.~\ref{sec:proc_auto_var}).
1339 Si tenga infine presente che se si passa a \func{putenv} solo il nome di una
1340 variabile (cioè \param{string} è nella forma \texttt{NAME} e non contiene un
1341 carattere \texttt{'='}) allora questa viene cancellata dall'ambiente. Infine
1342 se la chiamata di \func{putenv} comporta la necessità di allocare una nuova
1343 versione del vettore \var{environ} questo sarà allocato, ma la versione
1344 corrente sarà deallocata solo se anch'essa è risultante da un'allocazione
1345 fatta in precedenza da un'altra \func{putenv}. Questo perché il vettore delle
1346 variabili di ambiente iniziale, creato dalla chiamata ad \func{exec} (vedi
1347 sez.~\ref{sec:proc_exec}) è piazzato al di sopra dello \itindex{stack} stack,
1348 (vedi fig.~\ref{fig:proc_mem_layout}) e non nello \itindex{heap} \textit{heap}
1349 e non può essere deallocato. Inoltre la memoria associata alle variabili di
1350 ambiente eliminate non viene liberata.
1352 L'ultima funzione è \funcd{clearenv}, che viene usata per cancellare
1353 completamente tutto l'ambiente; il suo prototipo è:
1357 \funcdecl{int clearenv(void)}
1358 Cancella tutto l'ambiente.
1360 \bodydesc{la funzione restituisce 0 in caso di successo e un valore diverso
1361 da zero per un errore.}
1364 In genere si usa questa funzione in maniera precauzionale per evitare i
1365 problemi di sicurezza connessi nel trasmettere ai programmi che si invocano un
1366 ambiente che può contenere dei dati non controllati. In tal caso si provvede
1367 alla cancellazione di tutto l'ambiente per costruirne una versione
1368 ``\textsl{sicura}'' da zero.
1371 \subsection{Opzioni in formato esteso}
1372 \label{sec:proc_opt_extended}
1374 Oltre alla modalità ordinaria di gestione delle opzioni trattata in
1375 sez.~\ref{sec:proc_opt_handling} le \acr{glibc} forniscono una modalità
1376 alternativa costituita dalle cosiddette \textit{long-options}, che consente di
1377 esprimere le opzioni in una forma più descrittiva che nel caso più generale è
1378 qualcosa del tipo di ``\texttt{-{}-option-name=parameter}''.
1380 (NdA: questa parte verrà inserita in seguito).
1382 % TODO opzioni in formato esteso
1386 \section{Problematiche di programmazione generica}
1387 \label{sec:proc_gen_prog}
1389 Benché questo non sia un libro di C, è opportuno affrontare alcune delle
1390 problematiche generali che possono emergere nella programmazione e di quali
1391 precauzioni o accorgimenti occorre prendere per risolverle. Queste
1392 problematiche non sono specifiche di sistemi unix-like o multitasking, ma
1393 avendo trattato in questo capitolo il comportamento dei processi visti come
1394 entità a sé stanti, le riportiamo qui.
1397 \subsection{Il passaggio delle variabili e dei valori di ritorno}
1398 \label{sec:proc_var_passing}
1400 Una delle caratteristiche standard del C è che le variabili vengono passate
1401 alle subroutine attraverso un meccanismo che viene chiamato \textit{by value}
1402 (diverso ad esempio da quanto avviene con il Fortran, dove le variabili sono
1403 passate, come suol dirsi, \textit{by reference}, o dal C++ dove la modalità
1404 del passaggio può essere controllata con l'operatore \cmd{\&}).
1406 Il passaggio di una variabile \textit{by value} significa che in realtà quello
1407 che viene passato alla subroutine è una copia del valore attuale di quella
1408 variabile, copia che la subroutine potrà modificare a piacere, senza che il
1409 valore originale nella funzione chiamante venga toccato. In questo modo non
1410 occorre preoccuparsi di eventuali effetti delle operazioni della subroutine
1411 sulla variabile passata come argomento.
1413 Questo però va inteso nella maniera corretta. Il passaggio \textit{by value}
1414 vale per qualunque variabile, puntatori compresi; quando però in una
1415 subroutine si usano dei puntatori (ad esempio per scrivere in un buffer) in
1416 realtà si va a modificare la zona di memoria a cui essi puntano, per cui anche
1417 se i puntatori sono copie, i dati a cui essi puntano sono sempre gli stessi, e
1418 le eventuali modifiche avranno effetto e saranno visibili anche nella funzione
1421 Nella maggior parte delle funzioni di libreria e delle system call i puntatori
1422 vengono usati per scambiare dati (attraverso buffer o strutture) e le
1423 variabili semplici vengono usate per specificare argomenti; in genere le
1424 informazioni a riguardo dei risultati vengono passate alla funzione chiamante
1425 attraverso il valore di ritorno. È buona norma seguire questa pratica anche
1426 nella programmazione normale.
1428 Talvolta però è necessario che la funzione possa restituire indietro alla
1429 funzione chiamante un valore relativo ad uno dei suoi argomenti. Per far
1430 questo si usa il cosiddetto \itindex{value~result~argument} \textit{value
1431 result argument}, si passa cioè, invece di una normale variabile, un
1432 puntatore alla stessa; vedremo alcuni esempi di questa modalità nelle funzioni
1433 che gestiscono i socket (in sez.~\ref{sec:TCP_functions}), in cui, per
1434 permettere al kernel di restituire informazioni sulle dimensioni delle
1435 strutture degli indirizzi utilizzate, viene usato questo meccanismo.
1438 \subsection{Il passaggio di un numero variabile di argomenti}
1439 \label{sec:proc_variadic}
1441 Come vedremo nei capitoli successivi, non sempre è possibile specificare un
1442 numero fisso di argomenti per una funzione. Lo standard ISO C prevede nella
1443 sua sintassi la possibilità di definire delle \index{variadic}
1444 \textit{variadic function} che abbiano un numero variabile di argomenti,
1445 attraverso l'uso nella dichiarazione della funzione dello speciale costrutto
1446 ``\texttt{\textellipsis}'', che viene chiamato \textit{ellipsis}.
1448 Lo standard però non provvede a livello di linguaggio alcun meccanismo con cui
1449 dette funzioni possono accedere ai loro argomenti. L'accesso viene pertanto
1450 realizzato a livello delle librerie standard del C che provvedono gli
1451 strumenti adeguati. L'uso di una \textit{variadic function} prevede quindi
1454 \item \textsl{Dichiarare} la funzione come \textit{variadic} usando un
1455 prototipo che contenga una \textit{ellipsis}.
1456 \item \textsl{Definire} la funzione come \textit{variadic} usando la stessa
1457 \textit{ellipsis}, ed utilizzare le apposite macro che consentono la
1458 gestione di un numero variabile di argomenti.
1459 \item \textsl{Invocare} la funzione specificando prima gli argomenti fissi, ed
1460 a seguire quelli addizionali.
1463 Lo standard ISO C prevede che una \index{variadic} \textit{variadic function}
1464 abbia sempre almeno un argomento fisso; prima di effettuare la dichiarazione
1465 deve essere incluso l'apposito header file \file{stdarg.h}; un esempio di
1466 dichiarazione è il prototipo della funzione \func{execl} che vedremo in
1467 sez.~\ref{sec:proc_exec}:
1468 \includecodesnip{listati/exec_sample.c}
1469 in questo caso la funzione prende due argomenti fissi ed un numero variabile
1470 di altri argomenti (che verranno a costituire gli elementi successivi al primo
1471 del vettore \param{argv} passato al nuovo processo). Lo standard ISO C
1472 richiede inoltre che l'ultimo degli argomenti fissi sia di tipo
1473 \textit{self-promoting}\footnote{il linguaggio C prevede che quando si
1474 mescolano vari tipi di dati, alcuni di essi possano essere \textsl{promossi}
1475 per compatibilità; ad esempio i tipi \ctyp{float} vengono convertiti
1476 automaticamente a \ctyp{double} ed i \ctyp{char} e gli \ctyp{short} ad
1477 \ctyp{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
1478 a sé stesso.} il che esclude vettori, puntatori a funzioni e interi di tipo
1479 \ctyp{char} o \ctyp{short} (con segno o meno). Una restrizione ulteriore di
1480 alcuni compilatori è di non dichiarare l'ultimo argomento fisso come
1483 Una volta dichiarata la funzione il secondo passo è accedere ai vari argomenti
1484 quando la si va a definire. Gli argomenti fissi infatti hanno un loro nome, ma
1485 quelli variabili vengono indicati in maniera generica dalla \textit{ellipsis}.
1487 L'unica modalità in cui essi possono essere recuperati è pertanto quella
1488 sequenziale; essi verranno estratti dallo \itindex{stack} \textit{stack}
1489 secondo l'ordine in cui sono stati scritti. Per fare questo in \file{stdarg.h}
1490 sono definite delle apposite macro; la procedura da seguire è la seguente:
1492 \item Inizializzare un puntatore alla lista degli argomenti di tipo
1493 \macro{va\_list} attraverso la macro \macro{va\_start}.
1494 \item Accedere ai vari argomenti opzionali con chiamate successive alla macro
1495 \macro{va\_arg}, la prima chiamata restituirà il primo argomento, la seconda
1496 il secondo e così via.
1497 \item Dichiarare la conclusione dell'estrazione degli argomenti invocando la
1498 macro \macro{va\_end}.
1500 In generale è perfettamente legittimo richiedere meno argomenti di quelli che
1501 potrebbero essere stati effettivamente forniti, e nella esecuzione delle
1502 \macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
1503 saranno ignorati; se invece si richiedono più argomenti di quelli forniti si
1504 otterranno dei valori indefiniti. Nel caso del \cmd{gcc} l'uso della macro
1505 \macro{va\_end} è inutile, ma si consiglia di usarlo ugualmente per
1508 Le definizioni delle tre macro sono le seguenti:
1512 \funcdecl{void va\_start(va\_list ap, last)} Inizializza il puntatore alla
1513 lista di argomenti \param{ap}; il parametro \param{last} \emph{deve} essere
1514 l'ultimo degli argomenti fissi.
1516 \funcdecl{type va\_arg(va\_list ap, type)} Restituisce il valore del
1517 successivo argomento opzionale, modificando opportunamente \param{ap}; la
1518 macro richiede che si specifichi il tipo dell'argomento attraverso il
1519 parametro \param{type} che deve essere il nome del tipo dell'argomento in
1520 questione. Il tipo deve essere \textit{self-promoting}.
1522 \funcdecl{void va\_end(va\_list ap)} Conclude l'uso di \param{ap}.
1525 In generale si possono avere più puntatori alla lista degli argomenti,
1526 ciascuno andrà inizializzato con \macro{va\_start} e letto con \macro{va\_arg}
1527 e ciascuno potrà scandire la lista degli argomenti per conto suo.
1529 Dopo l'uso di \macro{va\_end} la variabile \param{ap} diventa indefinita e
1530 successive chiamate a \macro{va\_arg} non funzioneranno. Si avranno risultati
1531 indefiniti anche chiamando \macro{va\_arg} specificando un tipo che non
1532 corrisponde a quello dell'argomento.
1534 Un altro limite delle macro è che i passi 1) e 3) devono essere eseguiti nel
1535 corpo principale della funzione, il passo 2) invece può essere eseguito anche
1536 in una subroutine passandole il puntatore alla lista di argomenti; in questo
1537 caso però si richiede che al ritorno della funzione il puntatore non venga più
1538 usato (lo standard richiederebbe la chiamata esplicita di \macro{va\_end}),
1539 dato che il valore di \param{ap} risulterebbe indefinito.
1541 Esistono dei casi in cui è necessario eseguire più volte la scansione degli
1542 argomenti e poter memorizzare una posizione durante la stessa. La cosa più
1543 naturale in questo caso sembrerebbe quella di copiarsi il puntatore alla lista
1544 degli argomenti con una semplice assegnazione. Dato che una delle
1545 realizzazioni più comuni di \macro{va\_list} è quella di un puntatore nello
1546 \itindex{stack} \textit{stack} all'indirizzo dove sono stati salvati gli
1547 argomenti, è assolutamente normale pensare di poter effettuare questa
1550 In generale però possono esistere anche realizzazioni diverse, per questo
1551 motivo \macro{va\_list} è definito come \index{tipo!opaco} \textsl{tipo opaco}
1552 e non può essere assegnato direttamente ad un'altra variabile dello stesso
1553 tipo. Per risolvere questo problema lo standard ISO C99\footnote{alcuni
1554 sistemi che non hanno questa macro provvedono al suo posto
1555 \macro{\_\_va\_copy} che era il nome proposto in una bozza dello standard.}
1556 ha previsto una macro ulteriore che permette di eseguire la copia di un
1557 puntatore alla lista degli argomenti:
1558 \begin{prototype}{stdarg.h}{void va\_copy(va\_list dest, va\_list src)}
1559 Copia l'attuale valore \param{src} del puntatore alla lista degli argomenti
1562 \noindent anche in questo caso è buona norma chiudere ogni esecuzione di una
1563 \macro{va\_copy} con una corrispondente \macro{va\_end} sul nuovo puntatore
1564 alla lista degli argomenti.
1566 La chiamata di una funzione con un numero variabile di argomenti, posto che la
1567 si sia dichiarata e definita come tale, non prevede nulla di particolare;
1568 l'invocazione è identica alle altre, con gli argomenti, sia quelli fissi che
1569 quelli opzionali, separati da virgole. Quello che però è necessario tenere
1570 presente è come verranno convertiti gli argomenti variabili.
1572 In Linux gli argomenti dello stesso tipo sono passati allo stesso modo, sia
1573 che siano fissi sia che siano opzionali (alcuni sistemi trattano diversamente
1574 gli opzionali), ma dato che il prototipo non può specificare il tipo degli
1575 argomenti opzionali, questi verranno sempre promossi, pertanto nella ricezione
1576 dei medesimi occorrerà tenerne conto (ad esempio un \ctyp{char} verrà visto da
1577 \macro{va\_arg} come \ctyp{int}).
1579 Uno dei problemi che si devono affrontare con le funzioni con un numero
1580 variabile di argomenti è che non esiste un modo generico che permetta di
1581 stabilire quanti sono gli argomenti passati effettivamente in una chiamata.
1583 Esistono varie modalità per affrontare questo problema; una delle più
1584 immediate è quella di specificare il numero degli argomenti opzionali come uno
1585 degli argomenti fissi. Una variazione di questo metodo è l'uso di un argomento
1586 per specificare anche il tipo degli argomenti (come fa la stringa di formato
1589 Una modalità diversa, che può essere applicata solo quando il tipo degli
1590 argomenti lo rende possibile, è quella che prevede di usare un valore speciale
1591 come ultimo argomento (come fa ad esempio \func{execl} che usa un puntatore
1592 \val{NULL} per indicare la fine della lista degli argomenti).
1595 \subsection{Potenziali problemi con le variabili automatiche}
1596 \label{sec:proc_auto_var}
1598 Uno dei possibili problemi che si possono avere con le subroutine è quello di
1599 restituire alla funzione chiamante dei dati che sono contenuti in una
1600 variabile automatica. Ovviamente quando la subroutine ritorna la sezione
1601 dello \itindex{stack} \textit{stack} che conteneva la variabile automatica
1602 potrà essere riutilizzata da una nuova funzione, con le immaginabili
1603 conseguenze di sovrapposizione e sovrascrittura dei dati.
1605 Per questo una delle regole fondamentali della programmazione in C è che
1606 all'uscita di una funzione non deve restare nessun riferimento alle variabili
1607 locali; qualora sia necessario utilizzare variabili che possano essere viste
1608 anche dalla funzione chiamante queste devono essere allocate esplicitamente, o
1609 in maniera statica (usando variabili di tipo \ctyp{static} o \ctyp{extern}), o
1610 dinamicamente con una delle funzioni della famiglia \func{malloc}.
1613 \subsection{Il controllo di flusso non locale}
1614 \label{sec:proc_longjmp}
1616 Il controllo del flusso di un programma in genere viene effettuato con le
1617 varie istruzioni del linguaggio C; fra queste la più bistrattata è il
1618 \code{goto}, che viene deprecato in favore dei costrutti della programmazione
1619 strutturata, che rendono il codice più leggibile e mantenibile. Esiste però un
1620 caso in cui l'uso di questa istruzione porta all'implementazione più
1621 efficiente e più chiara anche dal punto di vista della struttura del
1622 programma: quello dell'uscita in caso di errore.
1624 \index{salto~non-locale|(}
1626 Il C però non consente di effettuare un salto ad una etichetta definita in
1627 un'altra funzione, per cui se l'errore avviene in una funzione, e la sua
1628 gestione ordinaria è in un'altra, occorre usare quello che viene chiamato un
1629 \textsl{salto non-locale}. Il caso classico in cui si ha questa necessità,
1630 citato sia in \cite{APUE} che in \cite{glibc}, è quello di un programma nel
1631 cui corpo principale vengono letti dei dati in ingresso sui quali viene
1632 eseguita, tramite una serie di funzioni di analisi, una scansione dei
1633 contenuti, da cui si ottengono le indicazioni per l'esecuzione di opportune
1636 Dato che l'analisi può risultare molto complessa, ed opportunamente suddivisa
1637 in fasi diverse, la rilevazione di un errore nei dati in ingresso può accadere
1638 all'interno di funzioni profondamente annidate l'una nell'altra. In questo
1639 caso si dovrebbe gestire, per ciascuna fase, tutta la casistica del passaggio
1640 all'indietro di tutti gli errori rilevabili dalle funzioni usate nelle fasi
1641 successive. Questo comporterebbe una notevole complessità, mentre sarebbe
1642 molto più comodo poter tornare direttamente al ciclo di lettura principale,
1643 scartando l'input come errato.\footnote{a meno che, come precisa \cite{glibc},
1644 alla chiusura di ciascuna fase non siano associate operazioni di pulizia
1645 specifiche (come deallocazioni, chiusure di file, ecc.), che non potrebbero
1646 essere eseguite con un salto non-locale.}
1648 Tutto ciò può essere realizzato proprio con un salto non-locale; questo di
1649 norma viene realizzato salvando il contesto dello \itindex{stack}
1650 \textit{stack} nel punto in cui si vuole tornare in caso di errore, e
1651 ripristinandolo, in modo da tornare nella funzione da cui si era partiti,
1652 quando serve. La funzione che permette di salvare il contesto dello
1653 \itindex{stack} \textit{stack} è \funcd{setjmp}, il cui prototipo è:
1656 \funcdecl{int setjmp(jmp\_buf env)}
1658 Salva il contesto dello stack.
1660 \bodydesc{La funzione ritorna zero quando è chiamata direttamente e un
1661 valore diverso da zero quando ritorna da una chiamata di \func{longjmp}
1662 che usa il contesto salvato in precedenza.}
1665 Quando si esegue la funzione il contesto corrente dello \itindex{stack}
1666 \textit{stack} viene salvato nell'argomento \param{env}, una variabile di tipo
1667 \type{jmp\_buf}\footnote{questo è un classico esempio di variabile di
1668 \index{tipo!opaco} \textsl{tipo opaco}. Si definiscono così strutture ed
1669 altri oggetti usati da una libreria, la cui struttura interna non deve
1670 essere vista dal programma chiamante (da cui il nome) che li devono
1671 utilizzare solo attraverso dalle opportune funzioni di gestione.} che deve
1672 essere stata definita in precedenza. In genere le variabili di tipo
1673 \type{jmp\_buf} vengono definite come variabili globali in modo da poter
1674 essere viste in tutte le funzioni del programma.
1676 Quando viene eseguita direttamente la funzione ritorna sempre zero, un valore
1677 diverso da zero viene restituito solo quando il ritorno è dovuto ad una
1678 chiamata di \func{longjmp} in un'altra parte del programma che ripristina lo
1679 \itindex{stack} \textit{stack} effettuando il salto non-locale. Si tenga conto
1680 che il contesto salvato in \param{env} viene invalidato se la funzione che ha
1681 chiamato \func{setjmp} ritorna, nel qual caso un successivo uso di
1682 \func{longjmp} può comportare conseguenze imprevedibili (e di norma fatali)
1685 Come accennato per effettuare un salto non-locale ad
1686 un punto precedentemente stabilito con \func{setjmp} si usa la funzione
1687 \funcd{longjmp}; il suo prototipo è:
1690 \funcdecl{void longjmp(jmp\_buf env, int val)}
1692 Ripristina il contesto dello stack.
1694 \bodydesc{La funzione non ritorna.}
1697 La funzione ripristina il contesto dello \itindex{stack} \textit{stack}
1698 salvato da una chiamata a \func{setjmp} nell'argomento \param{env}. Dopo
1699 l'esecuzione della funzione il programma prosegue nel codice successivo al
1700 ritorno della \func{setjmp} con cui si era salvato \param{env}, che restituirà
1702 \param{val} invece di zero. Il valore di \param{val} specificato nella
1703 chiamata deve essere diverso da zero, se si è specificato 0 sarà comunque
1704 restituito 1 al suo posto.
1706 In sostanza un \func{longjmp} è analogo ad un \code{return}, solo che invece
1707 di ritornare alla riga successiva della funzione chiamante, il programma
1708 ritorna alla posizione della relativa \func{setjmp}, l'altra differenza è che
1709 il ritorno può essere effettuato anche attraverso diversi livelli di funzioni
1712 L'implementazione di queste funzioni comporta alcune restrizioni dato che esse
1713 interagiscono direttamente con la gestione dello \itindex{stack}
1714 \textit{stack} ed il funzionamento del compilatore stesso. In particolare
1715 \func{setjmp} è implementata con una macro, pertanto non si può cercare di
1716 ottenerne l'indirizzo, ed inoltre delle chiamate a questa funzione sono sicure
1717 solo in uno dei seguenti casi:
1719 \item come espressione di controllo in un comando condizionale, di selezione
1720 o di iterazione (come \code{if}, \code{switch} o \code{while});
1721 \item come operando per un operatore di uguaglianza o confronto in una
1722 espressione di controllo di un comando condizionale, di selezione o di
1724 \item come operando per l'operatore di negazione (\code{!}) in una espressione
1725 di controllo di un comando condizionale, di selezione o di iterazione;
1726 \item come espressione a sé stante.
1729 In generale, dato che l'unica differenza fra la chiamata diretta e quella
1730 ottenuta da un \func{longjmp} è costituita dal valore di ritorno di
1731 \func{setjmp}, essa è usualmente chiamata all'interno di un comando \code{if}.
1733 Uno dei punti critici dei salti non-locali è quello del valore delle
1734 variabili, ed in particolare quello delle variabili automatiche della funzione
1735 a cui si ritorna. In generale le variabili globali e statiche mantengono i
1736 valori che avevano al momento della chiamata di \func{longjmp}, ma quelli
1737 delle variabili automatiche (o di quelle dichiarate
1738 \direct{register}\footnote{la direttiva \direct{register} del compilatore
1739 chiede che la variabile dichiarata tale sia mantenuta, nei limiti del
1740 possibile, all'interno di un registro del processore. Questa direttiva è
1741 originaria dell'epoca dai primi compilatori, quando stava al programmatore
1742 scrivere codice ottimizzato, riservando esplicitamente alle variabili più
1743 usate l'uso dei registri del processore. Oggi questa direttiva è in disuso
1744 dato che tutti i compilatori sono normalmente in grado di valutare con
1745 maggior efficacia degli stessi programmatori quando sia il caso di eseguire
1746 questa ottimizzazione.}) sono in genere indeterminati.
1748 Quello che succede infatti è che i valori delle variabili che sono tenute in
1749 memoria manterranno il valore avuto al momento della chiamata di
1750 \func{longjmp}, mentre quelli tenuti nei registri del processore (che nella
1751 chiamata ad un'altra funzione vengono salvati nel contesto nello
1752 \itindex{stack} \textit{stack}) torneranno al valore avuto al momento della
1753 chiamata di \func{setjmp}; per questo quando si vuole avere un comportamento
1754 coerente si può bloccare l'ottimizzazione che porta le variabili nei registri
1755 dichiarandole tutte come \direct{volatile}.\footnote{la direttiva
1756 \direct{volatile} informa il compilatore che la variabile che è dichiarata
1757 può essere modificata, durante l'esecuzione del nostro, da altri programmi.
1758 Per questo motivo occorre dire al compilatore che non deve essere mai
1759 utilizzata l'ottimizzazione per cui quanto opportuno essa viene mantenuta in
1760 un registro, poiché in questo modo si perderebbero le eventuali modifiche
1761 fatte dagli altri programmi (che avvengono solo in una copia posta in
1764 \index{salto~non-locale|)}
1768 % LocalWords: like exec kernel thread main ld linux static linker char envp Gb
1769 % LocalWords: sez POSIX exit system call cap abort shell diff errno stdlib int
1770 % LocalWords: SUCCESS FAILURE void atexit stream fclose unistd descriptor init
1771 % LocalWords: SIGCHLD wait function glibc SunOS arg argp execve fig high kb Mb
1772 % LocalWords: memory alpha swap table printf Unit MMU paging fault SIGSEGV BSS
1773 % LocalWords: multitasking text segment NULL Block Started Symbol
1774 % LocalWords: heap stack calling convention size malloc calloc realloc nmemb
1775 % LocalWords: ENOMEM ptr uClib cfree error leak smartpointers hook Dmalloc brk
1776 % LocalWords: Gray Watson Electric Fence Bruce Perens sbrk longjmp SUSv BSD ap
1777 % LocalWords: ptrdiff increment locking lock copy write capabilities IPC mlock
1778 % LocalWords: capability MEMLOCK limits getpagesize RLIMIT munlock sys const
1779 % LocalWords: addr len EINVAL EPERM mlockall munlockall flags l'OR CURRENT IFS
1780 % LocalWords: argc argv parsing questofile txt getopt optstring switch optarg
1781 % LocalWords: optind opterr optopt ForkTest POSIXLY CORRECT long options NdA
1782 % LocalWords: option parameter list environ PATH HOME XPG tab LOGNAME LANG PWD
1783 % LocalWords: TERM PAGER TMPDIR getenv name SVr setenv unsetenv putenv opz gcc
1784 % LocalWords: clearenv libc value overwrite string reference result argument
1785 % LocalWords: socket variadic ellipsis header stdarg execl self promoting last
1786 % LocalWords: float double short register type dest src extern setjmp jmp buf
1787 % LocalWords: env return if while Di page cdecl
1788 % LocalWords: environment
1790 %%% Local Variables:
1792 %%% TeX-master: "gapil"