3 %% Copyright (C) 2000-2012 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. Questo non è del tutto vero nel caso di un programma
38 \textit{multi-thread}, ma la gestione dei \itindex{thread} \textit{thread} in
39 Linux sarà trattata a parte in cap.~\ref{cha:threads}.
42 \subsection{L'avvio e l'esecuzione di un programma}
45 \itindbeg{link-loader}
47 Quando un programma viene messo in esecuzione cosa che può essere fatta solo
48 con una funzione della famiglia \func{exec} (vedi sez.~\ref{sec:proc_exec}) il
49 kernel esegue un opportuno codice di avvio, il cosiddetto
50 \textit{link-loader}, costituito dal programma \cmd{ld-linux.so}. Questo
51 programma è una parte fondamentale del sistema il cui compito è quello della
52 gestione delle cosiddette \textsl{librerie condivise}, quelle che nel mondo
53 Windows sono chiamate DLL (\textit{Dinamic Link Library}), e che invece in un
54 sistema unix-like vengono chiamate \textit{shared objects}.
56 Infatti, a meno di non aver specificato il flag \texttt{-static} durante la
57 compilazione, tutti i programmi in Linux sono compilati facendo riferimento a
58 librerie condivise, in modo da evitare di duplicare lo stesso codice nei
59 relativi eseguibili e consentire un uso più efficiente della memoria, dato che
60 il codice di uno \itindex{shared~objects} \textit{shared objects} viene
61 caricato in memoria dal kernel una sola volta per tutti i programmi che lo
64 Questo significa però che normalmente il codice di un programma è incompleto,
65 contenendo solo i riferimenti alle funzioni di libreria che vuole utilizzare e
66 non il relativo codice. Per questo motivo all'avvio del programma è necessario
67 l'intervento del \textit{link-loader} il cui compito è
68 caricare in memoria le librerie condivise eventualmente assenti, ed effettuare
69 poi il collegamento dinamico del codice del programma alle funzioni di
70 libreria da esso utilizzate prima di metterlo in esecuzione.
72 Il funzionamento di \cmd{ld-linux.so} è controllato da alcune variabili di
73 ambiente e dal contenuto del file \conffile{/etc/ld.so.conf}, che consentono
74 di elencare le directory un cui cercare le librerie e determinare quali
75 verranno utilizzate. In particolare con la variabile di ambiente
76 \envvar{LD\_LIBRARY\_PATH} si possono indicare ulteriori directory rispetto a
77 quelle di sistema in cui inserire versioni personali delle librerie che hanno
78 la precedenza su quelle di sistema, mentre con la variabile di ambiente
79 \envvar{LD\_PRELOAD} si può passare direttamente una lista di file di librerie
80 condivise da usare al posto di quelli di sistema. In questo modo è possibile
81 effettuare lo sviluppo o il test di nuove librerie senza dover sostituire
82 quelle di sistema. Ulteriori dettagli sono riportati nella pagina di manuale
83 di \cmd{ld.so} e per un approfondimento dell'argomento si può consultare
84 sez.~3.1.2 di \cite{AGL}.
86 Una volta completate le operazioni di inizializzazione di \cmd{ld-linux.so}, il
87 sistema fa partire qualunque programma chiamando la funzione \code{main}. Sta
88 al programmatore chiamare così la funzione principale del programma da cui si
89 suppone che inizi l'esecuzione. In ogni caso senza questa funzione lo stesso
90 \textit{link-loader} darebbe luogo ad errori. Lo standard ISO C specifica che
91 la funzione \code{main} può non avere argomenti o prendere due argomenti che
92 rappresentano gli argomenti passati da linea di comando (su cui torneremo in
93 sez.~\ref{sec:proc_par_format}), in sostanza un prototipo che va sempre bene è
95 \includecodesnip{listati/main_def.c}
97 \itindend{link-loader}
99 In realtà nei sistemi Unix esiste un altro modo per definire la funzione
100 \code{main}, che prevede la presenza di un terzo argomento, \code{char
101 *envp[]}, che fornisce l'\textsl{ambiente} del programma; questa forma però
102 non è prevista dallo standard POSIX.1 per cui se si vogliono scrivere
103 programmi portabili è meglio evitarla. Per accedere all'ambiente, come vedremo
104 in sez.~\ref{sec:proc_environ} si usa in genere una variabile globale che
105 viene sempre definita automaticamente.
107 Ogni programma viene fatto partire mettendo in esecuzione il codice contenuto
108 nella funzione \code{main}, ogni altra funzione usata dal programma, che sia
109 ottenuta da una libreria condivisa, o che sia direttamente definita nel
110 codice, dovrà essere invocata a partire dal codice di \code{main}. Nel caso di
111 funzioni definite nel programma occorre tenere conto che, nel momento stesso
112 in cui si usano le librerie di sistema (vale a dire la \acr{glibc}) alcuni
113 nomi sono riservati e non possono essere utilizzati.
115 In particolare sono riservati a priori e non possono essere mai ridefiniti in
116 nessun caso i nomi di tutte le funzioni, le variabili, le macro di
117 preprocessore, ed i tipi di dati previsti dallo standard ISO C. Lo stesso
118 varrà per tutti i nomi definiti negli \textit{header file} che si sono
119 esplicitamente inclusi nel programma (vedi sez.~\ref{sec:proc_syscall}), ma
120 anche se è possibile riutilizzare nomi definiti in altri \textit{header file}
121 la pratica è da evitare nella maniera più assoluta per non generare ambiguità.
123 Oltre ai nomi delle funzioni di libreria sono poi riservati in maniera
124 generica tutti i nomi di variabili o funzioni globali che iniziano con il
125 carattere di sottolineato (``\texttt{\_}''), e qualunque nome che inizi con il
126 doppio sottolineato (``\texttt{\_\_}'') o con il sottolineato seguito da
127 lettera maiuscola. Questi identificativi infatti sono utilizzati per i nomi
128 usati internamente in forma privata dalle librerie, ed evitandone l'uso si
129 elimina il rischio di conflitti.
131 Infine esiste una serie di classi di nomi che sono riservati per un loro
132 eventuale uso futuro da parte degli standard ISO C e POSIX.1, questi in teoria
133 possono essere usati senza problemi oggi, ma potrebbero dare un conflitto con
134 una revisione futura di questi standard, per cui è comunque opportuno
135 evitarli, in particolare questi sono:
137 \item i nomi che iniziano per ``\texttt{E}'' costituiti da lettere maiuscole e
138 numeri, che potrebbero essere utilizzati per nuovi codici di errore (vedi
139 sez.~\ref{sec:sys_errors}),
140 \item i nomi che iniziano con ``\texttt{is}'' o ``\texttt{to}'' e costituiti
141 da lettere minuscole che potrebbero essere utilizzati da nuove funzioni per
142 il controllo e la conversione del tipo di caratteri,
143 \item i nomi che iniziano con ``\texttt{LC\_}'' e costituiti
144 da lettere maiuscole che possono essere usato per macro attinenti la
145 localizzazione,% mettere in seguito (vedi sez.~\ref{sec:proc_localization}),
146 \item nomi che iniziano con ``\texttt{SIG}'' o ``\texttt{SIG\_}'' e costituiti
147 da lettere maiuscole che potrebbero essere usati per nuovi nomi di segnale
148 (vedi sez.~\ref{sec:sig_classification}),
149 \item nomi che iniziano con ``\texttt{str}'', ``\texttt{mem}'', o
150 ``\texttt{wcs}'' e costituiti da lettere minuscole che possono essere
151 utilizzati per funzioni attinenti la manipolazione delle stringhe e delle
153 \item nomi che terminano in ``\texttt{\_t}'' che potrebbero essere utilizzati
154 per la definizione di nuovi tipi di dati di sistema oltre quelli di
155 tab.~\ref{tab:intro_primitive_types}).
159 \subsection{Chiamate a funzioni e \textit{system call}}
160 \label{sec:proc_syscall}
162 Come accennato in sez.~\ref{sec:intro_syscall} un programma può utilizzare le
163 risorse che il sistema gli mette a disposizione attraverso l'uso delle
164 opportune \textit{system call}. Abbiamo inoltre appena visto come all'avvio un
165 programma venga messo in grado di chiamare le funzioni fornite da eventuali
166 librerie condivise da esso utilizzate.
168 Vedremo nel resto della guida quali sono le risorse del sistema accessibili
169 attraverso le \textit{system call} e tratteremo buona parte delle funzioni
170 messe a disposizione dalla libreria standard del C, in questa sezione però si
171 forniranno alcune indicazioni generali sul come fare perché un programma possa
172 utilizzare queste funzioni.
174 \itindbeg{header~file}
176 In sez.~\ref{sec:intro_standard} abbiamo accennato come le funzioni definite
177 nei vari standard siano definite in una serie di \textit{header file} (in
178 italiano \textsl{file di intestazione}). Vengono chiamati in questo modo quei
179 file, forniti insieme al codice delle librerie, che contengono le
180 dichiarazioni delle variabili, dei tipi di dati, delle macro di preprocessore
181 e soprattutto delle funzioni che fanno parte di una libreria.
183 Questi file sono necessari al compilatore del linguaggio C per ottenere i
184 riferimenti ai nomi delle funzioni (e alle altre risorse) definite in una
185 libreria, per questo quando si vogliono usare le funzioni di una libreria
186 occorre includere nel proprio codice gli \textit{header file} che le
187 definiscono con la direttiva \code{\#include}. Dato che le funzioni devono
188 essere definite prima di poterle usare in genere gli \textit{header file}
189 vengono inclusi all'inizio del programma. Se inoltre si vogliono utilizzare le
190 macro di controllo delle funzionalità fornite dai vari standard illustrate in
191 sez.~\ref{sec:intro_gcc_glibc_std} queste, come accennato, dovranno a loro
192 volta essere definite prima delle varie inclusioni.
194 Ogni libreria fornisce i propri file di intestazione per i quali si deve
195 consultare la documentazione, ma in tab.~\ref{tab:intro_posix_header} si sono
196 riportati i principali \textit{header file} definiti nella libreria standard
197 del C (nel caso la \acr{glibc}) che contengono le varie funzioni previste
198 negli standard POSIX ed ANSI C, e che prevedono la definizione sia delle
199 funzioni di utilità generica che delle interfacce alle \textit{system call}. In
200 seguito per ciascuna funzione o \textit{system call} che tratteremo
201 indicheremo anche quali sono gli \textit{header file} contenenti le necessarie
207 \begin{tabular}[c]{|l|c|c|l|}
209 \multirow{2}{*}{\textbf{Header}}&
210 \multicolumn{2}{|c|}{\textbf{Standard}}&
211 \multirow{2}{*}{\textbf{Contenuto}} \\
216 \headfile{assert.h}&$\bullet$& -- & Verifica le asserzioni fatte in un
218 \headfile{ctype.h} &$\bullet$& -- & Tipi standard.\\
219 \headfile{dirent.h}& -- &$\bullet$& Manipolazione delle directory.\\
220 \headfile{errno.h} & -- &$\bullet$& Errori di sistema.\\
221 \headfile{fcntl.h} & -- &$\bullet$& Controllo sulle opzioni dei file.\\
222 \headfile{limits.h}& -- &$\bullet$& Limiti e parametri del sistema.\\
223 \headfile{malloc.h}&$\bullet$& -- & Allocazione della memoria.\\
224 \headfile{setjmp.h}&$\bullet$& -- & Salti non locali.\\
225 \headfile{signal.h}& -- &$\bullet$& Gestione dei segnali.\\
226 \headfile{stdarg.h}&$\bullet$& -- & Gestione di funzioni a argomenti
228 \headfile{stdio.h} &$\bullet$& -- & I/O bufferizzato in standard ANSI
230 \headfile{stdlib.h}&$\bullet$& -- & Definizioni della libreria
232 \headfile{string.h}&$\bullet$& -- & Manipolazione delle stringhe.\\
233 \headfile{time.h} & -- &$\bullet$& Gestione dei tempi.\\
234 \headfile{times.h} &$\bullet$& -- & Gestione dei tempi.\\
235 \headfile{unistd.h}& -- &$\bullet$& Unix standard library.\\
236 \headfile{utmp.h} & -- &$\bullet$& Registro connessioni utenti.\\
239 \caption{Elenco dei principali \textit{header file} definiti dagli standard
241 \label{tab:intro_posix_header}
244 Un esempio di inclusione di questi file, preso da uno dei programmi di
245 esempio, è il seguente, e si noti come gli \textit{header file} possano essere
246 referenziati con il nome fra parentesi angolari, nel qual caso si indica l'uso
247 di quelli installati con il sistema,\footnote{in un sistema GNU/Linux che
248 segue le specifiche del \itindex{Filesystem~Hierarchy~Standard~(FHS)}
249 \textit{Filesystem Hierarchy Standard} (per maggiori informazioni si
250 consulti sez.~1.2.3 di \cite{AGL}) si trovano sotto \texttt{/usr/include}.}
251 o fra virgolette, nel qual caso si fa riferimento ad una versione locale, da
252 indicare con un \itindsub{pathname}{relativo} \textit{pathname} relativo:
253 \includecodesnip{listati/main_include.c}
255 Si tenga presente che oltre ai nomi riservati a livello generale di cui si è
256 parlato in sez.~\ref{sec:proc_main}, alcuni di questi \textit{header file}
257 riservano degli ulteriori identificativi, il cui uso sarà da evitare, ad
260 \item in \headfile{dirent.h} vengono riservati i nomi che iniziano con
261 ``\texttt{d\_}'' e costituiti da lettere minuscole,
262 \item in \headfile{fcntl.h} vengono riservati i nomi che iniziano con
263 ``\texttt{l\_}'', ``\texttt{F\_}'',``\texttt{O\_}'' e ``\texttt{S\_}'',
264 \item in \headfile{limits.h} vengono riservati i nomi che finiscono in
266 \item in \headfile{signal.h} vengono riservati i nomi che iniziano con
267 ``\texttt{sa\_}'' e ``\texttt{SA\_}'',
268 \item in \headfile{sys/stat.h} vengono riservati i nomi che iniziano con
269 ``\texttt{st\_}'' e ``\texttt{S\_}'',
270 \item in \headfile{sys/times.h} vengono riservati i nomi che iniziano con
272 \item in \headfile{termios.h} vengono riservati i nomi che iniziano con
273 ``\texttt{c\_}'', ``\texttt{V}'', ``\texttt{I}'', ``\texttt{O}'' e
274 ``\texttt{TC}'' e con ``\texttt{B}'' seguito da un numero,
275 \item in \headfile{grp.h} vengono riservati i nomi che iniziano con
277 \item in \headfile{pwd.h}vengono riservati i nomi che iniziano con
281 \itindend{header~file}
283 Una volta inclusi gli \textit{header file} necessari un programma potrà
284 richiamare le funzioni di libreria direttamente nel proprio codice ed accedere
285 ai servizi del kernel; come accennato infatti normalmente ogni \textit{system
286 call} è associata ad una omonima funzione di libreria, che è quella che si
287 usa normalmente per invocarla.
289 Occorre però tenere presente che anche se dal punto di vista della scrittura
290 del codice la chiamata di una \textit{system call} non è diversa da quella di
291 una qualunque funzione ordinaria, la situazione è totalmente diversa
292 nell'esecuzione del programma. Una funzione ordinaria infatti viene eseguita,
293 esattamente come il codice che si è scritto nel corpo del programma, in
294 \textit{user space}. Quando invece si esegue una \textit{system call}
295 l'esecuzione ordinaria del programma viene interrotta, i dati forniti (come
296 argomenti della chiamata) vengono trasferiti al kernel che esegue il codice
297 della \textit{system call} (che è codice del kernel) in \textit{kernel space}.
299 Dato che il passaggio dei dati ed il salvataggio del contesto di esecuzione
300 del programma che consentirà di riprenderne l'esecuzione ordinaria al
301 completamento della \textit{system call} sono operazioni critiche per le
302 prestazioni del sistema, per rendere il più veloce possibile questa
303 operazione, usualmente chiamata \textit{context switch} sono state sviluppate
304 una serie di ottimizzazioni che richiedono alcune preparazioni abbastanza
305 complesse dei dati, che in genere dipendono dall'architettura del processore
306 sono scritte direttamente in \textit{assembler}.
309 % TODO:trattare qui, quando sarà il momento vsyscall e vDSO, vedi:
310 % http://davisdoesdownunder.blogspot.com/2011/02/linux-syscall-vsyscall-and-vdso-oh-my.html
311 % http://www.win.tue.nl/~aeb/linux/lk/lk-4.html
314 Inoltre alcune \textit{system call} sono state modificate nel corso degli anni
315 con lo sviluppo del kernel per aggiungere ad esempio funzionalità in forma di
316 nuovi argomenti, o per consolidare diverse varianti in una interfaccia
317 generica. Per questo motivo dovendo utilizzare una \textit{system call} è
318 sempre preferibile usare l'interfaccia fornita dalla \textsl{glibc}, che si
319 cura di mantenere una uniformità chiamando le versioni più aggiornate.
321 Ci sono alcuni casi però in cui può essere necessario evitare questa
322 associazione, e lavorare a basso livello con una specifica versione, oppure si
323 può voler utilizzare una \textit{system call} che non è stata ancora associata
324 ad una funzione di libreria. In tal caso, per evitare di dover effettuare
325 esplicitamente le operazioni di preparazione citate, all'interno della
326 \textsl{glibc} è fornita una specifica funzione, \funcd{syscall}, che consente
327 eseguire direttamente una \textit{system call}; il suo prototipo, accessibile
328 se si è definita la macro \macro{\_GNU\_SOURCE}, è:
332 \fhead{sys/syscall.h}
333 \fdecl{int syscall(int number, ...)}
334 \fdesc{Esegue la \textit{system call} indicata da \param{number}.}
336 {La funzione ritorna un intero dipendente dalla \textit{system call} invocata,
337 in generale $0$ indica il successo ed un valore negativo un errore.}
340 La funzione richiede come primo argomento il numero della \textit{system call}
341 da invocare, seguita dagli argomenti da passare alla stessa, che ovviamente
342 dipendono da quest'ultima, e restituisce il codice di ritorno della
343 \textit{system call} invocata. In generale un valore nullo indica il successo
344 ed un valore negativo è un codice di errore che poi viene memorizzato nella
345 variabile \var{errno} (sulla gestione degli errori torneremo in dettaglio in
346 sez.~\ref{sec:sys_errors}).
348 Il valore di \param{number} dipende sia dalla versione di kernel che
349 dall'architettura,\footnote{in genere le vecchie \textit{system call} non
350 vengono eliminate e se ne aggiungono di nuove con nuovi numeri.} ma
351 ciascuna \textit{system call} viene in genere identificata da una costante
352 nella forma \texttt{SYS\_*} dove al prefisso viene aggiunto il nome che spesso
353 corrisponde anche alla omonima funzione di libreria. Queste costanti sono
354 definite nel file \headfile{sys/syscall.h}, ma si possono anche usare
355 direttamente valori numerici.
358 \subsection{La terminazione di un programma}
359 \label{sec:proc_conclusion}
361 Normalmente un programma conclude la sua esecuzione quando si fa ritornare la
362 funzione \code{main}, si usa cioè l'istruzione \instruction{return} del
363 linguaggio C all'interno della stessa, o se si richiede esplicitamente la
364 chiusura invocando direttamente la funzione \func{exit}. Queste due modalità
365 sono assolutamente equivalenti, dato che \func{exit} viene chiamata in maniera
366 trasparente anche quando \code{main} ritorna, passandogli come argomento il
367 valore di ritorno (che essendo .
369 La funzione \funcd{exit}, che è completamente generale, essendo definita dallo
370 standard ANSI C, è quella che deve essere invocata per una terminazione
371 ``\textit{normale}'', il suo prototipo è:
375 \fdecl{void exit(int status)}
376 \fdesc{Causa la conclusione ordinaria del programma.}
378 {La funzione non ritorna, il processo viene terminato.}
381 La funzione è pensata per eseguire una conclusione pulita di un programma che
382 usi la libreria standard del C; essa esegue tutte le funzioni che sono state
383 registrate con \func{atexit} e \func{on\_exit} (vedi
384 sez.~\ref{sec:proc_atexit}), chiude tutti gli \textit{stream} (vedi
385 sez.~\ref{sec:file_stream}) effettuando il salvataggio dei dati sospesi
386 (chiamando \func{fclose}, vedi sez.~\ref{sec:file_fopen}), infine passa il
387 controllo al kernel chiamando la \textit{system call} \func{\_exit} (che
388 vedremo a breve) che completa la terminazione del processo.
390 \itindbeg{exit~status}
392 Il valore dell'argomento \param{status} o il valore di ritorno di \code{main},
393 costituisce quello che viene chiamato lo \textsl{stato di uscita}
394 (l'\textit{exit status}) del processo. In generale si usa questo valore per
395 fornire al processo padre (come vedremo in sez.~\ref{sec:proc_wait}) delle
396 informazioni generiche sulla riuscita o il fallimento del programma appena
399 Anche se l'argomento \param{status} (ed il valore di ritorno di \code{main})
400 sono numeri interi di tipo \ctyp{int}, si deve tener presente che il valore
401 dello stato di uscita viene comunque troncato ad 8 bit,
402 per cui deve essere sempre compreso fra 0 e 255. Si tenga presente che se si
403 raggiunge la fine della funzione \code{main} senza ritornare esplicitamente si
404 ha un valore di uscita indefinito, è pertanto consigliabile di concludere
405 sempre in maniera esplicita detta funzione.
407 Non esiste un valore significato intrinseco della stato di uscita, ma una
408 convenzione in uso pressoché universale è quella di restituire 0 in caso di
409 successo e 1 in caso di fallimento. Una eccezione a questa convenzione è per i
410 programmi che effettuano dei confronti (come \cmd{diff}), che usano 0 per
411 indicare la corrispondenza, 1 per indicare la non corrispondenza e 2 per
412 indicare l'incapacità di effettuare il confronto. Un'altra convenzione riserva
413 i valori da 128 a 256 per usi speciali: ad esempio 128 viene usato per
414 indicare l'incapacità di eseguire un altro programma in un
415 sottoprocesso. Benché le convenzioni citate non siano seguite universalmente è
416 una buona idea tenerle presenti ed adottarle a seconda dei casi.
418 Si tenga presente inoltre che non è una buona idea usare eventuali codici di
419 errore restituiti nella variabile \var{errno} (vedi sez.~\ref{sec:sys_errors})
420 come \textit{exit status}. In generale infatti non ci si cura del valore dello
421 stato di uscita di un processo se non per vedere se è diverso da zero, come
422 indicazione di un qualche errore. Dato che viene troncato ad 8 bit utilizzare
423 un intero di valore generico può comportare il rischio, qualora si vada ad
424 usare un multiplo di 256, di avere uno stato di uscita uguale a zero, che
425 verrebbe interpretato come un successo.
427 Per questo motivo in \headfile{stdlib.h} sono definite, seguendo lo standard
428 POSIX, le due costanti \const{EXIT\_SUCCESS} e \const{EXIT\_FAILURE}, da usare
429 sempre per specificare lo stato di uscita di un processo. Su Linux, ed in
430 generale in qualunque sistema POSIX, ad esse sono assegnati rispettivamente i
433 \itindend{exit~status}
435 Una forma alternativa per effettuare una terminazione esplicita di un
436 programma è quella di chiamare direttamente la \textit{system call}
437 \funcd{\_exit},\footnote{la stessa è definita anche come \funcd{\_Exit} in
438 \headfile{stdlib.h}.} che restituisce il controllo direttamente al kernel,
439 concludendo immediatamente il processo, il suo prototipo è:
441 \begin{funcproto}{ \fhead{unistd.h} \fdecl{void \_exit(int status)}
442 \fdesc{Causa la conclusione immediata del programma.} } {La funzione non
443 ritorna, il processo viene terminato.}
446 La funzione termina immediatamente il processo e le eventuali funzioni
447 registrate con \func{atexit} e \func{on\_exit} non vengono eseguite. La
448 funzione chiude tutti i file descriptor appartenenti al processo, cosa che
449 però non comporta il salvataggio dei dati eventualmente presenti nei buffer
450 degli \textit{stream}, (torneremo sulle due interfacce dei file in
451 sez.~\ref{sec:file_unix_interface} e
452 sez.~\ref{sec:files_std_interface}). Infine fa sì che ogni figlio del processo
453 sia adottato da \cmd{init} (vedi sez.~\ref{sec:proc_termination}), manda un
454 segnale \signal{SIGCHLD} al processo padre (vedi
455 sez.~\ref{sec:sig_job_control}) e ritorna lo stato di uscita specificato
456 in \param{status} che può essere raccolto usando la funzione \func{wait} (vedi
457 sez.~\ref{sec:proc_wait}).
459 Si tenga presente infine che oltre alla conclusione ``\textsl{normale}''
460 appena illustrata esiste anche la possibilità di una conclusione
461 ``\textsl{anomala}'' del programma a causa della ricezione di un segnale
462 (tratteremo i segnali in cap.~\ref{cha:signals}) o della chiamata alla
463 funzione \func{abort}; torneremo su questo in sez.~\ref{sec:proc_termination}.
466 \subsection{Esecuzione di funzioni preliminari all'uscita}
467 \label{sec:proc_atexit}
469 Un'esigenza comune che si incontra è quella di dover effettuare una serie di
470 operazioni di pulizia (ad esempio salvare dei dati, ripristinare delle
471 impostazioni, eliminare dei file temporanei, ecc.) prima della conclusione di
472 un programma. In genere queste operazioni vengono fatte in un'apposita sezione
473 del programma, ma quando si realizza una libreria diventa antipatico dover
474 richiedere una chiamata esplicita ad una funzione di pulizia al programmatore
477 È invece molto meno soggetto ad errori, e completamente trasparente
478 all'utente, avere la possibilità di fare effettuare automaticamente la
479 chiamata ad una funzione che effettui tali operazioni all'uscita dal
480 programma. A questo scopo lo standard ANSI C prevede la possibilità di
481 registrare un certo numero di funzioni che verranno eseguite all'uscita dal
482 programma,\footnote{nel caso di \func{atexit} lo standard POSIX.1-2001
483 richiede che siano registrabili almeno \const{ATEXIT\_MAX} funzioni (il
484 valore può essere ottenuto con \func{sysconf}, vedi
485 sez.~\ref{sec:sys_limits}).} sia per la chiamata ad \func{exit} che per il
486 ritorno di \code{main}. La prima funzione che si può utilizzare a tal fine è
487 \funcd{atexit}, il cui prototipo è:
491 \fdecl{int atexit(void (*function)(void))}
492 \fdesc{Registra la funzione \param{function} per la chiamata all'uscita
495 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, \var{errno}
496 non viene modificata.}
499 La funzione richiede come argomento \param{function} l'indirizzo di una
500 opportuna funzione di pulizia da chiamare all'uscita del programma, che non
501 deve prendere argomenti e non deve ritornare niente. In sostanza deve la
502 funzione di pulizia dovrà essere definita come \code{void function(void)}.
504 Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che le
505 \acr{glibc} includono per compatibilità con SunOS ma che non è detto sia
506 definita su altri sistemi,\footnote{non essendo prevista dallo standard POSIX
507 è in genere preferibile evitarne l'uso.} il suo prototipo è:
511 \fdecl{int on\_exit(void (*function)(int, void *), void *arg))}
512 \fdesc{Registra la funzione \param{function} per la chiamata all'uscita dal
515 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, \var{errno}
516 non viene modificata.}
519 In questo caso la funzione da chiamare all'uscita prende i due argomenti
520 specificati nel prototipo, un intero ed un puntatore; dovrà cioè essere
521 definita come \code{void function(int status, void *argp)}. Il primo argomento
522 sarà inizializzato allo stato di uscita con cui è stata chiamata \func{exit}
523 ed il secondo al puntatore \param{arg} passato come secondo argomento di
524 \func{on\_exit}. Così diventa possibile passare dei dati alla funzione di
527 Nella sequenza di chiusura tutte le funzioni registrate verranno chiamate in
528 ordine inverso rispetto a quello di registrazione, ed una stessa funzione
529 registrata più volte sarà chiamata più volte. Siccome entrambe le funzioni
530 \func{atexit} e \func{on\_exit} fanno riferimento alla stessa lista, l'ordine
531 di esecuzione sarà riferito alla registrazione in quanto tale,
532 indipendentemente dalla funzione usata per farla.
534 Una volta completata l'esecuzione di tutte le funzioni registrate verranno
535 chiusi tutti gli \textit{stream} aperti ed infine verrà chiamata \func{\_exit}
536 per la terminazione del programma. Questa è la sequenza ordinaria, eseguita a
537 meno che una delle funzioni registrate non esegua al suo interno
538 \func{\_exit}, nel qual caso la terminazione del programma sarà immediata ed
539 anche le successive funzioni registrate non saranno invocate.
541 Se invece all'interno di una delle funzioni registrate si chiama un'altra
542 volta \func{exit} lo standard POSIX.1-2001 prescrive un comportamento
543 indefinito, con la possibilità (che su Linux comunque non c'è) di una
544 ripetizione infinita. Pertanto questa eventualità è da evitare nel modo più
545 assoluto. Una altro comportamento indefinito si può avere se si termina
546 l'esecuzione di una delle funzioni registrate con \func{longjmp} (vedi
547 sez.~\ref{sec:proc_longjmp}).
549 Si tenga presente infine che in caso di terminazione anomala di un processo
550 (ad esempio a causa di un segnale) nessuna delle funzioni registrate verrà
551 eseguita e che se invece si crea un nuovo processo con \func{fork} (vedi
552 sez.~\ref{sec:proc_fork}) questo manterrà tutte le funzioni già registrate.
555 \subsection{Un riepilogo}
556 \label{sec:proc_term_conclusion}
558 Data l'importanza dell'argomento è opportuno un piccolo riepilogo dei fatti
559 essenziali relativi alla esecuzione di un programma. Il primo punto da
560 sottolineare è che in un sistema unix-like l'unico modo in cui un programma
561 può essere eseguito dal kernel è attraverso la chiamata alla \textit{system
562 call} \func{execve}, sia direttamente che attraverso una delle funzioni
563 della famiglia \func{exec} che ne semplificano l'uso (vedi
564 sez.~\ref{sec:proc_exec}).
566 Allo stesso modo l'unico modo in cui un programma può concludere
567 volontariamente la propria esecuzione è attraverso una chiamata alla
568 \textit{system call} \func{\_exit}, sia che questa venga fatta esplicitamente,
569 o in maniera indiretta attraverso l'uso di \func{exit} o il ritorno di
572 Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
573 normalmente un programma è riportato in fig.~\ref{fig:proc_prog_start_stop}.
577 % \includegraphics[width=9cm]{img/proc_beginend}
578 \begin{tikzpicture}[>=stealth]
579 \filldraw[fill=black!35] (-0.3,0) rectangle (12,1);
580 \draw(5.5,0.5) node {\large{\textsf{kernel}}};
582 \filldraw[fill=black!15] (1.5,2) rectangle (4,3);
583 \draw (2.75,2.5) node {\texttt{ld-linux.so}};
584 \draw [->] (2.75,1) -- (2.75,2);
585 \draw (2.75,1.5) node [anchor=west]{\texttt{execve}};
587 \filldraw[fill=black!15,rounded corners] (1.5,4) rectangle (4,5);
588 \draw (2.75,4.5) node {\texttt{main}};
590 \draw [<->, dashed] (2.75,3) -- (2.75,4);
591 \draw [->] (1.5,4.5) -- (0.3,4.5) -- (0.3,1);
592 \draw (0.9,4.5) node [anchor=south] {\texttt{\_exit}};
594 \filldraw[fill=black!15,rounded corners] (1.5,6) rectangle (4,7);
595 \draw (2.75,6.5) node {\texttt{funzione}};
597 \draw [<->, dashed] (2.75,5) -- (2.75,6);
598 \draw [->] (1.5,6.5) -- (0.05,6.5) -- (0.05,1);
599 \draw (0.9,6.5) node [anchor=south] {\texttt{\_exit}};
601 \draw (6.75,4.5) node (exit) [rectangle,fill=black!15,minimum width=2.5cm,minimum height=1cm,rounded corners, draw]{\texttt{exit}};
603 \draw[->] (4,6.5) -- node[anchor=south west]{\texttt{exit}} (exit);
604 \draw[->] (4,4.5) -- node[anchor=south]{\texttt{exit}} (exit);
605 \draw[->] (exit) -- node[anchor=east]{\texttt{\_exit}}(6.75,1);
607 \draw (10,4.5) node (exithandler1) [rectangle,fill=black!15,rounded corners, draw]{\textsf{exit handler}};
608 \draw (10,5.5) node (exithandler2) [rectangle,fill=black!15,rounded corners, draw]{\textsf{exit handler}};
609 \draw (10,3.5) node (stream) [rectangle,fill=black!15,rounded corners, draw]{\textsf{chiusura stream}};
611 \draw[<->, dashed] (exithandler1) -- (exit);
612 \draw[<->, dashed] (exithandler2) -- (exit);
613 \draw[<->, dashed] (stream) -- (exit);
615 \caption{Schema dell'avvio e della conclusione di un programma.}
616 \label{fig:proc_prog_start_stop}
619 Si ricordi infine che un programma può anche essere interrotto dall'esterno
620 attraverso l'uso di un segnale (modalità di conclusione non mostrata in
621 fig.~\ref{fig:proc_prog_start_stop}); tratteremo nei dettagli i segnali e la
622 loro gestione nel capitolo \ref{cha:signals}.
626 \section{I processi e l'uso della memoria}
627 \label{sec:proc_memory}
629 Una delle risorse più importanti che ciascun processo ha a disposizione è la
630 memoria, e la gestione della memoria è appunto uno degli aspetti più complessi
631 di un sistema unix-like. In questa sezione, dopo una breve introduzione ai
632 concetti di base, esamineremo come la memoria viene vista da parte di un
633 programma in esecuzione, e le varie funzioni utilizzabili per la sua gestione.
636 \subsection{I concetti generali}
637 \label{sec:proc_mem_gen}
639 Ci sono vari modi in cui i sistemi operativi organizzano la memoria, ed i
640 dettagli di basso livello dipendono spesso in maniera diretta
641 dall'architettura dell'hardware, ma quello più tipico, usato dai sistemi
642 unix-like come Linux è la cosiddetta \index{memoria~virtuale} \textsl{memoria
643 virtuale} che consiste nell'assegnare ad ogni processo uno spazio virtuale
644 di indirizzamento lineare, in cui gli indirizzi vanno da zero ad un qualche
645 valore massimo.\footnote{nel caso di Linux fino al kernel 2.2 detto massimo
646 era, per macchine a 32bit, di 2Gb. Con il kernel 2.4 ed il supporto per la
647 \textit{high-memory} il limite è stato esteso anche per macchine a 32 bit.}
650 Come accennato nel cap.~\ref{cha:intro_unix} questo spazio di indirizzi è
651 virtuale e non corrisponde all'effettiva posizione dei dati nella RAM del
652 computer. In generale detto spazio non è neppure continuo, cioè non tutti gli
653 indirizzi possibili sono utilizzabili, e quelli usabili non sono
654 necessariamente adiacenti.
656 Per la gestione da parte del kernel la memoria viene divisa in pagine di
657 dimensione fissa. Inizialmente queste pagine erano di 4kb sulle macchine a 32
658 bit e di 8kb sulle alpha. Con le versioni più recenti del kernel è possibile
659 anche utilizzare pagine di dimensioni maggiori (di 4Mb, dette \textit{huge
660 page}), per sistemi con grandi quantitativi di memoria in cui l'uso di
661 pagine troppo piccole comporta una perdita di prestazioni. In alcuni sistemi
662 la costante \const{PAGE\_SIZE}, definita in \headfile{limits.h}, indica la
663 dimensione di una pagina in byte, con Linux questo non avviene e per ottenere
664 questa dimensione si deve ricorrere alla funzione \func{getpagesize} (vedi
665 sez.~\ref{sec:sys_memory_res}).
667 Ciascuna pagina di memoria nello spazio di indirizzi virtuale è associata ad
668 un supporto che può essere una pagina di memoria reale o ad un dispositivo di
669 stoccaggio secondario (come lo spazio disco riservato alla \textit{swap}, o i
670 file che contengono il codice). Per ciascun processo il kernel si cura di
671 mantenere un mappa di queste corrispondenze nella cosiddetta
672 \itindex{page~table} \textit{page table}.\footnote{questa è una
673 semplificazione brutale, il meccanismo è molto più complesso; una buona
674 trattazione di come Linux gestisce la memoria virtuale si trova su
677 Una stessa pagina di memoria reale può fare da supporto a diverse pagine di
678 memoria virtuale appartenenti a processi diversi, come accade in genere per le
679 pagine che contengono il codice delle librerie condivise. Ad esempio il codice
680 della funzione \func{printf} starà su una sola pagina di memoria reale che
681 farà da supporto a tutte le pagine di memoria virtuale di tutti i processi che
682 hanno detta funzione nel loro codice.
684 La corrispondenza fra le pagine della \index{memoria~virtuale} memoria
685 virtuale di un processo e quelle della memoria fisica della macchina viene
686 gestita in maniera trasparente dal kernel.\footnote{in genere con l'ausilio
687 dell'hardware di gestione della memoria (la \textit{Memory Management Unit}
688 del processore), con i kernel della serie 2.6 è comunque diventato possibile
689 utilizzare Linux anche su architetture che non dispongono di una MMU.}
690 Poiché in genere la memoria fisica è solo una piccola frazione della memoria
691 virtuale, è necessario un meccanismo che permetta di trasferire le pagine che
692 servono dal supporto su cui si trovano in memoria, eliminando quelle che non
693 servono. Questo meccanismo è detto \index{paginazione} \textsl{paginazione}
694 (o \textit{paging}), ed è uno dei compiti principali del kernel.
696 Quando un processo cerca di accedere ad una pagina che non è nella memoria
697 reale, avviene quello che viene chiamato un \itindex{page~fault} \textit{page
698 fault}; la gestione della memoria genera un'interruzione e passa il
699 controllo al kernel il quale sospende il processo e si incarica di mettere in
700 RAM la pagina richiesta, effettuando tutte le operazioni necessarie per
701 reperire lo spazio necessario, per poi restituire il controllo al processo.
703 Dal punto di vista di un processo questo meccanismo è completamente
704 trasparente, e tutto avviene come se tutte le pagine fossero sempre
705 disponibili in memoria. L'unica differenza avvertibile è quella dei tempi di
706 esecuzione, che passano dai pochi nanosecondi necessari per l'accesso in RAM
707 se la pagina è direttamente disponibile, a tempi estremamente più lunghi,
708 dovuti all'intervento del kernel, qualora sia necessario reperire pagine
709 riposte nella \textit{swap}.
711 Normalmente questo è il prezzo da pagare per avere un multitasking reale, ed
712 in genere il sistema è molto efficiente in questo lavoro; quando però ci siano
713 esigenze specifiche di prestazioni è possibile usare delle funzioni che
714 permettono di bloccare il meccanismo della \index{paginazione} paginazione e
715 mantenere fisse delle pagine in memoria (vedi sez.~\ref{sec:proc_mem_lock}).
718 \subsection{La struttura della memoria di un processo}
719 \label{sec:proc_mem_layout}
721 Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
722 una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
723 tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
724 commette quando si è manipolato male un puntatore e genera quella che viene
725 chiamata una \itindex{segment~violation} \textit{segment violation}. Se si
726 tenta cioè di leggere o scrivere con un indirizzo per il quale non esiste
727 un'associazione nella memoria virtuale, il kernel risponde al relativo
728 \itindex{page~fault} \textit{page fault} mandando un segnale \signal{SIGSEGV}
729 al processo, che normalmente ne causa la terminazione immediata.
731 È pertanto importante capire come viene strutturata \index{memoria~virtuale}
732 la memoria virtuale di un processo. Essa viene divisa in \textsl{segmenti},
733 cioè un insieme contiguo di indirizzi virtuali ai quali il processo può
734 accedere. Solitamente un programma C viene suddiviso nei seguenti segmenti:
736 \item Il \index{segmento!testo} segmento di testo o \textit{text segment}.
737 Contiene il codice del programma, delle funzioni di librerie da esso
738 utilizzate, e le costanti. Normalmente viene condiviso fra tutti i processi
739 che eseguono lo stesso programma e nel caso delle librerie anche da processi
740 che eseguono altri programmi.
742 Quando l'architettura hardware lo supporta viene marcato in sola lettura per
743 evitare sovrascritture accidentali (o maliziose) che ne modifichino le
744 istruzioni. Viene allocato da \func{execve} all'avvio del programma e resta
745 invariato per tutto il tempo dell'esecuzione.
747 \item Il \index{segmento!dati} segmento dei dati o \textit{data
748 segment}. Contiene tutti i dati del programma, come le
749 \index{variabili!globali} variabili globali, cioè quelle definite al di
750 fuori di tutte le funzioni che compongono il programma, e le
751 \index{variabili!statiche} variabili statiche, cioè quelle dichiarate con
752 l'attributo \direct{static},\footnote{la direttiva \direct{static} indica al
753 compilatore C che una variabile così dichiarata all'interno di una
754 funzione deve essere mantenuta staticamente in memoria (nel
755 \index{segmento!dati} segmento dati appunto); questo significa che la
756 variabile verrà inizializzata una sola volta alla prima invocazione della
757 funzione e che il suo valore sarà mantenuto fra diverse esecuzioni della
758 funzione stessa, la differenza con una \index{variabili!globali} variabile
759 globale è che essa può essere vista solo all'interno della funzione in cui
760 è dichiarata.} e la memoria allocata dinamicamente. Di norma è diviso in
764 \item Il segmento dei dati inizializzati, che contiene le variabili il cui
765 valore è stato assegnato esplicitamente. Ad esempio se si definisce:
766 \includecodesnip{listati/pi.c}
767 questo valore sarà immagazzinato in questo segmento. La memoria di questo
768 segmento viene preallocata all'avvio del programma e inizializzata ai valori
770 \item Il segmento dei dati non inizializzati, che contiene le variabili il
771 cui valore non è stato assegnato esplicitamente. Ad esempio se si
773 \includecodesnip{listati/vect.c}
774 questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
775 allocato all'avvio, e tutte le variabili vengono inizializzate a zero (ed
776 i puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
777 variabili che vanno nel \index{segmento!dati} segmento dati, e non è
778 affatto vero in generale.} Storicamente questa seconda parte del
779 \index{segmento!dati} segmento dati viene chiamata BSS (da \textit{Block
780 Started by Symbol}). La sua dimensione è fissa.
781 \item Lo \itindex{heap} \textit{heap}, detto anche \textit{free
782 store}. Tecnicamente lo si può considerare l'estensione del segmento dei
783 dati non inizializzati, a cui di solito è posto giusto di seguito. Questo
784 è il segmento che viene utilizzato per l'allocazione dinamica della
785 memoria. Lo \textit{heap} può essere ridimensionato allargandolo e
786 restringendolo per allocare e disallocare la memoria dinamica con le
787 apposite funzioni (vedi sez.~\ref{sec:proc_mem_alloc}), ma il suo limite
788 inferiore, quello adiacente al segmento dei dati non inizializzati, ha una
792 \item Il segmento di \itindex{stack} \textit{stack}, che contiene quello che
793 viene chiamato \textit{stack} del programma. Tutte le volte che si effettua
794 una chiamata ad una funzione è qui che viene salvato l'indirizzo di ritorno
795 e le informazioni dello stato del chiamante (come il contenuto di alcuni
796 registri della CPU), poi la funzione chiamata alloca qui lo spazio per le
797 sue variabili locali. Tutti questi dati vengono \textit{impilati} (da questo
798 viene il nome \itindex{stack} \textit{stack}) in sequenza uno sull'altro; in
799 questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
800 della funzione lo spazio è automaticamente rilasciato e
801 ``\textsl{ripulito}''.\footnote{il compilatore si incarica di generare
802 automaticamente il codice necessario, seguendo quella che viene chiamata
803 una \textit{calling convention}; quella standard usata con il C ed il C++
804 è detta \textit{cdecl} e prevede che gli argomenti siano caricati nello
805 \textit{stack} dal chiamante da destra a sinistra, e che sia il chiamante
806 stesso ad eseguire la ripulitura dello \textit{stack} al ritorno della
807 funzione, se ne possono però utilizzare di alternative (ad esempio nel
808 Pascal gli argomenti sono inseriti da sinistra a destra ed è compito del
809 chiamato ripulire lo \textit{stack}), in genere non ci si deve preoccupare
810 di questo fintanto che non si mescolano funzioni scritte con linguaggi
813 La dimensione di questo segmento aumenta seguendo la crescita dello
814 \itindex{stack} \textit{stack} del programma, ma non viene ridotta quando
815 quest'ultimo si restringe.
820 % \includegraphics[height=12cm]{img/memory_layout}
822 \draw (0,0) rectangle (4,1);
823 \draw (2,0.5) node {\textit{text}};
824 \draw (0,1) rectangle (4,2.5);
825 \draw (2,1.75) node {dati inizializzati};
826 \draw (0,2.5) rectangle (4,5);
827 \draw (2,3.75) node {dati non inizializzati};
828 \draw (0,5) rectangle (4,9);
829 \draw[dashed] (0,6) -- (4,6);
830 \draw[dashed] (0,8) -- (4,8);
831 \draw (2,5.5) node {\textit{heap}};
832 \draw (2,8.5) node {\textit{stack}};
833 \draw [->] (2,6) -- (2,6.5);
834 \draw [->] (2,8) -- (2,7.5);
835 \draw (0,9) rectangle (4,10);
836 \draw (2,9.5) node {\textit{environment}};
837 \draw (4,0) node [anchor=west] {\texttt{0x08000000}};
838 \draw (4,5) node [anchor=west] {\texttt{0x08xxxxxx}};
839 \draw (4,9) node [anchor=west] {\texttt{0xC0000000}};
841 \caption{Disposizione tipica dei segmenti di memoria di un processo.}
842 \label{fig:proc_mem_layout}
845 Una disposizione tipica dei vari segmenti (testo, dati inizializzati e non
846 inizializzati, \itindex{heap} \textit{heap}, \itindex{stack} \textit{stack},
847 ecc.) è riportata in fig.~\ref{fig:proc_mem_layout}. Si noti come in figura
848 sia indicata una ulteriore regione, marcata \textit{environment}, che è quella
849 che contiene i dati relativi alle variabili di ambiente passate al programma
850 al suo avvio (torneremo su questo argomento in sez.~\ref{sec:proc_environ}).
852 Usando il comando \cmd{size} su un programma se ne può stampare le dimensioni
853 dei \index{segmento!testo} segmenti di testo e \index{segmento!dati} di dati
854 (solo però per i dati inizializzati ed il BSS, dato che lo \itindex{heap}
855 \textit{heap} ha una dimensione dinamica). Si tenga presente comunque che il
856 BSS, contrariamente al segmento dei dati inizializzati, non è mai salvato sul
857 file che contiene l'eseguibile, dato che viene sempre inizializzato a zero al
858 caricamento del programma.
861 \subsection{Allocazione della memoria per i programmi C}
862 \label{sec:proc_mem_alloc}
864 Il C supporta direttamente, come linguaggio di programmazione, soltanto due
865 modalità di allocazione della memoria: l'\textsl{allocazione statica} e
866 l'\textsl{allocazione automatica}.
868 L'\textsl{allocazione statica} è quella con cui sono memorizzate le
869 \index{variabili!globali} variabili globali e le \index{variabili!statiche}
870 variabili statiche, cioè le variabili il cui valore deve essere mantenuto per
871 tutta la durata del programma. Come accennato queste variabili vengono
872 allocate nel \index{segmento!dati} segmento dei dati all'avvio del programma
873 come parte delle operazioni svolte da \func{exec}, e lo spazio da loro
874 occupato non viene liberato fino alla sua conclusione.
876 L'\textsl{allocazione automatica} è quella che avviene per gli argomenti di
877 una funzione e per le sue variabili locali, quelle che vengono definite
878 all'interno della funzione che esistono solo per la durata della sua esecuzione
879 e che per questo vengono anche dette \index{variabili!automatiche}
880 \textsl{variabili automatiche}. Lo spazio per queste variabili viene allocato
881 nello \itindex{stack} \textit{stack} quando viene eseguita la funzione e
882 liberato quando si esce dalla medesima.
884 Esiste però un terzo tipo di allocazione, l'\textsl{allocazione dinamica}
885 della memoria, che non è prevista direttamente all'interno del linguaggio C,
886 ma che è necessaria quando il quantitativo di memoria che serve è
887 determinabile solo durante il corso dell'esecuzione del programma. Il C non
888 consente di usare variabili allocate dinamicamente, non è possibile cioè
889 definire in fase di programmazione una variabile le cui dimensioni possano
890 essere modificate durante l'esecuzione del programma. Per questo la libreria
891 standard del C fornisce una opportuna serie di funzioni per eseguire
892 l'allocazione dinamica di memoria, che come accennato avviene nello
893 \itindex{heap} \textit{heap}.
895 Le variabili il cui contenuto è allocato in questo modo non potranno essere
896 usate direttamente come le altre (quelle nello \itindex{stack}
897 \textit{stack}), ma l'accesso sarà possibile solo in maniera indiretta,
898 attraverso i puntatori alla memoria loro riservata che si sono ottenuti dalle
899 funzioni di allocazione.
901 Le funzioni previste dallo standard ANSI C per la gestione della memoria sono
902 quattro: \func{malloc}, \func{calloc}, \func{realloc} e \func{free}. Le prime
903 due, \funcd{malloc} e \funcd{calloc} allocano nuovo spazio di memoria; i
904 rispettivi prototipi sono:
908 \fdecl{void *calloc(size\_t nmemb, size\_t size)}
909 \fdesc{Alloca un'area di memoria inizializzata a 0.}
910 \fdecl{void *malloc(size\_t size)}
911 \fdesc{Alloca un'area di memoria non inizializzata.}
913 {Entrambe le funzioni restituiscono il puntatore alla zona di memoria allocata
914 in caso di successo e \val{NULL} in caso di fallimento, nel qual caso
915 \var{errno} assumerà il valore \errcode{ENOMEM}.}
918 In genere si usano \func{malloc} e \func{calloc} per allocare dinamicamente
919 un'area di memoria.\footnote{queste funzioni presentano un comportamento
920 diverso fra le \acr{glibc} e le \acr{uClib} quando il valore di \param{size}
921 è nullo. Nel primo caso viene comunque restituito un puntatore valido,
922 anche se non è chiaro a cosa esso possa fare riferimento, nel secondo caso
923 viene restituito \val{NULL}. Il comportamento è analogo con
924 \code{realloc(NULL, 0)}.} Dato che i puntatori ritornati sono di tipo
925 generico non è necessario effettuare un cast per assegnarli a puntatori al
926 tipo di variabile per la quale si effettua l'allocazione, inoltre le funzioni
927 garantiscono che i puntatori siano allineati correttamente per tutti i tipi di
928 dati; ad esempio sulle macchine a 32 bit in genere sono allineati a multipli
929 di 4 byte e sulle macchine a 64 bit a multipli di 8 byte.
931 Nel caso di \func{calloc} l'area di memoria viene allocata nello \textit{heap}
932 come un vettore di \param{nmemb} membri di \param{size} byte di dimensione, e
933 preventivamente inizializzata a zero, nel caso di \func{malloc} invece vengono
934 semplicemente allocati \param{size} byte e l'area di memoria non viene
937 Una volta che non sia più necessaria la memoria allocata dinamicamente deve
938 essere esplicitamente rilasciata usando la funzione \funcd{free},\footnote{le
939 glibc provvedono anche una funzione \funcm{cfree} definita per compatibilità
940 con SunOS, che è deprecata.} il suo prototipo è:
944 \fdecl{void free(void *ptr)}
945 \fdesc{Disalloca un'area di memoria precedentemente allocata.}
947 {La funzione non ritorna nulla e non riporta errori.}
950 Questa funzione vuole come argomento \var{ptr} il puntatore restituito da una
951 precedente chiamata ad una qualunque delle funzioni di allocazione che non sia
952 già stato liberato da un'altra chiamata a \func{free}. Se il valore
953 di \param{ptr} è \val{NULL} la funzione non fa niente, mentre se l'area di
954 memoria era già stata liberata da un precedente chiamata il comportamento
955 della funzione è dichiarato indefinito, ma in genere comporta la corruzione
956 dei dati di gestione dell'allocazione, che può dar luogo a problemi gravi, ad
957 esempio un \textit{segmentation fault} in una successiva chiamata di una di
960 Dato che questo errore, chiamato in gergo \itindex{double~free} \textit{double
961 free}, è abbastanza frequente, specie quando si manipolano vettori di
962 puntatori, e dato che le conseguenze possono essere pesanti ed inaspettate, si
963 suggerisce come soluzione precauzionale di assegnare sempre a \val{NULL} ogni
964 puntatore su cui sia stata eseguita \func{free} immediatamente dopo
965 l'esecuzione della funzione. In questo modo, dato che con un puntatore nullo
966 \func{free} non esegue nessuna operazione, si evitano i problemi del
967 \itindex{double~free} \textit{double free}.
969 Infine la funzione \funcd{realloc} consente di modificare, in genere di
970 aumentare, la dimensione di un'area di memoria precedentemente allocata; il
975 \fdecl{void *realloc(void *ptr, size\_t size)}
976 \fdesc{Cambia la dimensione di un'area di memoria precedentemente allocata.}
977 } {La funzione ritorna il puntatore alla zona di memoria allocata in caso
978 di successo e \val{NULL} per un errore, nel qual caso \var{errno}
979 assumerà il valore \errcode{ENOMEM}.}
982 La funzione vuole come primo argomento il puntatore restituito da una
983 precedente chiamata a \func{malloc} o \func{calloc} e come secondo argomento
984 la nuova dimensione (in byte) che si intende ottenere. Se si passa
985 per \param{ptr} il valore \val{NULL} allora la funzione si comporta come
986 \func{malloc}.\footnote{questo è vero per Linux e l'implementazione secondo lo
987 standard ANSI C, ma non è vero per alcune vecchie implementazioni, inoltre
988 alcune versioni delle librerie del C consentivano di usare \func{realloc}
989 anche per un puntatore liberato con \func{free} purché non ci fossero state
990 nel frattempo altre chiamate a funzioni di allocazione, questa funzionalità
991 è totalmente deprecata e non è consentita sotto Linux.}
993 La funzione si usa ad esempio quando si deve far crescere la dimensione di un
994 vettore. In questo caso se è disponibile dello spazio adiacente al precedente
995 la funzione lo utilizza, altrimenti rialloca altrove un blocco della
996 dimensione voluta, copiandoci automaticamente il contenuto; lo spazio aggiunto
997 non viene inizializzato. Se la funzione fallisce l'area di memoria originale
998 non viene assolutamente toccata.
1000 Si deve sempre avere ben presente il fatto che il blocco di memoria restituito
1001 da \func{realloc} può non essere un'estensione di quello che gli si è passato
1002 in ingresso; per questo si dovrà \emph{sempre} eseguire la riassegnazione di
1003 \param{ptr} al valore di ritorno della funzione, e reinizializzare o provvedere
1004 ad un adeguato aggiornamento di tutti gli altri puntatori all'interno del
1005 blocco di dati ridimensionato.
1007 La \acr{glibc} ha un'implementazione delle funzioni di allocazione che è
1008 controllabile dall'utente attraverso alcune variabili di ambiente (vedi
1009 sez.~\ref{sec:proc_environ}), in particolare diventa possibile tracciare
1010 questo tipo di errori usando la variabile di ambiente \envvar{MALLOC\_CHECK\_}
1011 che quando viene definita mette in uso una versione meno efficiente delle
1012 funzioni suddette, che però è più tollerante nei confronti di piccoli errori
1013 come quello dei \itindex{double~free} \textit{double~free} o i
1014 \itindex{buffer~overrun} \textit{buffer overrun} di un byte.\footnote{uno
1015 degli errori più comuni, causato ad esempio dalla scrittura di una stringa
1016 di dimensione pari a quella del buffer, in cui ci si dimentica dello zero di
1017 terminazione finale.} In particolare:
1019 \item se la variabile è posta a $0$ gli errori vengono ignorati;
1020 \item se la variabile è posta a $1$ viene stampato un avviso sullo
1021 \textit{standard error} (vedi sez.~\ref{sec:file_fd});
1022 \item se la variabile è posta a $2$ viene chiamata la funzione \func{abort}
1023 (vedi sez.~\ref{sec:sig_alarm_abort}), che in genere causa l'immediata
1024 terminazione del programma;
1025 \item se la variabile è posta a $3$ viene stampato l'avviso e chiamata
1029 L'errore di programmazione più comune e più difficile da risolvere che si
1030 incontra con le funzioni di allocazione è quando non viene opportunamente
1031 liberata la memoria non più utilizzata, quello che in inglese viene chiamato
1032 \itindex{memory~leak} \textit{memory leak}, cioè una \textsl{perdita di
1035 Un caso tipico che illustra il problema è quello in cui in una propria
1036 funzione si alloca della memoria per uso locale senza liberarla prima di
1037 uscire. La memoria resta così allocata fino alla terminazione del processo.
1038 Chiamate ripetute alla stessa funzione continueranno ad effettuare altre
1039 allocazioni, che si accumuleranno causando a lungo andare un esaurimento della
1040 memoria disponibile e la probabile impossibilità di proseguire l'esecuzione
1043 Il problema è che l'esaurimento della memoria può avvenire in qualunque
1044 momento, in corrispondenza ad una qualunque chiamata di \func{malloc} che può
1045 essere in una sezione del codice che non ha alcuna relazione con la funzione
1046 che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
1047 \itindex{memory~leak} \textit{memory leak}.
1049 In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
1050 programmazione ad oggetti, il problema dei \itindex{memory~leak}
1051 \textit{memory leak} si può notevolmente ridimensionare attraverso l'uso
1052 accurato di appositi oggetti come gli \textit{smartpointers}. Questo però in
1053 genere va a scapito delle prestazioni dell'applicazione in esecuzione.
1055 % TODO decidere cosa fare di questo che segue
1056 % In altri linguaggi come il java e recentemente il C\# il problema non si pone
1057 % nemmeno perché la gestione della memoria viene fatta totalmente in maniera
1058 % automatica, ovvero il programmatore non deve minimamente preoccuparsi di
1059 % liberare la memoria allocata precedentemente quando non serve più, poiché
1060 % l'infrastruttura del linguaggio gestisce automaticamente la cosiddetta
1061 % \index{\textit{garbage~collection}} \textit{garbage collection}. In tal caso,
1062 % attraverso meccanismi simili a quelli del \textit{reference counting}, quando
1063 % una zona di memoria precedentemente allocata non è più riferita da nessuna
1064 % parte del codice in esecuzione, può essere deallocata automaticamente in
1065 % qualunque momento dall'infrastruttura.
1067 % Anche questo va a scapito delle prestazioni dell'applicazione in esecuzione
1068 % (inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
1069 % eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
1070 % la presenza di una infrastruttura per la loro interpretazione e pertanto hanno
1071 % di per sé delle prestazioni più scadenti rispetto alle stesse applicazioni
1072 % compilate direttamente). Questo comporta però il problema della non
1073 % predicibilità del momento in cui viene deallocata la memoria precedentemente
1074 % allocata da un oggetto.
1076 Per limitare l'impatto di questi problemi, e semplificare la ricerca di
1077 eventuali errori, l'implementazione delle funzioni di allocazione nella
1078 \acr{glibc} mette a disposizione una serie di funzionalità che permettono di
1079 tracciare le allocazioni e le disallocazioni, e definisce anche una serie di
1080 possibili \textit{hook} (\textsl{ganci}) che permettono di sostituire alle
1081 funzioni di libreria una propria versione (che può essere più o meno
1082 specializzata per il debugging). Esistono varie librerie che forniscono dei
1083 sostituti opportuni delle funzioni di allocazione in grado, senza neanche
1084 ricompilare il programma,\footnote{esempi sono \textit{Dmalloc}
1085 \url{http://dmalloc.com/} di Gray Watson ed \textit{Electric Fence} di Bruce
1086 Perens.} di eseguire diagnostiche anche molto complesse riguardo
1087 l'allocazione della memoria. Vedremo alcune delle funzionalità di ausilio
1088 presenti nella \acr{glibc} in sez.~\ref{sec:proc_memory_adv_management}.
1090 Una possibile alternativa all'uso di \func{malloc}, per evitare di soffrire
1091 dei problemi di \itindex{memory~leak} \textit{memory leak} descritti in
1092 precedenza, è di allocare la memoria nel segmento di \itindex{stack}
1093 \textit{stack} della funzione corrente invece che nello \itindex{heap}
1094 \textit{heap}. Per farlo si può usare la funzione \funcd{alloca}, la cui
1095 sintassi è identica a quella di \func{malloc}; il suo prototipo è:
1099 \fdecl{void *alloca(size\_t size)}
1100 \fdesc{Alloca un'area di memoria nello \textit{stack}.}
1102 {La funzione ritorna il puntatore alla zona di memoria allocata, in caso
1103 di errore il comportamento è indefinito.}
1106 La funzione alloca la quantità di memoria (non inizializzata) richiesta
1107 dall'argomento \param{size} nel segmento di \itindex{stack} \textit{stack}
1108 della funzione chiamante. Con questa funzione non è più necessario liberare
1109 la memoria allocata, e quindi non esiste un analogo della \func{free}, in
1110 quanto essa viene rilasciata automaticamente al ritorno della funzione.
1112 Come è evidente questa funzione ha alcuni vantaggi interessanti, anzitutto
1113 permette di evitare alla radice i problemi di \itindex{memory~leak}
1114 \textit{memory leak}, dato che non serve più la deallocazione esplicita;
1115 inoltre la deallocazione automatica funziona anche quando si usa
1116 \func{longjmp} per uscire da una subroutine con un salto non locale da una
1117 funzione (vedi sez.~\ref{sec:proc_longjmp}). Un altro vantaggio è che in
1118 Linux la funzione è molto più veloce di \func{malloc} e non viene sprecato
1119 spazio, infatti non è necessario gestire un pool di memoria da riservare e si
1120 evitano così anche i problemi di frammentazione di quest'ultimo, che
1121 comportano inefficienze sia nell'allocazione della memoria che nell'esecuzione
1124 Gli svantaggi sono che questa funzione non è disponibile su tutti gli Unix, e
1125 non è inserita né nello standard POSIX né in SUSv3 (ma è presente in BSD), il
1126 suo utilizzo quindi limita la portabilità dei programmi. Inoltre la funzione
1127 non può essere usata nella lista degli argomenti di una funzione, perché lo
1128 spazio verrebbe allocato nel mezzo degli stessi. Inoltre non è chiaramente
1129 possibile usare \func{alloca} per allocare memoria che deve poi essere usata
1130 anche al di fuori della funzione in cui essa viene chiamata, dato che
1131 all'uscita dalla funzione lo spazio allocato diventerebbe libero, e potrebbe
1132 essere sovrascritto all'invocazione di nuove funzioni. Questo è lo stesso
1133 problema che si può avere con le \index{variabili!automatiche} variabili
1134 automatiche, su cui torneremo in sez.~\ref{sec:proc_var_passing}.
1136 Infine non esiste un modo di sapere se l'allocazione ha avuto successo, la
1137 funzione infatti viene realizzata inserendo del codice \textit{inline} nel
1138 programma\footnote{questo comporta anche il fatto che non è possibile
1139 sostituirla con una propria versione o modificarne il comportamento
1140 collegando il proprio programma con un'altra libreria.} che si limita a
1141 modificare il puntatore nello \itindex{stack} \textit{stack} e non c'è modo di
1142 sapere se se ne sono superate le dimensioni, per cui in caso di fallimento
1143 nell'allocazione il comportamento del programma può risultare indefinito,
1144 dando luogo ad una \itindex{segment~violation} \textit{segment violation} la
1145 prima volta che cercherà di accedere alla memoria non effettivamente
1149 \index{segmento!dati|(}
1151 Le due funzioni seguenti\footnote{le due funzioni sono state definite con BSD
1152 4.3, sono marcate obsolete in SUSv2 e non fanno parte delle librerie
1153 standard del C e mentre sono state esplicitamente rimosse dallo standard
1154 POSIX.1-2001.} vengono utilizzate soltanto quando è necessario effettuare
1155 direttamente la gestione della memoria associata allo spazio dati di un
1156 processo, per poterle utilizzare è necessario definire una della macro di
1157 funzionalità (vedi sez.~\ref{sec:intro_gcc_glibc_std}) fra
1158 \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE} (ad un
1159 valore maggiore o uguale di 500). La prima funzione è \funcd{brk}, ed il suo
1164 \fdecl{int brk(void *addr)}
1165 \fdesc{Sposta la fine del segmento dati del processo.}
1167 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
1168 nel qual caso \var{errno} assumerà il valore \errcode{ENOMEM}.}
1171 La funzione è un'interfaccia all'omonima \textit{system call} ed imposta
1172 l'indirizzo finale del segmento dati di un processo (più precisamente dello
1173 \itindex{heap} \textit{heap}) all'indirizzo specificato
1174 da \param{addr}. Quest'ultimo deve essere un valore ragionevole, e la
1175 dimensione totale non deve comunque eccedere un eventuale limite (vedi
1176 sez.~\ref{sec:sys_resource_limit}) imposto sulle dimensioni massime del
1177 segmento dati del processo.
1179 Il valore di ritorno della funzione fa riferimento alla versione fornita dalla
1180 \acr{glibc}, in realtà in Linux la \textit{system call} corrispondente
1181 restituisce come valore di ritorno il nuovo valore della fine del segmento
1182 dati in caso di successo e quello corrente in caso di fallimento, è la
1183 funzione di interfaccia usata dalla \acr{glibc} che fornisce i valori di
1184 ritorno appena descritti; se si usano librerie diverse questo potrebbe non
1187 Una seconda funzione per la manipolazione diretta delle dimensioni del
1188 segmento dati\footnote{in questo caso si tratta soltanto di una funzione di
1189 libreria, anche se basata sulla stessa \textit{system call}.} è
1190 \funcd{sbrk}, ed il suo prototipo è:
1194 \fdecl{void *sbrk(intptr\_t increment)}
1195 \fdesc{Incrementa la dimensione del segmento dati del processo.}
1197 {La funzione ritorna il puntatore all'inizio della nuova zona di memoria
1198 allocata in caso di successo e \val{NULL} per un errore, nel qual
1199 caso \var{errno} assumerà il valore \errcode{ENOMEM}.}
1202 La funzione incrementa la dimensione dello \itindex{heap} \textit{heap} di un
1203 programma del valore indicato dall'argomento \param{increment}, restituendo il
1204 nuovo indirizzo finale dello stesso. L'argomento è definito come di tipo
1205 \type{intptr\_t}, ma a seconda della versione delle librerie e del sistema può
1206 essere indicato con una serie di tipi equivalenti come \type{ptrdiff\_t},
1207 \type{ssize\_t}, \ctyp{int}. Se invocata con un valore nullo la funzione
1208 permette di ottenere l'attuale posizione della fine del segmento dati.
1210 Queste due funzioni sono state deliberatamente escluse dallo standard POSIX.1
1211 dato che per i normali programmi è sempre opportuno usare le funzioni di
1212 allocazione standard descritte in precedenza, a meno di non voler realizzare
1213 per proprio conto un diverso meccanismo di gestione della memoria del segmento
1216 \index{segmento!dati|)}
1219 \subsection{Il controllo della memoria virtuale}
1220 \label{sec:proc_mem_lock}
1222 \index{memoria~virtuale|(}
1224 Come spiegato in sez.~\ref{sec:proc_mem_gen} il kernel gestisce la memoria
1225 virtuale in maniera trasparente ai processi, decidendo quando rimuovere pagine
1226 dalla memoria per metterle nell'area di \textit{swap}, sulla base
1227 dell'utilizzo corrente da parte dei vari processi.
1229 Nell'uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il
1230 meccanismo della \index{paginazione} paginazione riporta in RAM, ed in maniera
1231 trasparente, tutte le pagine che gli occorrono; esistono però esigenze
1232 particolari in cui non si vuole che questo meccanismo si attivi. In generale i
1233 motivi per cui si possono avere di queste necessità sono due:
1235 \item \textsl{La velocità}. Il processo della \index{paginazione} paginazione
1236 è trasparente solo se il programma in esecuzione non è sensibile al tempo
1237 che occorre a riportare la pagina in memoria; per questo motivo processi
1238 critici che hanno esigenze di tempo reale o tolleranze critiche nelle
1239 risposte (ad esempio processi che trattano campionamenti sonori) possono non
1240 essere in grado di sopportare le variazioni della velocità di accesso dovuta
1243 In certi casi poi un programmatore può conoscere meglio dell'algoritmo di
1244 allocazione delle pagine le esigenze specifiche del suo programma e decidere
1245 quali pagine di memoria è opportuno che restino in memoria per un aumento
1246 delle prestazioni. In genere queste sono esigenze particolari e richiedono
1247 anche un aumento delle priorità in esecuzione del processo (vedi
1248 sez.~\ref{sec:proc_real_time}).
1250 \item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro
1251 in memoria queste possono essere portate su disco dal meccanismo della
1252 \index{paginazione} paginazione. Questo rende più lungo il periodo di tempo
1253 in cui detti segreti sono presenti in chiaro e più complessa la loro
1254 cancellazione: un processo infatti può cancellare la memoria su cui scrive
1255 le sue variabili, ma non può toccare lo spazio disco su cui una pagina di
1256 memoria può essere stata salvata. Per questo motivo di solito i programmi
1257 di crittografia richiedono il blocco di alcune pagine di memoria.
1260 Per ottenere informazioni sulle modalità in cui un programma sta usando la
1261 memoria virtuale è disponibile una apposita funzione di sistema,
1262 \funcd{mincore}, che però non è standardizzata da POSIX e pertanto non è
1263 disponibile su tutte le versioni di kernel unix-like;\footnote{nel caso di
1264 Linux devono essere comunque definite le macro \macro{\_BSD\_SOURCE} e
1265 \macro{\_SVID\_SOURCE}.} il suo prototipo è:
1270 \fdecl{int mincore(void *addr, size\_t length, unsigned char *vec)}
1271 \fdesc{Ritorna lo stato delle pagine di memoria occupate da un processo.}
1273 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1274 caso \var{errno} assumerà uno dei valori:
1276 \item[\errcode{EAGAIN}] il kernel è temporaneamente non in grado di fornire
1278 \item[\errcode{EFAULT}] \param{vec} punta ad un indirizzo non valido.
1279 \item[\errcode{EINVAL}] \param{addr} non è un multiplo delle dimensioni di
1281 \item[\errcode{ENOMEM}] o \param{addr}$+$\param{length} eccede la dimensione
1282 della memoria usata dal processo o l'intervallo di indirizzi specificato
1287 La funzione permette di ottenere le informazioni sullo stato della mappatura
1288 della memoria per il processo chiamante, specificando l'intervallo da
1289 esaminare con l'indirizzo iniziale, indicato con l'argomento \param{addr}, e
1290 la lunghezza, indicata con l'argomento \param{length}. L'indirizzo iniziale
1291 deve essere un multiplo delle dimensioni di una pagina, mentre la lunghezza
1292 può essere qualunque, fintanto che si resta nello spazio di indirizzi del
1293 processo,\footnote{in caso contrario si avrà un errore di \errcode{ENOMEM};
1294 fino al kernel 2.6.11 in questo caso veniva invece restituito
1295 \errcode{EINVAL}, in considerazione che il caso più comune in cui si
1296 verifica questo errore è quando si usa per sbaglio un valore negativo
1297 di \param{length}, che nel caso verrebbe interpretato come un intero
1298 positivo di grandi dimensioni.} ma il risultato verrà comunque fornito per
1299 l'intervallo compreso fino al multiplo successivo.
1301 I risultati della funzione vengono forniti nel vettore puntato da \param{vec},
1302 che deve essere allocato preventivamente e deve essere di dimensione
1303 sufficiente a contenere tanti byte quante sono le pagine contenute
1304 nell'intervallo di indirizzi specificato, la dimensione cioè deve essere
1305 almeno pari a \code{(length+PAGE\_SIZE-1)/PAGE\_SIZE}. Al ritorno della
1306 funzione il bit meno significativo di ciascun byte del vettore sarà acceso se
1307 la pagina di memoria corrispondente è al momento residente in memoria, o
1308 cancellato altrimenti. Il comportamento sugli altri bit è indefinito, essendo
1309 questi al momento riservati per usi futuri. Per questo motivo in genere è
1310 comunque opportuno inizializzare a zero il contenuto del vettore, così che le
1311 pagine attualmente residenti in memoria saranno indicata da un valore non
1312 nullo del byte corrispondente.
1314 Dato che lo stato della memoria di un processo può cambiare continuamente, il
1315 risultato di \func{mincore} è assolutamente provvisorio e lo stato delle
1316 pagine potrebbe essere già cambiato al ritorno stesso della funzione, a meno
1317 che, come vedremo ora, non si sia attivato il meccanismo che forza il
1318 mantenimento di una pagina sulla memoria.
1320 \itindbeg{memory~locking}
1322 Il meccanismo che previene la \index{paginazione} paginazione di parte della
1323 memoria virtuale di un processo è chiamato \textit{memory locking} (o
1324 \textsl{blocco della memoria}). Il blocco è sempre associato alle pagine della
1325 memoria virtuale del processo, e non al segmento reale di RAM su cui essa
1326 viene mantenuta. La regola è che se un segmento di RAM fa da supporto ad
1327 almeno una pagina bloccata allora esso viene escluso dal meccanismo della
1328 \index{paginazione} paginazione. I blocchi non si accumulano, se si blocca due
1329 volte la stessa pagina non è necessario sbloccarla due volte, una pagina o è
1332 Il \textit{memory lock} persiste fintanto che il processo che detiene la
1333 memoria bloccata non la sblocca. Chiaramente la terminazione del processo
1334 comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
1335 tutti i suoi \textit{memory lock}. Inoltre i \textit{memory lock} non sono
1336 ereditati dai processi figli, ma siccome Linux usa il \itindex{copy~on~write}
1337 \textit{copy on write} (vedi sez.~\ref{sec:proc_fork}) gli indirizzi virtuali
1338 del figlio sono mantenuti sullo stesso segmento di RAM del padre, e quindi
1339 fintanto che un figlio non scrive su un segmento bloccato, può usufruire del
1340 \textit{memory lock} del padre. Infine i \textit{memory lock} vengono
1341 automaticamente rimossi se si pone in esecuzione un altro programma con
1342 \func{exec} (vedi sez.~\ref{sec:proc_exec}).
1344 Il sistema pone dei limiti all'ammontare di memoria di un processo che può
1345 essere bloccata e al totale di memoria fisica che si può dedicare a questo, lo
1346 standard POSIX.1 richiede che sia definita in \headfile{unistd.h} la macro
1347 \macro{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
1348 \textit{memory locking}.
1350 Siccome la richiesta di un \textit{memory lock} da parte di un processo riduce
1351 la memoria fisica disponibile nel sistema per gli altri processi, questo ha un
1352 evidente impatto su tutti gli altri processi, per cui fino al kernel 2.6.9
1353 solo un processo dotato di privilegi amministrativi (la \itindex{capabilities}
1354 \textit{capability} \const{CAP\_IPC\_LOCK}, vedi
1355 sez.~\ref{sec:proc_capabilities}) aveva la capacità di bloccare una pagina di
1358 A partire dal kernel 2.6.9 anche un processo normale può bloccare la propria
1359 memoria\footnote{la funzionalità è stata introdotta per non essere costretti a
1360 dare privilegi eccessivi a programmi di crittografia, che necessitano di
1361 questa funzionalità, ma che devono essere usati da utenti normali.} ma
1362 mentre un processo privilegiato non ha limiti sulla quantità di memoria che
1363 può bloccare, un processo normale è soggetto al limite della risorsa
1364 \const{RLIMIT\_MEMLOCK} (vedi sez.~\ref{sec:sys_resource_limit}). In generale
1365 poi ogni processo può sbloccare le pagine relative alla propria memoria, se
1366 però diversi processi bloccano la stessa pagina questa resterà bloccata
1367 fintanto che ci sarà almeno un processo che la blocca.
1369 Le funzioni di sistema per bloccare e sbloccare la \index{paginazione}
1370 paginazione di singole sezioni di memoria sono rispettivamente \funcd{mlock} e
1371 \funcd{munlock}; i loro prototipi sono:
1375 \fdecl{int mlock(const void *addr, size\_t len)}
1376 \fdesc{Blocca la paginazione su un intervallo di memoria.}
1378 \fdecl{int munlock(const void *addr, size\_t len)}
1379 \fdesc{Rimuove il blocco della paginazione su un intervallo di memoria.}
1381 {Entrambe le funzioni ritornano $0$ in caso di successo e $-1$ in caso di
1382 errore, nel qual caso \var{errno} assumerà uno dei valori:
1384 \item[\errcode{EINVAL}] \param{len} non è un valore positivo.
1385 \item[\errcode{ENOMEM}] alcuni indirizzi dell’intervallo specificato non
1386 corrispondono allo spazio di indirizzi del processo o si è superato il
1387 limite di \const{RLIMIT\_MEMLOCK} per un processo non privilegiato (solo
1388 per kernel a partire dal 2.6.9).
1389 \item[\errcode{EPERM}] il processo non è privilegiato (per kernel precedenti
1390 il 2.6.9) o si ha un limite nullo per \const{RLIMIT\_MEMLOCK} e
1391 il processo non è privilegiato (per kernel a partire dal 2.6.9).
1395 Le due funzioni permettono rispettivamente di bloccare e sbloccare la
1396 \index{paginazione} paginazione per l'intervallo di memoria iniziante
1397 all'indirizzo \param{addr} e lungo \param{len} byte. Tutte le pagine che
1398 contengono una parte dell'intervallo bloccato sono mantenute in RAM per tutta
1399 la durata del blocco. Con kernel diversi da Linux si può ottenere un errore di
1400 \errcode{EINVAL} se \param{addr} non è un multiplo della dimensione delle
1401 pagine di memoria, pertanto se si ha a cuore la portabilità si deve avere cura
1402 di allinearne correttamente il valore.
1404 Altre due funzioni di sistema, \funcd{mlockall} e \funcd{munlockall},
1405 consentono di bloccare genericamente la \index{paginazione} paginazione per
1406 l'intero spazio di indirizzi di un processo. I prototipi di queste funzioni
1411 \fdecl{int mlockall(int flags)}
1412 \fdesc{Blocca la paginazione per lo spazio di indirizzi del processo corrente.}
1413 \fdecl{int munlockall(void)}
1414 \fdesc{Sblocca la paginazione per lo spazio di indirizzi del processo corrente.}
1416 {Codici di ritorno ed errori sono gli stessi di \func{mlock} e \func{munlock},
1417 tranne per \errcode{EINVAL} che viene restituito solo se si è specificato
1418 con \func{mlockall} un valore sconosciuto per \param{flags}.}
1421 L'argomento \param{flags} di \func{mlockall} permette di controllarne il
1422 comportamento; esso deve essere specificato come maschera binaria dei valori
1423 espressi dalle costanti riportate in tab.~\ref{tab:mlockall_flags}.
1428 \begin{tabular}[c]{|l|p{8cm}|}
1430 \textbf{Valore} & \textbf{Significato} \\
1433 \const{MCL\_CURRENT}& blocca tutte le pagine correntemente mappate nello
1434 spazio di indirizzi del processo.\\
1435 \const{MCL\_FUTURE} & blocca tutte le pagine che verranno mappate nello
1436 spazio di indirizzi del processo.\\
1439 \caption{Valori e significato dell'argomento \param{flags} della funzione
1441 \label{tab:mlockall_flags}
1444 Con \func{mlockall} si possono bloccare tutte le pagine mappate nello spazio
1445 di indirizzi del processo, sia che comprendano il \index{segmento!dati}
1446 \index{segmento!testo} segmento di testo, di dati, lo \itindex{stack}
1447 \textit{stack}, lo \itindex{heap} \textit{heap} e pure le funzioni di libreria
1448 chiamate, i file mappati in memoria, i dati del kernel mappati in user space,
1449 la memoria condivisa. L'uso dell'argomento \param{flags} permette di
1450 selezionare con maggior finezza le pagine da bloccare, ad esempio usando
1451 \const{MCL\_FUTURE} ci si può limitare a tutte le pagine allocate a partire
1452 dalla chiamata della funzione.
1454 In ogni caso un processo real-time che deve entrare in una
1455 \index{sezione~critica} sezione critica deve provvedere a riservare memoria
1456 sufficiente prima dell'ingresso, per scongiurare l'occorrenza di un eventuale
1457 \itindex{page~fault} \textit{page fault} causato dal meccanismo di
1458 \itindex{copy~on~write} \textit{copy on write}. Infatti se nella
1459 \index{sezione~critica} sezione critica si va ad utilizzare memoria che non è
1460 ancora stata riportata in RAM si potrebbe avere un \itindex{page~fault}
1461 \textit{page fault} durante l'esecuzione della stessa, con conseguente
1462 rallentamento (probabilmente inaccettabile) dei tempi di esecuzione.
1464 In genere si ovvia a questa problematica chiamando una funzione che ha
1465 allocato una quantità sufficientemente ampia di \index{variabili!automatiche}
1466 variabili automatiche, in modo che esse vengano mappate in RAM dallo
1467 \itindex{stack} \textit{stack}, dopo di che, per essere sicuri che esse siano
1468 state effettivamente portate in memoria, ci si scrive sopra.
1470 \itindend{memory~locking}
1472 \index{memoria~virtuale|)}
1475 \subsection{Gestione avanzata dell'allocazione della memoria}
1476 \label{sec:proc_memory_adv_management}
1478 La trattazione delle funzioni di allocazione di sez.~\ref{sec:proc_mem_alloc}
1479 si è limitata a coprire le esigenze generiche di un programma, in cui non si
1480 hanno dei requisiti specifici e si lascia il controllo delle modalità di
1481 allocazione alle funzioni di libreria. Tuttavia esistono una serie di casi in
1482 cui può essere necessario avere un controllo più dettagliato delle modalità
1483 con cui la memoria viene allocata; nel qual caso potranno venire in aiuto le
1484 funzioni trattate in questa sezione.
1486 Le prime funzioni che tratteremo sono quelle che consentono di richiedere di
1487 allocare un blocco di memoria ``\textsl{allineato}'' ad un multiplo una certa
1488 dimensione. Questo tipo di esigenza emerge usualmente quando si devono
1489 allocare dei buffer da utilizzare per eseguire dell'I/O diretto su dispositivi
1490 a blocchi. In questo caso infatti il trasferimento di dati viene eseguito per
1491 blocchi di dimensione fissa, ed è richiesto che l'indirizzo di partenza del
1492 buffer sia un multiplo intero di questa dimensione, usualmente 512 byte. In
1493 tal caso l'uso di \func{malloc} non è sufficiente, ed occorre utilizzare una
1496 Tradizionalmente per rispondere a questa esigenza sono state create due
1497 funzioni diverse, \funcd{memalign} e \funcd{valloc}, oggi obsolete; i
1498 rispettivi prototipi sono:
1502 \fdecl{void *valloc(size\_t size)}
1503 \fdesc{Alloca un blocco di memoria allineato alla dimensione di una pagina di
1505 \fdecl{void *memalign(size\_t boundary, size\_t size)}
1506 \fdesc{Alloca un blocco di memoria allineato ad un multiplo
1507 di \param{boundary}.}
1509 {Entrambe le funzioni ritornano un puntatore al blocco di memoria allocato in
1510 caso di successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
1511 assumerà uno dei valori:
1513 \item[\errcode{EINVAL}] \param{boundary} non è una potenza di due.
1514 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione.
1518 Le funzioni restituiscono il puntatore al buffer di memoria allocata di
1519 dimensioni pari a \param{size}, che per \func{memalign} sarà un multiplo
1520 di \param{boundary} mentre per \func{valloc} un multiplo della dimensione di
1521 una pagina di memoria. Nel caso della versione fornita dalla \acr{glibc} la
1522 memoria allocata con queste funzioni deve essere liberata con \func{free},
1523 cosa che non è detto accada con altre implementazioni.
1525 Nessuna delle due funzioni ha una chiara standardizzazione e nessuna delle due
1526 compare in POSIX.1, inoltre ci sono indicazioni discordi sui file che ne
1527 contengono la definizione;\footnote{secondo SUSv2 \func{valloc} è definita in
1528 \headfile{stdlib.h}, mentre sia le \acr{glibc} che le precedenti \acr{libc4}
1529 e \acr{libc5} la dichiarano in \headfile{malloc.h}, lo stesso vale per
1530 \func{memalign} che in alcuni sistemi è dichiarata in \headfile{stdlib.h}.}
1531 per questo motivo il loro uso è sconsigliato, essendo state sostituite dalla
1532 nuova \funcd{posix\_memalign}, che è stata standardizzata in POSIX.1d; il suo
1537 \fdecl{posix\_memalign(void **memptr, size\_t alignment, size\_t size)}
1538 \fdesc{Alloca un buffer di memoria allineato ad un multiplo
1539 di \param{alignment}.}
1541 {Entrambe le funzioni ritornano un puntatore al blocco di memoria allocato in
1542 caso di successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
1543 assumerà uno dei valori:
1545 \item[\errcode{EINVAL}] \param{alignment} non è potenza di due e multiplo
1546 di \code{sizeof(void *)}.
1547 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione.
1551 La funzione restituisce il puntatore al buffer allocato di dimensioni pari
1552 a \param{size} nella variabile (di tipo \texttt{void *}) posta all'indirizzo
1553 indicato da \param{memptr}. La funzione fallisce nelle stesse condizioni delle
1554 due funzioni precedenti, ma a loro differenza restituisce direttamente come
1555 valore di ritorno il codice di errore. Come per le precedenti la memoria
1556 allocata con \func{posix\_memalign} deve essere disallocata con \func{free},
1557 che in questo caso però è quanto richiesto dallo standard. Si tenga presente
1558 infine che nessuna di queste funzioni inizializza il buffer di memoria
1559 allocato, il loro comportamento cioè è analogo, allineamento a parte, a quello
1562 Un secondo caso in cui risulta estremamente utile poter avere un maggior
1563 controllo delle modalità di allocazione della memoria è quello in cui cercano
1564 errori di programmazione. Esempi di questi errori sono i \itindex{double~free}
1565 \textit{double free}, o i cosiddetti \itindex{buffer~overrun} \textit{buffer
1566 overrun}, cioè le scritture su un buffer oltre le dimensioni della sua
1567 allocazione,\footnote{entrambe queste operazioni causano in genere la
1568 corruzione dei dati di controllo delle funzioni di allocazione, che vengono
1569 anch'essi mantenuti nello \itindex{heap} \textit{heap} per tenere traccia
1570 delle zone di memoria allocata.} o i classici \itindex{memory~leak}
1571 \textit{memory leak}.
1573 Abbiamo visto in sez.~\ref{sec:proc_mem_lock} come una prima funzionalità di
1574 ausilio nella ricerca di questi errori sia l'uso della variabile di ambiente
1575 \envvar{MALLOC\_CHECK\_}. Una modalità alternativa per effettuare dei
1576 controlli di consistenza sullo stato delle allocazioni di memoria eseguite con
1577 \func{malloc}, anche questa fornita come estensione specifica (e non standard)
1578 della \acr{glibc}, è quella di utilizzare la funzione \funcd{mcheck}, che deve
1579 essere chiamata prima di eseguire qualunque allocazione con \func{malloc}; il
1584 \fdecl{int mcheck(void (*abortfn) (enum mcheck\_status status))}
1585 \fdesc{Attiva i controlli di consistenza delle allocazioni di memoria.}
1587 {La funzione ritorna $0$ in caso di successo e $-1$ per un errorre;
1588 \var{errno} non viene impostata.}
1591 La funzione consente di registrare una funzione di emergenza che verrà
1592 eseguita tutte le volte che, in una successiva esecuzione di \func{malloc},
1593 venissero trovate delle inconsistenze, come delle operazioni di scrittura
1594 oltre i limiti dei buffer allocati. Per questo motivo la funzione deve essere
1595 chiamata prima di qualunque allocazione di memoria, altrimenti fallirà.
1597 Se come primo argomento di \func{mcheck} si passa \val{NULL} verrà utilizzata
1598 una funzione predefinita che stampa un messaggio di errore ed invoca la
1599 funzione \func{abort} (vedi sez.~\ref{sec:sig_alarm_abort}), altrimenti si
1600 dovrà creare una funzione personalizzata in grado di ricevere il tipo di
1601 errore ed agire di conseguenza.
1603 Nonostante la scarsa leggibilità del prototipo si tratta semplicemente di
1604 definire una funzione di tipo \code{void abortfn(enum mcheck\_status status)},
1605 che non deve restituire nulla e che deve avere un unico argomento di tipo
1606 \code{mcheck\_status}. In caso di errore la funzione verrà eseguita ricevendo
1607 un opportuno valore di \param{status} che è un tipo enumerato che può assumere
1608 soltanto i valori di tab.~\ref{tab:mcheck_status_value} che indicano la
1609 tipologia di errore riscontrata.
1614 \begin{tabular}[c]{|l|p{7cm}|}
1616 \textbf{Valore} & \textbf{Significato} \\
1619 \const{MCHECK\_OK} & Riportato a \func{mprobe} se nessuna
1620 inconsistenza è presente.\\
1621 \const{MCHECK\_DISABLED}& Riportato a \func{mprobe} se si è chiamata
1622 \func{mcheck} dopo aver già usato
1624 \const{MCHECK\_HEAD} & I dati immediatamente precedenti il buffer sono
1625 stati modificati, avviene in genere quando si
1626 decrementa eccessivamente il valore di un
1627 puntatore scrivendo poi prima dell'inizio del
1629 \const{MCHECK\_TAIL} & I dati immediatamente seguenti il buffer sono
1630 stati modificati, succede quando si va scrivere
1631 oltre la dimensione corretta del buffer.\\
1632 \const{MCHECK\_FREE} & Il buffer è già stato disallocato.\\
1635 \caption{Valori dello stato dell'allocazione di memoria ottenibili dalla
1636 funzione di terminazione installata con \func{mcheck}.}
1637 \label{tab:mcheck_status_value}
1640 Una volta che si sia chiamata \func{mcheck} con successo si può anche
1641 controllare esplicitamente lo stato delle allocazioni senza aspettare un
1642 errore nelle relative funzioni utilizzando la funzione \funcd{mprobe}, il cui
1647 \fdecl{enum mcheck\_status mprobe(ptr)}
1648 \fdesc{Esegue un controllo di consistenza delle allocazioni.}
1650 {La funzione ritorna un codice fra quelli riportati in
1651 tab.~\ref{tab:mcheck_status_value} e non ha errori.}
1654 La funzione richiede che si passi come argomento un puntatore ad un blocco di
1655 memoria precedentemente allocato con \func{malloc} o \func{realloc}, e
1656 restituisce lo stesso codice di errore che si avrebbe per la funzione di
1657 emergenza ad una successiva chiamata di una funzione di allocazione, e poi i
1658 primi due codici che indicano rispettivamente quando tutto è a posto o il
1659 controllo non è possibile per non aver chiamato \func{mcheck} in tempo.
1661 % TODO: trattare le altre funzionalità avanzate di \func{malloc}, mallopt,
1662 % mtrace, muntrace, mallinfo e gli hook con le glibc 2.10 c'è pure malloc_info
1663 % a sostituire mallinfo, vedi http://udrepper.livejournal.com/20948.html
1666 \section{Argomenti, ambiente ed altre proprietà di un processo}
1667 \label{sec:proc_options}
1669 In questa sezione esamineremo le funzioni che permettono di gestire gli
1670 argomenti e le opzioni, e quelle che consentono di manipolare ed utilizzare le
1671 variabili di ambiente. Accenneremo infine alle modalità con cui si può gestire
1672 la localizzazione di un programma modificandone il comportamento a seconda
1673 della lingua o del paese a cui si vuole faccia riferimento nelle sue
1676 \subsection{Il formato degli argomenti}
1677 \label{sec:proc_par_format}
1679 Tutti i programmi hanno la possibilità di ricevere argomenti e opzioni quando
1680 vengono lanciati e come accennato in sez.~\ref{sec:proc_main} questo viene
1681 effettuato attraverso gli argomenti \param{argc} e \param{argv} ricevuti nella
1682 funzione \code{main} all'avvio del programma. Questi argomenti vengono passati
1683 al programma dalla shell o dal processo che esegue la \func{exec} (secondo le
1684 modalità che vedremo in sez.~\ref{sec:proc_exec}) quando questo viene messo in
1687 Nel caso più comune il passaggio di argomenti ed opzioni viene effettuato
1688 dalla shell, che si incarica di leggere la linea di comando con cui si lancia
1689 il programma e di effettuarne la scansione (il cosiddetto \textit{parsing})
1690 per individuare le parole che la compongono, ciascuna delle quali potrà essere
1691 considerata un argomento o un'opzione.
1693 Di norma per individuare le parole che andranno a costituire la lista degli
1694 argomenti viene usato come carattere di separazione lo spazio o il tabulatore,
1695 ma la cosa dipende ovviamente dalle modalità con cui si effettua la scansione
1696 e dalle convenzioni adottate dal programma che la esegue: ad esempio la shell
1697 consente di proteggere con opportuni caratteri di controllo argomenti che
1698 contengono degli spazi evitando di spezzarli in parole diverse.
1702 % \includegraphics[width=13cm]{img/argv_argc}
1703 % \includegraphics[width=13cm]{img/argv_argc}
1704 \begin{tikzpicture}[>=stealth]
1705 \draw (0.5,2.5) rectangle (3.5,3);
1706 \draw (2,2.75) node {\texttt{argc = 5}};
1707 \draw (5,2.5) rectangle (8,3);
1708 \draw (6.5,2.75) node {\texttt{argv[0]}};
1709 \draw [->] (8,2.75) -- (9,2.75);
1710 \draw (9,2.75) node [anchor=west] {\texttt{"touch"}};
1711 \draw (5,2) rectangle (8,2.5);
1712 \draw (6.5,2.25) node {\texttt{argv[1]}};
1713 \draw [->] (8,2.25) -- (9,2.25);
1714 \draw (9,2.25) node [anchor=west] {\texttt{"-r"}};
1715 \draw (5,1.5) rectangle (8,2);
1716 \draw (6.5,1.75) node {\texttt{argv[2]}};
1717 \draw [->] (8,1.75) -- (9,1.75);
1718 \draw (9,1.75) node [anchor=west] {\texttt{"riferimento.txt"}};
1719 \draw (5,1.0) rectangle (8,1.5);
1720 \draw (6.5,1.25) node {\texttt{argv[3]}};
1721 \draw [->] (8,1.25) -- (9,1.25);
1722 \draw (9,1.25) node [anchor=west] {\texttt{"-m"}};
1723 \draw (5,0.5) rectangle (8,1.0);
1724 \draw (6.5,0.75) node {\texttt{argv[4]}};
1725 \draw [->] (8,0.75) -- (9,0.75);
1726 \draw (9,0.75) node [anchor=west] {\texttt{"questofile.txt"}};
1727 \draw (4.25,3.5) node{\texttt{"touch -r riferimento.txt -m questofile.txt"}};
1730 \caption{Esempio dei valori di \param{argv} e \param{argc} generati nella
1731 scansione di una riga di comando.}
1732 \label{fig:proc_argv_argc}
1735 Indipendentemente da come viene eseguita, il risultato finale della scansione
1736 dovrà comunque essere la costruzione del vettore di puntatori \param{argv} in
1737 cui si devono inserire in successione i puntatori alle stringhe costituenti i
1738 vari argomenti ed opzioni da passare al programma, e della
1739 variabile \param{argc} che deve essere inizializzata al numero di stringhe
1740 contenute in \param{argv}. Nel caso della shell questo comporta ad esempio che
1741 il primo argomento sia sempre il nome del programma. Un esempio di questo
1742 meccanismo è mostrato in fig.~\ref{fig:proc_argv_argc}, che illustra il
1743 risultato della scansione di una riga di comando.
1746 \subsection{La gestione delle opzioni}
1747 \label{sec:proc_opt_handling}
1749 In generale un programma Unix riceve da linea di comando sia gli argomenti che
1750 le opzioni, queste ultime sono standardizzate per essere riconosciute come
1751 tali: un elemento di \param{argv} successivo al primo che inizia con il
1752 carattere ``\texttt{-}'' e che non sia un singolo ``\texttt{-}'' o un
1753 ``\texttt{-{}-}'' viene considerato un'opzione. In genere le opzioni sono
1754 costituite da una lettera singola (preceduta dal carattere ``\texttt{-}'') e
1755 possono avere o no un parametro associato. Un esempio tipico può essere quello
1756 mostrato in fig.~\ref{fig:proc_argv_argc}. In quel caso le opzioni sono
1757 \cmd{-r} e \cmd{-m} e la prima vuole un parametro mentre la seconda no
1758 (\cmd{questofile.txt} è un argomento del programma, non un parametro di
1761 Per gestire le opzioni all'interno degli argomenti a linea di comando passati
1762 in \param{argv} la libreria standard del C fornisce la funzione
1763 \funcd{getopt}, che ha il seguente prototipo:
1767 \fdecl{int getopt(int argc, char * const argv[], const char *optstring)}
1768 \fdesc{Esegue la scansione delle opzioni negli argomenti della funzione
1771 {Ritorna il carattere che segue l'opzione, ``\texttt{:}'' se manca un
1772 parametro all'opzione, ``\texttt{?}'' se l'opzione è sconosciuta, e $-1$ se
1773 non esistono altre opzioni.}
1776 Questa funzione prende come argomenti le due variabili \param{argc} e
1777 \param{argv} che devono essere quelle passate come argomenti di \code{main}
1778 all'esecuzione del programma, ed una stringa \param{optstring} che indica
1779 quali sono le opzioni valide. La funzione effettua la scansione della lista
1780 degli argomenti ricercando ogni stringa che comincia con il carattere
1781 ``\texttt{-}'' e ritorna ogni volta che trova un'opzione valida.
1783 La stringa \param{optstring} indica quali sono le opzioni riconosciute ed è
1784 costituita da tutti i caratteri usati per identificare le singole opzioni, se
1785 l'opzione ha un parametro al carattere deve essere fatto seguire il carattere
1786 di due punti (``\texttt{:}''); nel caso di fig.~\ref{fig:proc_argv_argc} ad
1787 esempio la stringa di opzioni avrebbe dovuto contenere \texttt{"r:m"}.
1789 La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
1790 funzione all'interno di un ciclo, fintanto che essa non ritorna il valore $-1$
1791 che indica che non ci sono più opzioni. Nel caso si incontri un'opzione non
1792 dichiarata in \param{optstring} viene ritornato il carattere ``\texttt{?}''
1793 mentre se un'opzione che lo richiede non è seguita da un parametro viene
1794 ritornato il carattere ``\texttt{:}'', infine se viene incontrato il valore
1795 ``\texttt{-{}-}'' la scansione viene considerata conclusa, anche se vi sono
1796 altri elementi di \param{argv} che cominciano con il carattere ``\texttt{-}''.
1798 \begin{figure}[!htb]
1799 \footnotesize \centering
1800 \begin{minipage}[c]{\codesamplewidth}
1801 \includecodesample{listati/option_code.c}
1804 \caption{Esempio di codice per la gestione delle opzioni.}
1805 \label{fig:proc_options_code}
1808 Quando \func{getopt} trova un'opzione fra quelle indicate in \param{optstring}
1809 essa ritorna il valore numerico del carattere, in questo modo si possono
1810 eseguire azioni specifiche usando uno \instruction{switch}; la funzione
1811 inoltre inizializza alcune \index{variabili!globali} variabili globali:
1813 \item \var{char *optarg} contiene il puntatore alla stringa parametro
1815 \item \var{int optind} alla fine della scansione restituisce l'indice del
1816 primo elemento di \param{argv} che non è un'opzione.
1817 \item \var{int opterr} previene, se posto a zero, la stampa di un messaggio
1818 di errore in caso di riconoscimento di opzioni non definite.
1819 \item \var{int optopt} contiene il carattere dell'opzione non riconosciuta.
1822 In fig.~\ref{fig:proc_options_code} si è mostrata la sezione del programma
1823 \file{fork\_test.c}, che useremo nel prossimo capitolo per effettuare dei test
1824 sulla creazione dei processi, deputata alla decodifica delle opzioni a riga di
1825 comando da esso supportate.
1827 Si può notare che si è anzitutto (\texttt{\small 1}) disabilitata la stampa di
1828 messaggi di errore per opzioni non riconosciute, per poi passare al ciclo per
1829 la verifica delle opzioni (\texttt{\small 2-27}); per ciascuna delle opzioni
1830 possibili si è poi provveduto ad un'azione opportuna, ad esempio per le tre
1831 opzioni che prevedono un parametro si è effettuata la decodifica del medesimo,
1832 il cui indirizzo è contenuto nella variabile \var{optarg}), avvalorando la
1833 relativa variabile (\texttt{\small 12-14}, \texttt{\small 15-17} e
1834 \texttt{\small 18-20}). Completato il ciclo troveremo in \var{optind} l'indice
1835 in \code{argv[]} del primo degli argomenti rimanenti nella linea di comando.
1837 Normalmente \func{getopt} compie una permutazione degli elementi di
1838 \param{argv} cosicché alla fine della scansione gli elementi che non sono
1839 opzioni sono spostati in coda al vettore. Oltre a questa esistono altre due
1840 modalità di gestire gli elementi di \param{argv}; se \param{optstring} inizia
1841 con il carattere ``\texttt{+}'' (o è impostata la variabile di ambiente
1842 \macro{POSIXLY\_CORRECT}) la scansione viene fermata non appena si incontra un
1843 elemento che non è un'opzione.
1845 L'ultima modalità, usata quando un programma può gestire la mescolanza fra
1846 opzioni e argomenti, ma se li aspetta in un ordine definito, si attiva
1847 quando \param{optstring} inizia con il carattere ``\texttt{-}''. In questo caso
1848 ogni elemento che non è un'opzione viene considerato comunque un'opzione e
1849 associato ad un valore di ritorno pari ad 1, questo permette di identificare
1850 gli elementi che non sono opzioni, ma non effettua il riordinamento del
1851 vettore \param{argv}.
1854 \subsection{Le variabili di ambiente}
1855 \label{sec:proc_environ}
1857 \index{variabili!di~ambiente|(}
1858 Oltre agli argomenti passati a linea di comando esiste un'altra modalità che
1859 permette di trasferire ad un processo delle informazioni in modo da
1860 modificarne il comportamento. Ogni processo infatti riceve dal sistema, oltre
1861 alle variabili \param{argv} e \param{argc} anche un \textsl{ambiente} (in
1862 inglese \textit{environment}); questo viene espresso nella forma di una lista
1863 (chiamata \textit{environment list}) delle cosiddette \textsl{variabili di
1864 ambiente}, i valori di queste variabili possono essere poi usati dal
1867 Anche in questo caso la lista delle \textsl{variabili di ambiente} deve essere
1868 costruita ed utilizzata nella chiamata alla funzione \func{exec} (torneremo su
1869 questo in sez.~\ref{sec:proc_exec}) quando questo viene lanciato. Come per la
1870 lista degli argomenti anche questa lista è un vettore di puntatori a
1871 caratteri, ciascuno dei quali punta ad una stringa, terminata da un
1872 \val{NULL}. A differenza di \code{argv[]} in questo caso non si ha una
1873 lunghezza del vettore data da un equivalente di \param{argc}, ma la lista è
1874 terminata da un puntatore nullo.
1876 L'indirizzo della lista delle variabili di ambiente è passato attraverso la
1877 \index{variabili!globali} variabile globale \var{environ}, che viene definita
1878 automaticamente per ciascun processo, e a cui si può accedere attraverso una
1879 semplice dichiarazione del tipo:
1880 \includecodesnip{listati/env_ptr.c}
1881 un esempio della struttura di questa lista, contenente alcune delle variabili
1882 più comuni che normalmente sono definite dal sistema, è riportato in
1883 fig.~\ref{fig:proc_envirno_list}.
1886 % \includegraphics[width=15 cm]{img/environ_var}
1887 \begin{tikzpicture}[>=stealth]
1888 \draw (2,3.5) node {\textsf{Environment pointer}};
1889 \draw (6,3.5) node {\textsf{Environment list}};
1890 \draw (10.5,3.5) node {\textsf{Environment string}};
1891 \draw (0.5,2.5) rectangle (3.5,3);
1892 \draw (2,2.75) node {\texttt{environ}};
1893 \draw [->] (3.5,2.75) -- (4.5,2.75);
1894 \draw (4.5,2.5) rectangle (7.5,3);
1895 \draw (6,2.75) node {\texttt{environ[0]}};
1896 \draw (4.5,2) rectangle (7.5,2.5);
1897 \draw (6,2.25) node {\texttt{environ[1]}};
1898 \draw (4.5,1.5) rectangle (7.5,2);
1899 \draw (4.5,1) rectangle (7.5,1.5);
1900 \draw (4.5,0.5) rectangle (7.5,1);
1901 \draw (4.5,0) rectangle (7.5,0.5);
1902 \draw (6,0.25) node {\texttt{NULL}};
1903 \draw [->] (7.5,2.75) -- (8.5,2.75);
1904 \draw (8.5,2.75) node[right] {\texttt{HOME=/home/piccardi}};
1905 \draw [->] (7.5,2.25) -- (8.5,2.25);
1906 \draw (8.5,2.25) node[right] {\texttt{PATH=:/bin:/usr/bin}};
1907 \draw [->] (7.5,1.75) -- (8.5,1.75);
1908 \draw (8.5,1.75) node[right] {\texttt{SHELL=/bin/bash}};
1909 \draw [->] (7.5,1.25) -- (8.5,1.25);
1910 \draw (8.5,1.25) node[right] {\texttt{EDITOR=emacs}};
1911 \draw [->] (7.5,0.75) -- (8.5,0.75);
1912 \draw (8.5,0.75) node[right] {\texttt{OSTYPE=linux-gnu}};
1914 \caption{Esempio di lista delle variabili di ambiente.}
1915 \label{fig:proc_envirno_list}
1918 Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
1919 \textsl{\texttt{NOME=valore}} ed in questa forma che le funzioni di gestione
1920 che vedremo a breve se le aspettano, se pertanto si dovesse costruire
1921 manualmente un ambiente si abbia cura di rispettare questa convenzione.
1922 Inoltre alcune variabili, come quelle elencate in
1923 fig.~\ref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
1924 da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
1925 usare nomi espressi in caratteri maiuscoli.\footnote{ma si tratta solo di una
1926 convenzione, niente vieta di usare caratteri minuscoli, come avviene in vari
1929 Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
1930 riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
1931 costituiscono un modo comodo per definire un comportamento specifico senza
1932 dover ricorrere all'uso di opzioni a linea di comando o di file di
1933 configurazione. É di norma cura della shell, quando esegue un comando, passare
1934 queste variabili al programma messo in esecuzione attraverso un uso opportuno
1935 delle relative chiamate (si veda sez.~\ref{sec:proc_exec}).
1937 La shell ad esempio ne usa molte per il suo funzionamento, come \envvar{PATH}
1938 per indicare la lista delle directory in cui effettuare la ricerca dei comandi
1939 o \envvar{PS1} per impostare il proprio \textit{prompt}. Alcune di esse, come
1940 \envvar{HOME}, \envvar{USER}, ecc. sono invece definite al login (per i
1941 dettagli si veda sez.~\ref{sec:sess_login}), ed in genere è cura della propria
1942 distribuzione definire le opportune variabili di ambiente in uno script di
1943 avvio. Alcune servono poi come riferimento generico per molti programmi, come
1944 \envvar{EDITOR} che indica l'editor preferito da invocare in caso di
1945 necessità. Una in particolare, \envvar{LANG}, serve a controllare la
1946 localizzazione del programma
1947 %(su cui torneremo in sez.~\ref{sec:proc_localization})
1948 per adattarlo alla lingua ed alle convezioni
1951 Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
1952 comuni), come riportato in tab.~\ref{tab:proc_env_var}. GNU/Linux le supporta
1953 tutte e ne definisce anche altre, in particolare poi alcune funzioni di
1954 libreria prevedono la presenza di specifiche variabili di ambiente che ne
1955 modificano il comportamento, come quelle usate per indicare una localizzazione
1956 e quelle per indicare un fuso orario; una lista più completa che comprende
1957 queste ed ulteriori variabili si può ottenere con il comando \cmd{man 7
1963 \begin{tabular}[c]{|l|c|c|c|l|}
1965 \textbf{Variabile} & \textbf{POSIX} & \textbf{XPG3}
1966 & \textbf{Linux} & \textbf{Descrizione} \\
1969 \texttt{USER} &$\bullet$&$\bullet$&$\bullet$& Nome utente\\
1970 \texttt{LOGNAME}&$\bullet$&$\bullet$&$\bullet$& Nome di login\\
1971 \texttt{HOME} &$\bullet$&$\bullet$&$\bullet$& Directory base
1973 \texttt{LANG} &$\bullet$&$\bullet$&$\bullet$& Localizzazione\\
1974 \texttt{PATH} &$\bullet$&$\bullet$&$\bullet$& Elenco delle directory
1976 \texttt{PWD} &$\bullet$&$\bullet$&$\bullet$& Directory corrente\\
1977 \texttt{SHELL} &$\bullet$&$\bullet$&$\bullet$& Shell in uso\\
1978 \texttt{TERM} &$\bullet$&$\bullet$&$\bullet$& Tipo di terminale\\
1979 \texttt{PAGER} &$\bullet$&$\bullet$&$\bullet$& Programma per vedere i
1981 \texttt{EDITOR} &$\bullet$&$\bullet$&$\bullet$& Editor preferito\\
1982 \texttt{BROWSER}&$\bullet$&$\bullet$&$\bullet$& Browser preferito\\
1983 \texttt{TMPDIR} &$\bullet$&$\bullet$&$\bullet$& Directory dei file
1987 \caption{Esempi delle variabili di ambiente più comuni definite da vari
1989 \label{tab:proc_env_var}
1992 Lo standard ANSI C prevede l'esistenza di un ambiente, e pur non entrando
1993 nelle specifiche di come sono strutturati i contenuti, definisce la funzione
1994 \funcd{getenv} che permette di ottenere i valori delle variabili di ambiente;
1999 \fdecl{char *getenv(const char *name)}
2000 \fdesc{Cerca una variabile di ambiente del processo.}
2002 {La funzione ritorna il puntatore alla stringa contenente il valore della
2003 variabile di ambiente in caso di successo e \val{NULL} per un errore.}
2006 La funzione effettua una ricerca nell'ambiente del processo cercando una
2007 variabile il cui nome corrisponda a quanto indicato con
2008 l'argomento \param{name}, ed in caso di successo ritorna il puntatore alla
2009 stringa che ne contiene il valore, nella forma ``\texttt{NOME=valore}''.
2014 \begin{tabular}[c]{|l|c|c|c|c|c|c|}
2016 \textbf{Funzione} & \textbf{ANSI C} & \textbf{POSIX.1} & \textbf{XPG3} &
2017 \textbf{SVr4} & \textbf{BSD} & \textbf{Linux} \\
2020 \func{getenv} & $\bullet$ & $\bullet$ & $\bullet$
2021 & $\bullet$ & $\bullet$ & $\bullet$ \\
2022 \func{setenv} & -- & -- & --
2023 & -- & $\bullet$ & $\bullet$ \\
2024 \func{unsetenv}& -- & -- & --
2025 & -- & $\bullet$ & $\bullet$ \\
2026 \func{putenv} & -- & opz. & $\bullet$
2027 & -- & $\bullet$ & $\bullet$ \\
2028 \func{clearenv}& -- & opz. & --
2029 & -- & -- & $\bullet$ \\
2032 \caption{Funzioni per la gestione delle variabili di ambiente.}
2033 \label{tab:proc_env_func}
2036 Oltre a questa funzione di lettura, che è l'unica definita dallo standard ANSI
2037 C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
2038 utilizzare per impostare, modificare e per cancellare le variabili di
2039 ambiente. Uno schema delle funzioni previste nei vari standard e disponibili
2040 in Linux è riportato in tab.~\ref{tab:proc_env_func}. Tutte le funzioni sono
2041 state comunque inserite nello standard POSIX.1-2001, ad eccetto di
2042 \func{clearenv} che è stata rigettata.
2044 In Linux sono definite tutte le funzioni elencate in
2045 tab.~\ref{tab:proc_env_func},\footnote{in realtà nelle libc4 e libc5 sono
2046 definite solo le prime quattro, \func{clearenv} è stata introdotta con la
2047 \acr{glibc} 2.0.} anche se parte delle funzionalità sono ridondanti. La
2048 prima funzione di manipolazione che prenderemo in considerazione è
2049 \funcd{putenv}, che consente di aggiungere, modificare e cancellare una
2050 variabile di ambiente; il suo prototipo è:
2053 \fdecl{int putenv(char *string)}
2054 \fdesc{Inserisce, modifica o rimuove una variabile d'ambiente.}
2056 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, che può
2057 essere solo \errval{ENOMEM}.}
2060 La funzione prende come argomento una stringa analoga a quella restituita da
2061 \func{getenv} e sempre nella forma ``\texttt{NOME=valore}''. Se la variabile
2062 specificata (nel caso \texttt{NOME}) non esiste la stringa sarà aggiunta
2063 all'ambiente, se invece esiste il suo valore sarà impostato a quello
2064 specificato dal contenuto di \param{string} (nel caso \texttt{valore}). Se
2065 invece si passa come argomento solo il nome di una variabile di ambiente
2066 (cioè \param{string} è nella forma ``\texttt{NOME}'' e non contiene il
2067 carattere ``\texttt{=}'') allora questa, se presente nell'ambiente, verrà
2070 Si tenga presente che, seguendo lo standard SUSv2, le \acr{glibc} successive
2071 alla versione 2.1.2 aggiungono direttamente \param{string} nella lista delle
2072 variabili di ambiente illustrata in fig.~\ref{fig:proc_envirno_list}
2073 sostituendo il relativo puntatore;\footnote{il comportamento è lo stesso delle
2074 vecchie \acr{libc4} e \acr{libc5}; nella \acr{glibc}, dalla versione 2.0
2075 alla 2.1.1, veniva invece fatta una copia, seguendo il comportamento di
2076 BSD4.4; dato che questo può dar luogo a perdite di memoria e non rispetta lo
2077 standard il comportamento è stato modificato a partire dalle 2.1.2,
2078 eliminando anche, sempre in conformità a SUSv2, l'attributo \direct{const}
2079 dal prototipo.} pertanto ogni cambiamento alla stringa in questione si
2080 riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
2081 questa funzione una \index{variabili!automatiche} variabile automatica (per
2082 evitare i problemi esposti in sez.~\ref{sec:proc_var_passing}). Benché non sia
2083 richiesto dallo standard nelle versioni della \acr{glibc} a partire dalla 2.1
2084 la funzione è rientrante (vedi sez.~\ref{sec:proc_reentrant}).
2086 Infine quando una chiamata a \func{putenv} comporta la necessità di creare una
2087 nuova versione del vettore \var{environ} questo sarà allocato automaticamente,
2088 ma la versione corrente sarà deallocata solo se anch'essa è risultante da
2089 un'allocazione fatta in precedenza da un'altra \func{putenv}. Questo avviene
2090 perché il vettore delle variabili di ambiente iniziale, creato dalla chiamata
2091 ad \func{exec} (vedi sez.~\ref{sec:proc_exec}) è piazzato nella memoria al di
2092 sopra dello \itindex{stack} \textit{stack}, (vedi
2093 fig.~\ref{fig:proc_mem_layout}) e non nello \itindex{heap} \textit{heap} e
2094 quindi non può essere deallocato. Inoltre la memoria associata alle variabili
2095 di ambiente eliminate non viene liberata.
2097 Come alternativa a \func{putenv} si può usare la funzione \funcd{setenv} che
2098 però consente solo di aggiungere o modificare una variabile di ambiente; il
2103 \fdecl{int setenv(const char *name, const char *value, int overwrite)}
2104 \fdesc{Inserisce o modifica una variabile di ambiente.}
2106 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
2107 nel qual caso \var{errno} assumerà uno dei valori:
2109 \item[\errcode{EINVAL}] \param{name} è \val{NULL} o una stringa di lunghezza
2110 nulla o che contiene il carattere ``\texttt{=}''.
2111 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per aggiungere una nuova
2112 variabile all'ambiente.
2116 La funzione consente di specificare separatamente nome e valore della
2117 variabile di ambiente da aggiungere negli argomenti \param{name}
2118 e \param{value}. Se la variabile è già presente nell'ambiente
2119 l'argomento \param{overwrite} specifica il comportamento della funzione, se
2120 diverso da zero sarà sovrascritta, se uguale a zero sarà lasciata immutata. A
2121 differenza di \func{putenv} la funzione esegue delle copie del contenuto degli
2122 argomenti \param{name} e \param{value} e non è necessario preoccuparsi di
2123 allocarli in maniera permanente.
2125 La cancellazione di una variabile di ambiente viene invece gestita
2126 esplicitamente con \funcd{unsetenv}, il cui prototipo è:
2130 \fdecl{int unsetenv(const char *name)}
2131 \fdesc{Rimuove una variabile di ambiente.}
2133 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
2134 nel qual caso \var{errno} assumerà uno dei valori:
2136 \item[\errcode{EINVAL}] \param{name} è \val{NULL} o una stringa di lunghezza
2137 nulla o che contiene il carattere ``\texttt{=}''.
2141 La funzione richiede soltanto il nome della variabile di ambiente
2142 nell'argomento \param{name}, se la variabile non esiste la funzione ritorna
2143 comunque con un valore di successo.\footnote{questo con le versioni della
2144 \acr{glibc} successive la 2.2.2, per le precedenti \func{unsetenv} era
2145 definita come \texttt{void} e non restituiva nessuna informazione.}
2147 L'ultima funzione per la gestione dell'ambiente è
2148 \funcd{clearenv},\footnote{che come accennato è l'unica non presente nello
2149 standard POSIX.1-2000, ed è disponibili solo per versioni della \acr{glibc}
2150 a partire dalla 2.0; per poterla utilizzare occorre aver definito le macro
2151 \macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE}.} che viene usata per
2152 cancellare completamente tutto l'ambiente; il suo prototipo è:
2156 \fdecl{int clearenv(void)}
2157 \fdesc{Cancella tutto l'ambiente.}
2159 {La funzione ritorna $0$ in caso di successo e un valore diverso da zero per
2163 In genere si usa questa funzione in maniera precauzionale per evitare i
2164 problemi di sicurezza connessi nel trasmettere ai programmi che si invocano un
2165 ambiente che può contenere dei dati non controllati, le cui variabili possono
2166 causare effetti indesiderati. Con l'uso della funzione si provvede alla
2167 cancellazione di tutto l'ambiente originale in modo da poterne costruirne una
2168 versione ``\textsl{sicura}'' da zero.
2170 \index{variabili!di~ambiente|)}
2173 % \subsection{La localizzazione}
2174 % \label{sec:proc_localization}
2176 % Abbiamo accennato in sez.~\ref{sec:proc_environ} come la variabile di ambiente
2177 % \envvar{LANG} sia usata per indicare ai processi il valore della cosiddetta
2178 % \textsl{localizzazione}. Si tratta di una funzionalità fornita dalle librerie
2179 % di sistema\footnote{prenderemo in esame soltanto il caso della \acr{glibc}.}
2180 % che consente di gestire in maniera automatica sia la lingua in cui vengono
2181 % stampati i vari messaggi (come i messaggi associati agli errori che vedremo in
2182 % sez.~\ref{sec:sys_strerror}) che le convenzioni usate nei vari paesi per una
2183 % serie di aspetti come il formato dell'ora, quello delle date, gli ordinamenti
2184 % alfabetici, le espressioni della valute, ecc.
2188 % La localizzazione di un programma si può selezionare con la
2190 % In realtà perché un programma sia effettivamente localizzato non è sufficiente
2192 % TODO trattare, quando ci sarà tempo, setlocale ed il resto
2195 %\subsection{Opzioni in formato esteso}
2196 %\label{sec:proc_opt_extended}
2198 %Oltre alla modalità ordinaria di gestione delle opzioni trattata in
2199 %sez.~\ref{sec:proc_opt_handling} le \acr{glibc} forniscono una modalità
2200 %alternativa costituita dalle cosiddette \textit{long-options}, che consente di
2201 %esprimere le opzioni in una forma più descrittiva che nel caso più generale è
2202 %qualcosa del tipo di ``\texttt{-{}-option-name=parameter}''.
2204 %(NdA: questa parte verrà inserita in seguito).
2206 % TODO opzioni in formato esteso
2208 \section{Problematiche di programmazione generica}
2209 \label{sec:proc_gen_prog}
2211 Benché questo non sia un libro sul linguaggio C, è opportuno affrontare alcune
2212 delle problematiche generali che possono emergere nella programmazione con
2213 questo linguaggio e di quali precauzioni o accorgimenti occorre prendere per
2214 risolverle. Queste problematiche non sono specifiche di sistemi unix-like o
2215 multitasking, ma avendo trattato in questo capitolo il comportamento dei
2216 processi visti come entità a sé stanti, le riportiamo qui.
2219 \subsection{Il passaggio di variabili e valori di ritorno nelle funzioni}
2220 \label{sec:proc_var_passing}
2222 Una delle caratteristiche standard del C è che le variabili vengono passate
2223 alle funzioni che si invocano in un programma attraverso un meccanismo che
2224 viene chiamato \textit{by value}, diverso ad esempio da quanto avviene con il
2225 Fortran, dove le variabili sono passate, come suol dirsi, \textit{by
2226 reference}, o dal C++ dove la modalità del passaggio può essere controllata
2227 con l'operatore \cmd{\&}.
2229 Il passaggio di una variabile \textit{by value} significa che in realtà quello
2230 che viene passato alla funzione è una copia del valore attuale di quella
2231 variabile, copia che la funzione potrà modificare a piacere, senza che il
2232 valore originale nella funzione chiamante venga toccato. In questo modo non
2233 occorre preoccuparsi di eventuali effetti delle operazioni svolte nella
2234 funzione stessa sulla variabile passata come argomento.
2236 Questo però va inteso nella maniera corretta. Il passaggio \textit{by value}
2237 vale per qualunque variabile, puntatori compresi; quando però in una funzione
2238 si usano dei puntatori (ad esempio per scrivere in un buffer) in realtà si va
2239 a modificare la zona di memoria a cui essi puntano, per cui anche se i
2240 puntatori sono copie, i dati a cui essi puntano saranno sempre gli stessi, e
2241 le eventuali modifiche avranno effetto e saranno visibili anche nella funzione
2244 Nella maggior parte delle funzioni di libreria e delle \textit{system call} i
2245 puntatori vengono usati per scambiare dati (attraverso i buffer o le strutture
2246 a cui fanno riferimento) e le variabili normali vengono usate per specificare
2247 argomenti; in genere le informazioni a riguardo dei risultati vengono passate
2248 alla funzione chiamante attraverso il valore di ritorno. È buona norma
2249 seguire questa pratica anche nella programmazione normale.
2251 Talvolta però è necessario che la funzione possa restituire indietro alla
2252 funzione chiamante un valore relativo ad uno dei suoi argomenti usato anche in
2253 ingresso. Per far questo si usa il cosiddetto \itindex{value~result~argument}
2254 \textit{value result argument}, si passa cioè, invece di una normale
2255 variabile, un puntatore alla stessa. Gli esempi di questa modalità di
2256 passaggio sono moltissimi, ad esempio essa viene usata nelle funzioni che
2257 gestiscono i socket (in sez.~\ref{sec:TCP_functions}), in cui, per permettere
2258 al kernel di restituire informazioni sulle dimensioni delle strutture degli
2259 indirizzi utilizzate, viene usato proprio questo meccanismo.
2261 Occorre tenere ben presente questa differenza, perché le variabili passate in
2262 maniera ordinaria, che vengono inserite nello \textit{stack}, cessano di
2263 esistere al ritorno di una funzione, ed ogni loro eventuale modifica
2264 all'interno della stessa sparisce con la conclusione della stessa, per poter
2265 passare delle informazioni occorre quindi usare un puntatore che faccia
2266 riferimento ad un indirizzo accessibile alla funzione chiamante.
2268 Questo requisito di accessibilità è fondamentale, infatti dei possibili
2269 problemi che si possono avere con il passaggio dei dati è quello di restituire
2270 alla funzione chiamante dei dati che sono contenuti in una
2271 \index{variabili!automatiche} variabile automatica. Ovviamente quando la
2272 funzione ritorna la sezione dello \itindex{stack} \textit{stack} che conteneva
2273 la \index{variabili!automatiche} variabile automatica (si ricordi quanto detto
2274 in sez.~\ref{sec:proc_mem_alloc}) verrà liberata automaticamente e potrà
2275 essere riutilizzata all'invocazione di un'altra funzione, con le immaginabili
2276 conseguenze, quasi invariabilmente catastrofiche, di sovrapposizione e
2277 sovrascrittura dei dati.
2279 Per questo una delle regole fondamentali della programmazione in C è che
2280 all'uscita di una funzione non deve restare nessun riferimento alle sue
2281 \index{variabili!automatiche} variabili locali. Qualora sia necessario
2282 utilizzare delle variabili che devono essere viste anche dalla funzione
2283 chiamante queste devono essere allocate esplicitamente, o in maniera statica
2284 usando variabili globali o dichiarate come \direct{extern},\footnote{la
2285 direttiva \direct{extern} informa il compilatore che la variabile che si è
2286 dichiarata in una funzione non è da considerarsi locale, ma globale, e per
2287 questo allocata staticamente e visibile da tutte le funzioni dello stesso
2288 programma.} o dinamicamente con una delle funzioni della famiglia
2289 \func{malloc}, passando opportunamente il relativo puntatore fra le funzioni.
2292 \subsection{Il passaggio di un numero variabile di argomenti}
2293 \label{sec:proc_variadic}
2295 \index{funzioni!variadic|(}
2297 Come vedremo nei capitoli successivi, non sempre è possibile specificare un
2298 numero fisso di argomenti per una funzione. Lo standard ISO C prevede nella
2299 sua sintassi la possibilità di definire delle \textit{variadic function} che
2300 abbiano un numero variabile di argomenti, attraverso l'uso nella dichiarazione
2301 della funzione dello speciale costrutto ``\texttt{...}'', che viene chiamato
2304 Lo standard però non provvede a livello di linguaggio alcun meccanismo con cui
2305 dette funzioni possono accedere ai loro argomenti. L'accesso viene pertanto
2306 realizzato a livello della libreria standard del C che fornisce gli strumenti
2307 adeguati. L'uso di una \textit{variadic function} prevede quindi tre punti:
2309 \item \textsl{dichiarare} la funzione come \textit{variadic} usando un
2310 prototipo che contenga una \textit{ellipsis};
2311 \item \textsl{definire} la funzione come \textit{variadic} usando la stessa
2312 \textit{ellipsis}, ed utilizzare le apposite macro che consentono la
2313 gestione di un numero variabile di argomenti;
2314 \item \textsl{invocare} la funzione specificando prima gli argomenti fissi, ed
2315 a seguire quelli addizionali.
2318 Lo standard ISO C prevede che una \textit{variadic function} abbia sempre
2319 almeno un argomento fisso. Prima di effettuare la dichiarazione deve essere
2320 incluso l'apposito \textit{header file} \headfile{stdarg.h}; un esempio di
2321 dichiarazione è il prototipo della funzione \func{execl} che vedremo in
2322 sez.~\ref{sec:proc_exec}:
2323 \includecodesnip{listati/exec_sample.c}
2324 in questo caso la funzione prende due argomenti fissi ed un numero variabile
2325 di altri argomenti, che andranno a costituire gli elementi successivi al primo
2326 del vettore \param{argv} passato al nuovo processo. Lo standard ISO C richiede
2327 inoltre che l'ultimo degli argomenti fissi sia di tipo
2328 \textit{self-promoting}\footnote{il linguaggio C prevede che quando si
2329 mescolano vari tipi di dati, alcuni di essi possano essere \textsl{promossi}
2330 per compatibilità; ad esempio i tipi \ctyp{float} vengono convertiti
2331 automaticamente a \ctyp{double} ed i \ctyp{char} e gli \ctyp{short} ad
2332 \ctyp{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
2333 a sé stesso.} il che esclude vettori, puntatori a funzioni e interi di tipo
2334 \ctyp{char} o \ctyp{short} (con segno o meno). Una restrizione ulteriore di
2335 alcuni compilatori è di non dichiarare l'ultimo argomento fisso come variabile
2336 di tipo \direct{register}.\footnote{la direttiva \direct{register} del
2337 compilatore chiede che la variabile dichiarata tale sia mantenuta, nei
2338 limiti del possibile, all'interno di un registro del processore; questa
2339 direttiva è originaria dell'epoca dai primi compilatori, quando stava al
2340 programmatore scrivere codice ottimizzato, riservando esplicitamente alle
2341 variabili più usate l'uso dei registri del processore, oggi questa direttiva
2342 è in disuso pressoché completo dato che tutti i compilatori sono normalmente
2343 in grado di valutare con maggior efficacia degli stessi programmatori quando
2344 sia il caso di eseguire questa ottimizzazione.}
2346 Una volta dichiarata la funzione il secondo passo è accedere ai vari argomenti
2347 quando la si va a definire. Gli argomenti fissi infatti hanno un loro nome, ma
2348 quelli variabili vengono indicati in maniera generica dalla
2349 \textit{ellipsis}. L'unica modalità in cui essi possono essere recuperati è
2350 pertanto quella sequenziale, in cui vengono estratti dallo \itindex{stack}
2351 \textit{stack} secondo l'ordine in cui sono stati scritti nel prototipo della
2354 Per fare questo in \headfile{stdarg.h} sono definite delle macro specifiche,
2355 previste dallo standard ISO C89, che consentono di eseguire questa operazione.
2356 La prima di queste macro è \macro{va\_start}, che inizializza opportunamente
2357 una lista degli argomenti, la sua definizione è:
2362 \fdecl{void va\_start(va\_list ap, last)}
2363 \fdesc{Inizializza una lista degli argomenti di una funzione
2368 La macro inizializza il puntatore alla lista di argomenti \param{ap} che
2369 deve essere una apposita variabile di tipo \type{va\_list}; il
2370 parametro \param{last} deve indicare il nome dell'ultimo degli argomenti fissi
2371 dichiarati nel prototipo della funzione \textit{variadic}.
2373 La seconda macro di gestione delle liste di argomenti di una funzione
2374 \textit{variadic} è \macro{va\_arg}, che restituisce in successione un
2375 argomento della lista; la sua definizione è:
2380 \fdecl{type va\_arg(va\_list ap, type)}
2381 \fdesc{Restituisce il valore del successivo argomento opzionale.}
2385 La macro restituisce il valore di un argomento, modificando opportunamente la
2386 lista \param{ap} perché una chiamata successiva restituisca l'argomento
2387 seguente. La macro richiede che si specifichi il tipo dell'argomento che si
2388 andrà ad estrarre attraverso il parametro \param{type} che sarà anche il tipo
2389 del valore da essa restituito. Si ricordi che il tipo deve essere
2390 \textit{self-promoting}.
2392 In generale è perfettamente legittimo richiedere meno argomenti di quelli che
2393 potrebbero essere stati effettivamente forniti, per cui nella esecuzione delle
2394 \macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
2395 saranno ignorati. Se invece si richiedono più argomenti di quelli
2396 effettivamente forniti si otterranno dei valori indefiniti. Si avranno
2397 risultati indefiniti anche quando si chiama \macro{va\_arg} specificando un
2398 tipo che non corrisponde a quello usato per il corrispondente argomento.
2400 Infine una volta completata l'estrazione occorre indicare che si sono concluse
2401 le operazioni con la macro \macro{va\_end}, la cui definizione è:
2406 \fdecl{void va\_end(va\_list ap)}
2407 \fdesc{Conclude l'estrazione degli argomenti di una funzione
2412 Dopo l'uso di \macro{va\_end} la variabile \param{ap} diventa indefinita e
2413 successive chiamate a \macro{va\_arg} non funzioneranno. Nel caso del
2414 \cmd{gcc} l'uso di \macro{va\_end} può risultare inutile, ma è comunque
2415 necessario usarla per chiarezza del codice, per compatibilità con diverse
2416 implementazioni e per eventuali eventuali modifiche future a questo
2419 Riassumendo la procedura da seguire per effettuare l'estrazione degli
2420 argomenti di una funzione \textit{variadic} è la seguente:
2422 \item inizializzare una lista degli argomenti attraverso la macro
2424 \item accedere agli argomenti con chiamate successive alla macro
2425 \macro{va\_arg}: la prima chiamata restituirà il primo argomento, la seconda
2426 il secondo e così via;
2427 \item dichiarare la conclusione dell'estrazione degli argomenti invocando la
2428 macro \macro{va\_end}.
2431 Si tenga presente che si possono usare anche più liste degli argomenti,
2432 ciascuna di esse andrà inizializzata con \macro{va\_start} e letta con
2433 \macro{va\_arg}, e ciascuna potrà essere usata per scandire la lista degli
2434 argomenti in modo indipendente. Infine ciascuna scansione dovrà essere
2435 terminata con \macro{va\_end}.
2437 Un limite di queste macro è che i passi 1) e 3) devono essere eseguiti nel
2438 corpo principale della funzione, il passo 2) invece può essere eseguito anche
2439 in un'altra funzione, passandole lista degli argomenti \param{ap}. In questo
2440 caso però al ritorno della funzione \macro{va\_arg} non può più essere usata
2441 (anche se non si era completata l'estrazione) dato che il valore di \param{ap}
2442 risulterebbe indefinito.
2444 Esistono dei casi in cui è necessario eseguire più volte la scansione degli
2445 argomenti e poter memorizzare una posizione durante la stessa. In questo caso
2446 sembrerebbe naturale copiarsi la lista degli argomenti \param{ap} con una
2447 semplice assegnazione ad un'altra variabile dello stesso tipo. Dato che una
2448 delle realizzazioni più comuni di \type{va\_list} è quella di un puntatore
2449 nello \itindex{stack} \textit{stack} all'indirizzo dove sono stati salvati gli
2450 argomenti, è assolutamente normale pensare di poter effettuare questa
2453 In generale però possono esistere anche realizzazioni diverse, ed è per questo
2454 motivo che invece che di un semplice puntatore viene \type{va\_list} è quello
2455 che viene chiamato un \index{tipo!opaco} \textsl{tipo opaco}. Si chiamano così
2456 quei tipi di dati, in genere usati da una libreria, la cui struttura interna
2457 non deve essere vista dal programma chiamante (da cui deriva il nome opaco)
2458 che li devono utilizzare solo attraverso dalle opportune funzioni di
2461 Per questo motivo una variabile di tipo \type{va\_list} non può essere
2462 assegnata direttamente ad un'altra variabile dello stesso tipo, ma lo standard
2463 ISO C99\footnote{alcuni sistemi che non hanno questa macro provvedono al suo
2464 posto \macro{\_\_va\_copy} che era il nome proposto in una bozza dello
2465 standard.} ha previsto una macro ulteriore che permette di eseguire la
2466 copia di una lista degli argomenti:
2471 \fdecl{void va\_copy(va\_list dest, va\_list src)}
2472 \fdesc{Copia la lista degli argomenti di una funzione \textit{variadic}.}
2476 La macro copia l'attuale della lista degli argomenti \param{src} su una nuova
2477 lista \param{dest}. Anche in questo caso è buona norma chiudere ogni
2478 esecuzione di una \macro{va\_copy} con una corrispondente \macro{va\_end} sul
2479 nuovo puntatore alla lista degli argomenti.
2481 La chiamata di una funzione con un numero variabile di argomenti, posto che la
2482 si sia dichiarata e definita come tale, non prevede nulla di particolare;
2483 l'invocazione è identica alle altre, con gli argomenti, sia quelli fissi che
2484 quelli opzionali, separati da virgole. Quello che però è necessario tenere
2485 presente è come verranno convertiti gli argomenti variabili.
2487 In Linux gli argomenti dello stesso tipo sono passati allo stesso modo, sia
2488 che siano fissi sia che siano opzionali (alcuni sistemi trattano diversamente
2489 gli opzionali), ma dato che il prototipo non può specificare il tipo degli
2490 argomenti opzionali, questi verranno sempre promossi, pertanto nella ricezione
2491 dei medesimi occorrerà tenerne conto (ad esempio un \ctyp{char} verrà visto da
2492 \macro{va\_arg} come \ctyp{int}).
2494 Un altro dei problemi che si devono affrontare con le funzioni con un numero
2495 variabile di argomenti è che non esiste un modo generico che permetta di
2496 stabilire quanti sono gli argomenti effettivamente passati in una chiamata.
2498 Esistono varie modalità per affrontare questo problema; una delle più
2499 immediate è quella di specificare il numero degli argomenti opzionali come uno
2500 degli argomenti fissi. Una variazione di questo metodo è l'uso di un argomento
2501 fisso per specificare anche il tipo degli argomenti variabili, come fa la
2502 stringa di formato per \func{printf} (vedi sez.~\ref{sec:file_formatted_io}).
2504 Infine una ulteriore modalità diversa, che può essere applicata solo quando il
2505 tipo degli argomenti lo rende possibile, è quella che prevede di usare un
2506 valore speciale per l'ultimo argomento, come fa ad esempio \func{execl} che
2507 usa un puntatore \val{NULL} per indicare la fine della lista degli argomenti
2508 (vedi sez.~\ref{sec:proc_exec}).
2510 \index{funzioni!variadic|)}
2512 \subsection{Il controllo di flusso non locale}
2513 \label{sec:proc_longjmp}
2515 Il controllo del flusso di un programma in genere viene effettuato con le
2516 varie istruzioni del linguaggio C; fra queste la più bistrattata è il
2517 \instruction{goto}, che viene deprecato in favore dei costrutti della
2518 programmazione strutturata, che rendono il codice più leggibile e
2519 mantenibile. Esiste però un caso in cui l'uso di questa istruzione porta
2520 all'implementazione più efficiente e più chiara anche dal punto di vista della
2521 struttura del programma: quello dell'uscita in caso di errore.
2523 \index{salto~non-locale|(}
2525 Il C però non consente di effettuare un salto ad una etichetta definita in
2526 un'altra funzione, per cui se l'errore avviene in una funzione, e la sua
2527 gestione ordinaria è in un'altra, occorre usare quello che viene chiamato un
2528 \textsl{salto non-locale}. Il caso classico in cui si ha questa necessità,
2529 citato sia in \cite{APUE} che in \cite{GlibcMan}, è quello di un programma nel
2530 cui corpo principale vengono letti dei dati in ingresso sui quali viene
2531 eseguita, tramite una serie di funzioni di analisi, una scansione dei
2532 contenuti, da cui si ottengono le indicazioni per l'esecuzione di opportune
2535 Dato che l'analisi può risultare molto complessa, ed opportunamente suddivisa
2536 in fasi diverse, la rilevazione di un errore nei dati in ingresso può accadere
2537 all'interno di funzioni profondamente annidate l'una nell'altra. In questo
2538 caso si dovrebbe gestire, per ciascuna fase, tutta la casistica del passaggio
2539 all'indietro di tutti gli errori rilevabili dalle funzioni usate nelle fasi
2540 successive. Questo comporterebbe una notevole complessità, mentre sarebbe
2541 molto più comodo poter tornare direttamente al ciclo di lettura principale,
2542 scartando l'input come errato.\footnote{a meno che, come precisa
2543 \cite{GlibcMan}, alla chiusura di ciascuna fase non siano associate
2544 operazioni di pulizia specifiche (come deallocazioni, chiusure di file,
2545 ecc.), che non potrebbero essere eseguite con un salto non-locale.}
2547 Tutto ciò può essere realizzato proprio con un salto non-locale; questo di
2548 norma viene realizzato salvando il contesto dello \itindex{stack}
2549 \textit{stack} nel punto in cui si vuole tornare in caso di errore, e
2550 ripristinandolo, in modo da tornare quando serve nella funzione da cui si era
2551 partiti. La funzione che permette di salvare il contesto dello
2552 \itindex{stack} \textit{stack} è \funcd{setjmp}, il cui prototipo è:
2556 \fdecl{int setjmp(jmp\_buf env)}
2557 \fdesc{Salva il contesto dello \textit{stack}.}
2559 {La funzione ritorna $0$ quando è chiamata direttamente ed un valore diverso
2560 da zero quando ritorna da una chiamata di \func{longjmp} che usa il contesto
2561 salvato in precedenza.}
2564 Quando si esegue la funzione il contesto corrente dello \itindex{stack}
2565 \textit{stack} viene salvato nell'argomento \param{env}, una variabile di tipo
2566 \type{jmp\_buf}\footnote{anche questo è un classico esempio di variabile di
2567 \index{tipo!opaco} \textsl{tipo opaco}.} che deve essere stata definita in
2568 precedenza. In genere le variabili di tipo \type{jmp\_buf} vengono definite
2569 come \index{variabili!globali} variabili globali in modo da poter essere viste
2570 in tutte le funzioni del programma.
2572 Quando viene eseguita direttamente la funzione ritorna sempre zero, un valore
2573 diverso da zero viene restituito solo quando il ritorno è dovuto ad una
2574 chiamata di \func{longjmp} in un'altra parte del programma che ripristina lo
2575 \itindex{stack} \textit{stack} effettuando il salto non-locale. Si tenga conto
2576 che il contesto salvato in \param{env} viene invalidato se la funzione che ha
2577 chiamato \func{setjmp} ritorna, nel qual caso un successivo uso di
2578 \func{longjmp} può comportare conseguenze imprevedibili (e di norma fatali)
2581 Come accennato per effettuare un salto non-locale ad un punto precedentemente
2582 stabilito con \func{setjmp} si usa la funzione \funcd{longjmp}; il suo
2587 \fdecl{void longjmp(jmp\_buf env, int val)}
2588 \fdesc{Ripristina il contesto dello stack.}
2590 {La funzione non ritorna.}
2593 La funzione ripristina il contesto dello \itindex{stack} \textit{stack}
2594 salvato da una chiamata a \func{setjmp} nell'argomento \param{env}. Dopo
2595 l'esecuzione della funzione il programma prosegue nel codice successivo alla
2596 chiamata della \func{setjmp} con cui si era salvato \param{env}, che
2597 restituirà il valore dell'argomento \param{val} invece di zero. Il valore
2598 dell'argomento \param{val} deve essere sempre diverso da zero, se si è
2599 specificato 0 sarà comunque restituito 1 al suo posto.
2601 In sostanza l'esecuzione di \func{longjmp} è analoga a quella di una
2602 istruzione \instruction{return}, solo che invece di ritornare alla riga
2603 successiva della funzione chiamante, il programma in questo caso ritorna alla
2604 posizione della relativa \func{setjmp}. L'altra differenza fondamentale con
2605 \instruction{return} è che il ritorno può essere effettuato anche attraverso
2606 diversi livelli di funzioni annidate.
2608 L'implementazione di queste funzioni comporta alcune restrizioni dato che esse
2609 interagiscono direttamente con la gestione dello \itindex{stack}
2610 \textit{stack} ed il funzionamento del compilatore stesso. In particolare
2611 \func{setjmp} è implementata con una macro, pertanto non si può cercare di
2612 ottenerne l'indirizzo, ed inoltre le chiamate a questa funzione sono sicure
2613 solo in uno dei seguenti casi:
2615 \item come espressione di controllo in un comando condizionale, di selezione o
2616 di iterazione (come \instruction{if}, \instruction{switch} o
2617 \instruction{while});
2618 \item come operando per un operatore di uguaglianza o confronto in una
2619 espressione di controllo di un comando condizionale, di selezione o di
2621 \item come operando per l'operatore di negazione (\code{!}) in una espressione
2622 di controllo di un comando condizionale, di selezione o di iterazione;
2623 \item come espressione a sé stante.
2626 In generale, dato che l'unica differenza fra la chiamata diretta e quella
2627 ottenuta nell'uscita con un \func{longjmp} è costituita dal valore di ritorno
2628 di \func{setjmp}, pertanto quest'ultima viene usualmente chiamata all'interno
2629 di un una istruzione \instruction{if} che permetta di distinguere i due casi.
2631 Uno dei punti critici dei salti non-locali è quello del valore delle
2632 variabili, ed in particolare quello delle \index{variabili!automatiche}
2633 variabili automatiche della funzione a cui si ritorna. In generale le
2634 \index{variabili!globali} variabili globali e \index{variabili!statiche}
2635 statiche mantengono i valori che avevano al momento della chiamata di
2636 \func{longjmp}, ma quelli delle \index{variabili!automatiche} variabili
2637 automatiche (o di quelle dichiarate \direct{register}) sono in genere
2640 Quello che succede infatti è che i valori delle variabili che sono tenute in
2641 memoria manterranno il valore avuto al momento della chiamata di
2642 \func{longjmp}, mentre quelli tenuti nei registri del processore (che nella
2643 chiamata ad un'altra funzione vengono salvati nel contesto nello
2644 \itindex{stack} \textit{stack}) torneranno al valore avuto al momento della
2645 chiamata di \func{setjmp}; per questo quando si vuole avere un comportamento
2646 coerente si può bloccare l'ottimizzazione che porta le variabili nei registri
2647 dichiarandole tutte come \direct{volatile}.\footnote{la direttiva
2648 \direct{volatile} informa il compilatore che la variabile che è dichiarata
2649 può essere modificata, durante l'esecuzione del nostro, da altri programmi.
2650 Per questo motivo occorre dire al compilatore che non deve essere mai
2651 utilizzata l'ottimizzazione per cui quanto opportuno essa viene mantenuta in
2652 un registro, poiché in questo modo si perderebbero le eventuali modifiche
2653 fatte dagli altri programmi (che avvengono solo in una copia posta in
2656 \index{salto~non-locale|)}
2659 \subsection{La \textit{endianness}}
2660 \label{sec:sock_endianness}
2662 \itindbeg{endianness}
2664 Un altro dei problemi di programmazione che può dar luogo ad effetti
2665 imprevisti è quello relativo alla cosiddetta \textit{endianness}. Questa è una
2666 caratteristica generale dell'architettura hardware di un computer che dipende
2667 dal fatto che la rappresentazione di un numero binario può essere fatta in due
2668 modi, chiamati rispettivamente \textit{big endian} e \textit{little endian} a
2669 seconda di come i singoli bit vengono aggregati per formare le variabili
2670 intere (ed in genere in diretta corrispondenza a come sono poi in realtà
2671 cablati sui bus interni del computer).
2673 \begin{figure}[!htb]
2674 \centering \includegraphics[height=3cm]{img/endianness}
2675 \caption{Schema della disposizione dei dati in memoria a seconda della
2676 \textit{endianness}.}
2677 \label{fig:sock_endianness}
2680 Per capire meglio il problema si consideri un intero a 32 bit scritto in una
2681 locazione di memoria posta ad un certo indirizzo. Come illustrato in
2682 fig.~\ref{fig:sock_endianness} i singoli bit possono essere disposti in memoria
2683 in due modi: a partire dal più significativo o a partire dal meno
2684 significativo. Così nel primo caso si troverà il byte che contiene i bit più
2685 significativi all'indirizzo menzionato e il byte con i bit meno significativi
2686 nell'indirizzo successivo; questo ordinamento è detto \textit{big endian},
2687 dato che si trova per prima la parte più grande. Il caso opposto, in cui si
2688 parte dal bit meno significativo è detto per lo stesso motivo \textit{little
2691 Si può allora verificare quale tipo di \textit{endianness} usa il proprio
2692 computer con un programma elementare che si limita ad assegnare un valore ad
2693 una variabile per poi ristamparne il contenuto leggendolo un byte alla volta.
2694 Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
2695 allora se lo eseguiamo su un normale PC compatibile, che è \textit{little
2696 endian} otterremo qualcosa del tipo:
2698 [piccardi@gont sources]$ ./endtest
2702 Using value ABCDEF01
2708 mentre su un vecchio Macintosh con PowerPC, che è \textit{big endian} avremo
2711 piccardi@anarres:~/gapil/sources$ ./endtest
2715 Using value ABCDEF01
2722 L'attenzione alla \textit{endianness} nella programmazione è importante, perché
2723 se si fanno assunzioni relative alla propria architettura non è detto che
2724 queste restino valide su un'altra architettura. Inoltre, come vedremo ad
2725 esempio in sez.~\ref{sec:sock_addr_func}, si possono avere problemi quando ci
2726 si trova a usare valori di un formato con una infrastruttura che ne usa
2729 La \textit{endianness} di un computer dipende essenzialmente dalla architettura
2730 hardware usata; Intel e Digital usano il \textit{little endian}, Motorola,
2731 IBM, Sun (sostanzialmente tutti gli altri) usano il \textit{big endian}. Il
2732 formato dei dati contenuti nelle intestazioni dei protocolli di rete (il
2733 cosiddetto \textit{network order}) è anch'esso \textit{big endian}; altri
2734 esempi di uso di questi due diversi formati sono quello del bus PCI, che è
2735 \textit{little endian}, o quello del bus VME che è \textit{big endian}.
2737 Esistono poi anche dei processori che possono scegliere il tipo di formato
2738 all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
2739 da un tipo di ordinamento all'altro con una specifica istruzione. In ogni caso
2740 in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
2741 in genere resta sempre lo stesso,\footnote{su architettura PowerPC è possibile
2742 cambiarlo, si veda sez.~\ref{sec:process_prctl}.} anche quando il processore
2743 permetterebbe di eseguire questi cambiamenti.
2745 \begin{figure}[!htbp]
2746 \footnotesize \centering
2747 \begin{minipage}[c]{\codesamplewidth}
2748 \includecodesample{listati/endian.c}
2751 \caption{La funzione \samplefunc{endian}, usata per controllare il tipo di
2752 architettura della macchina.}
2753 \label{fig:sock_endian_code}
2756 Per controllare quale tipo di ordinamento si ha sul proprio computer si è
2757 scritta una piccola funzione di controllo, il cui codice è riportato
2758 fig.~\ref{fig:sock_endian_code}, che restituisce un valore nullo (falso) se
2759 l'architettura è \textit{big endian} ed uno non nullo (vero) se l'architettura
2760 è \textit{little endian}.
2762 Come si vede la funzione è molto semplice, e si limita, una volta assegnato
2763 (\texttt{\small 9}) un valore di test pari a \texttt{0xABCD} ad una variabile
2764 di tipo \ctyp{short} (cioè a 16 bit), a ricostruirne una copia byte a byte.
2765 Per questo prima (\texttt{\small 10}) si definisce il puntatore \var{ptr} per
2766 accedere al contenuto della prima variabile, ed infine calcola (\texttt{\small
2767 11}) il valore della seconda assumendo che il primo byte sia quello meno
2768 significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianness}, che sia
2769 \textit{little endian}). Infine la funzione restituisce (\texttt{\small 12})
2770 il valore del confronto delle due variabili.
2772 In generale non ci si deve preoccupare della \textit{endianness} all'interno
2773 di un programma fintanto che questo non deve generare o manipolare dei dati
2774 che sono scambiati con altre macchine, ad esempio tramite via rete o tramite
2775 dei file binari. Nel primo caso la scelta è già stata fatta nella
2776 standardizzazione dei protocolli, che hanno adottato il \textit{big endian}
2777 (che viene detto anche per questo \textit{network order} e vedremo in
2778 sez.~\ref{sec:sock_func_ord} le funzioni di conversione che devono essere
2781 Nel secondo caso occorre sapere quale \textit{endianness} è stata usata nei
2782 dati memorizzati sul file e tenerne conto nella rilettura e nella
2783 manipolazione e relativa modifica (e salvataggio). La gran parte dei formati
2784 binari standardizzati specificano quale \textit{endianness} viene utilizzata e
2785 basterà identificare qual'è, se se ne deve definire uno per i propri scopi
2786 basterà scegliere una volta per tutte quale usare e attenersi alla scelta.
2788 \itindend{endianness}
2791 % LocalWords: like exec kernel thread main ld linux static linker char envp Gb
2792 % LocalWords: sez POSIX exit system call cap abort shell diff errno stdlib int
2793 % LocalWords: SUCCESS FAILURE void atexit stream fclose unistd descriptor init
2794 % LocalWords: SIGCHLD wait function glibc SunOS arg argp execve fig high kb Mb
2795 % LocalWords: memory alpha swap table printf Unit MMU paging fault SIGSEGV BSS
2796 % LocalWords: multitasking text segment NULL Block Started Symbol fill black
2797 % LocalWords: heap stack calling convention size malloc calloc realloc nmemb
2798 % LocalWords: ENOMEM ptr uClib cfree error leak smartpointers hook Dmalloc brk
2799 % LocalWords: Gray Watson Electric Fence Bruce Perens sbrk longjmp SUSv BSD ap
2800 % LocalWords: ptrdiff increment locking lock copy write capabilities IPC mlock
2801 % LocalWords: capability MEMLOCK limits getpagesize RLIMIT munlock sys const
2802 % LocalWords: addr len EINVAL EPERM mlockall munlockall flags l'OR CURRENT IFS
2803 % LocalWords: argc argv parsing questofile txt getopt optstring switch optarg
2804 % LocalWords: optind opterr optopt ForkTest POSIXLY CORRECT long options NdA
2805 % LocalWords: option parameter list environ PATH HOME XPG tab LOGNAME LANG PWD
2806 % LocalWords: TERM PAGER TMPDIR getenv name SVr setenv unsetenv putenv opz gcc
2807 % LocalWords: clearenv libc value overwrite string reference result argument
2808 % LocalWords: socket variadic ellipsis header stdarg execl self promoting last
2809 % LocalWords: float double short register type dest src extern setjmp jmp buf
2810 % LocalWords: env return if while Di page cdecl rectangle node anchor west PS
2811 % LocalWords: environment rounded corners dashed south width height draw east
2812 % LocalWords: exithandler handler violation inline SOURCE SVID XOPEN mincore
2813 % LocalWords: length unsigned vec EFAULT EAGAIN dell'I memalign valloc posix
2814 % LocalWords: boundary memptr alignment sizeof overrun mcheck abortfn enum big
2815 % LocalWords: mprobe DISABLED HEAD TAIL touch right emacs OSTYPE endianness IBM
2816 % LocalWords: endian little endtest Macintosh PowerPC Intel Digital Motorola
2817 % LocalWords: Sun order VME loader Windows DLL shared objects PRELOAD termios
2818 % LocalWords: is to LC SIG str mem wcs assert ctype dirent fcntl signal stdio
2819 % LocalWords: times library utmp syscall number Filesystem Hierarchy pathname
2820 % LocalWords: context assembler sysconf fork Dinamic huge segmentation program
2821 % LocalWords: break store Using
2823 %%% Local Variables:
2825 %%% TeX-master: "gapil"