3 %% Copyright (C) 2000-2015 by 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
313 % Altro materiale al riguardo http://lwn.net/Articles/615809/
314 % http://man7.org/linux/man-pages/man7/vdso.7.html
316 Inoltre alcune \textit{system call} sono state modificate nel corso degli anni
317 con lo sviluppo del kernel per aggiungere ad esempio funzionalità in forma di
318 nuovi argomenti, o per consolidare diverse varianti in una interfaccia
319 generica. Per questo motivo dovendo utilizzare una \textit{system call} è
320 sempre preferibile usare l'interfaccia fornita dalla \textsl{glibc}, che si
321 cura di mantenere una uniformità chiamando le versioni più aggiornate.
323 Ci sono alcuni casi però in cui può essere necessario evitare questa
324 associazione, e lavorare a basso livello con una specifica versione, oppure si
325 può voler utilizzare una \textit{system call} che non è stata ancora associata
326 ad una funzione di libreria. In tal caso, per evitare di dover effettuare
327 esplicitamente le operazioni di preparazione citate, all'interno della
328 \textsl{glibc} è fornita una specifica funzione, \funcd{syscall}, che consente
329 eseguire direttamente una \textit{system call}; il suo prototipo, accessibile
330 se si è definita la macro \macro{\_GNU\_SOURCE}, è:
334 \fhead{sys/syscall.h}
335 \fdecl{int syscall(int number, ...)}
336 \fdesc{Esegue la \textit{system call} indicata da \param{number}.}
338 {La funzione ritorna un intero dipendente dalla \textit{system call} invocata,
339 in generale $0$ indica il successo ed un valore negativo un errore.}
342 La funzione richiede come primo argomento il numero della \textit{system call}
343 da invocare, seguita dagli argomenti da passare alla stessa, che ovviamente
344 dipendono da quest'ultima, e restituisce il codice di ritorno della
345 \textit{system call} invocata. In generale un valore nullo indica il successo
346 ed un valore negativo è un codice di errore che poi viene memorizzato nella
347 variabile \var{errno} (sulla gestione degli errori torneremo in dettaglio in
348 sez.~\ref{sec:sys_errors}).
350 Il valore di \param{number} dipende sia dalla versione di kernel che
351 dall'architettura,\footnote{in genere le vecchie \textit{system call} non
352 vengono eliminate e se ne aggiungono di nuove con nuovi numeri.} ma
353 ciascuna \textit{system call} viene in genere identificata da una costante
354 nella forma \texttt{SYS\_*} dove al prefisso viene aggiunto il nome che spesso
355 corrisponde anche alla omonima funzione di libreria. Queste costanti sono
356 definite nel file \headfile{sys/syscall.h}, ma si possono anche usare
357 direttamente valori numerici.
360 \subsection{La terminazione di un programma}
361 \label{sec:proc_conclusion}
363 Normalmente un programma conclude la sua esecuzione quando si fa ritornare la
364 funzione \code{main}, si usa cioè l'istruzione \instruction{return} del
365 linguaggio C all'interno della stessa, o se si richiede esplicitamente la
366 chiusura invocando direttamente la funzione \func{exit}. Queste due modalità
367 sono assolutamente equivalenti, dato che \func{exit} viene chiamata in maniera
368 trasparente anche quando \code{main} ritorna, passandogli come argomento il
369 valore di ritorno (che essendo .
371 La funzione \funcd{exit}, che è completamente generale, essendo definita dallo
372 standard ANSI C, è quella che deve essere invocata per una terminazione
373 ``\textit{normale}'', il suo prototipo è:
377 \fdecl{void exit(int status)}
378 \fdesc{Causa la conclusione ordinaria del programma.}
380 {La funzione non ritorna, il processo viene terminato.}
383 La funzione è pensata per eseguire una conclusione pulita di un programma che
384 usi la libreria standard del C; essa esegue tutte le funzioni che sono state
385 registrate con \func{atexit} e \func{on\_exit} (vedi
386 sez.~\ref{sec:proc_atexit}), chiude tutti gli \textit{stream} (vedi
387 sez.~\ref{sec:file_stream}) effettuando il salvataggio dei dati sospesi
388 (chiamando \func{fclose}, vedi sez.~\ref{sec:file_fopen}), infine passa il
389 controllo al kernel chiamando la \textit{system call} \func{\_exit} (che
390 vedremo a breve) che completa la terminazione del processo.
392 \itindbeg{exit~status}
394 Il valore dell'argomento \param{status} o il valore di ritorno di \code{main},
395 costituisce quello che viene chiamato lo \textsl{stato di uscita}
396 (l'\textit{exit status}) del processo. In generale si usa questo valore per
397 fornire al processo padre (come vedremo in sez.~\ref{sec:proc_wait}) delle
398 informazioni generiche sulla riuscita o il fallimento del programma appena
401 Anche se l'argomento \param{status} (ed il valore di ritorno di \code{main})
402 sono numeri interi di tipo \ctyp{int}, si deve tener presente che il valore
403 dello stato di uscita viene comunque troncato ad 8 bit,
404 per cui deve essere sempre compreso fra 0 e 255. Si tenga presente che se si
405 raggiunge la fine della funzione \code{main} senza ritornare esplicitamente si
406 ha un valore di uscita indefinito, è pertanto consigliabile di concludere
407 sempre in maniera esplicita detta funzione.
409 Non esiste un valore significato intrinseco della stato di uscita, ma una
410 convenzione in uso pressoché universale è quella di restituire 0 in caso di
411 successo e 1 in caso di fallimento. Una eccezione a questa convenzione è per i
412 programmi che effettuano dei confronti (come \cmd{diff}), che usano 0 per
413 indicare la corrispondenza, 1 per indicare la non corrispondenza e 2 per
414 indicare l'incapacità di effettuare il confronto. Un'altra convenzione riserva
415 i valori da 128 a 256 per usi speciali: ad esempio 128 viene usato per
416 indicare l'incapacità di eseguire un altro programma in un
417 sottoprocesso. Benché le convenzioni citate non siano seguite universalmente è
418 una buona idea tenerle presenti ed adottarle a seconda dei casi.
420 Si tenga presente inoltre che non è una buona idea usare eventuali codici di
421 errore restituiti nella variabile \var{errno} (vedi sez.~\ref{sec:sys_errors})
422 come \textit{exit status}. In generale infatti non ci si cura del valore dello
423 stato di uscita di un processo se non per vedere se è diverso da zero, come
424 indicazione di un qualche errore. Dato che viene troncato ad 8 bit utilizzare
425 un intero di valore generico può comportare il rischio, qualora si vada ad
426 usare un multiplo di 256, di avere uno stato di uscita uguale a zero, che
427 verrebbe interpretato come un successo.
429 Per questo motivo in \headfile{stdlib.h} sono definite, seguendo lo standard
430 POSIX, le due costanti \const{EXIT\_SUCCESS} e \const{EXIT\_FAILURE}, da usare
431 sempre per specificare lo stato di uscita di un processo. Su Linux, ed in
432 generale in qualunque sistema POSIX, ad esse sono assegnati rispettivamente i
435 \itindend{exit~status}
437 Una forma alternativa per effettuare una terminazione esplicita di un
438 programma è quella di chiamare direttamente la \textit{system call}
439 \funcd{\_exit},\footnote{la stessa è definita anche come \funcd{\_Exit} in
440 \headfile{stdlib.h}.} che restituisce il controllo direttamente al kernel,
441 concludendo immediatamente il processo, il suo prototipo è:
443 \begin{funcproto}{ \fhead{unistd.h} \fdecl{void \_exit(int status)}
444 \fdesc{Causa la conclusione immediata del programma.} } {La funzione non
445 ritorna, il processo viene terminato.}
448 La funzione termina immediatamente il processo e le eventuali funzioni
449 registrate con \func{atexit} e \func{on\_exit} non vengono eseguite. La
450 funzione chiude tutti i file descriptor appartenenti al processo, cosa che
451 però non comporta il salvataggio dei dati eventualmente presenti nei buffer
452 degli \textit{stream}, (torneremo sulle due interfacce dei file in
453 sez.~\ref{sec:file_unix_interface} e
454 sez.~\ref{sec:files_std_interface}). Infine fa sì che ogni figlio del processo
455 sia adottato da \cmd{init} (vedi sez.~\ref{sec:proc_termination}), manda un
456 segnale \signal{SIGCHLD} al processo padre (vedi
457 sez.~\ref{sec:sig_job_control}) e ritorna lo stato di uscita specificato
458 in \param{status} che può essere raccolto usando la funzione \func{wait} (vedi
459 sez.~\ref{sec:proc_wait}).
461 Si tenga presente infine che oltre alla conclusione ``\textsl{normale}''
462 appena illustrata esiste anche la possibilità di una conclusione
463 ``\textsl{anomala}'' del programma a causa della ricezione di un segnale
464 (tratteremo i segnali in cap.~\ref{cha:signals}) o della chiamata alla
465 funzione \func{abort}; torneremo su questo in sez.~\ref{sec:proc_termination}.
468 \subsection{Esecuzione di funzioni preliminari all'uscita}
469 \label{sec:proc_atexit}
471 Un'esigenza comune che si incontra è quella di dover effettuare una serie di
472 operazioni di pulizia (ad esempio salvare dei dati, ripristinare delle
473 impostazioni, eliminare dei file temporanei, ecc.) prima della conclusione di
474 un programma. In genere queste operazioni vengono fatte in un'apposita sezione
475 del programma, ma quando si realizza una libreria diventa antipatico dover
476 richiedere una chiamata esplicita ad una funzione di pulizia al programmatore
479 È invece molto meno soggetto ad errori, e completamente trasparente
480 all'utente, avere la possibilità di fare effettuare automaticamente la
481 chiamata ad una funzione che effettui tali operazioni all'uscita dal
482 programma. A questo scopo lo standard ANSI C prevede la possibilità di
483 registrare un certo numero di funzioni che verranno eseguite all'uscita dal
484 programma,\footnote{nel caso di \func{atexit} lo standard POSIX.1-2001
485 richiede che siano registrabili almeno \const{ATEXIT\_MAX} funzioni (il
486 valore può essere ottenuto con \func{sysconf}, vedi
487 sez.~\ref{sec:sys_limits}).} sia per la chiamata ad \func{exit} che per il
488 ritorno di \code{main}. La prima funzione che si può utilizzare a tal fine è
489 \funcd{atexit}, il cui prototipo è:
493 \fdecl{int atexit(void (*function)(void))}
494 \fdesc{Registra la funzione \param{function} per la chiamata all'uscita
497 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, \var{errno}
498 non viene modificata.}
501 La funzione richiede come argomento \param{function} l'indirizzo di una
502 opportuna funzione di pulizia da chiamare all'uscita del programma, che non
503 deve prendere argomenti e non deve ritornare niente. In sostanza deve la
504 funzione di pulizia dovrà essere definita come \code{void function(void)}.
506 Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che le
507 \acr{glibc} includono per compatibilità con SunOS ma che non è detto sia
508 definita su altri sistemi,\footnote{non essendo prevista dallo standard POSIX
509 è in genere preferibile evitarne l'uso.} il suo prototipo è:
513 \fdecl{int on\_exit(void (*function)(int, void *), void *arg))}
514 \fdesc{Registra la funzione \param{function} per la chiamata all'uscita dal
517 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, \var{errno}
518 non viene modificata.}
521 In questo caso la funzione da chiamare all'uscita prende i due argomenti
522 specificati nel prototipo, un intero ed un puntatore; dovrà cioè essere
523 definita come \code{void function(int status, void *argp)}. Il primo argomento
524 sarà inizializzato allo stato di uscita con cui è stata chiamata \func{exit}
525 ed il secondo al puntatore \param{arg} passato come secondo argomento di
526 \func{on\_exit}. Così diventa possibile passare dei dati alla funzione di
529 Nella sequenza di chiusura tutte le funzioni registrate verranno chiamate in
530 ordine inverso rispetto a quello di registrazione, ed una stessa funzione
531 registrata più volte sarà chiamata più volte. Siccome entrambe le funzioni
532 \func{atexit} e \func{on\_exit} fanno riferimento alla stessa lista, l'ordine
533 di esecuzione sarà riferito alla registrazione in quanto tale,
534 indipendentemente dalla funzione usata per farla.
536 Una volta completata l'esecuzione di tutte le funzioni registrate verranno
537 chiusi tutti gli \textit{stream} aperti ed infine verrà chiamata \func{\_exit}
538 per la terminazione del programma. Questa è la sequenza ordinaria, eseguita a
539 meno che una delle funzioni registrate non esegua al suo interno
540 \func{\_exit}, nel qual caso la terminazione del programma sarà immediata ed
541 anche le successive funzioni registrate non saranno invocate.
543 Se invece all'interno di una delle funzioni registrate si chiama un'altra
544 volta \func{exit} lo standard POSIX.1-2001 prescrive un comportamento
545 indefinito, con la possibilità (che su Linux comunque non c'è) di una
546 ripetizione infinita. Pertanto questa eventualità è da evitare nel modo più
547 assoluto. Una altro comportamento indefinito si può avere se si termina
548 l'esecuzione di una delle funzioni registrate con \func{longjmp} (vedi
549 sez.~\ref{sec:proc_longjmp}).
551 Si tenga presente infine che in caso di terminazione anomala di un processo
552 (ad esempio a causa di un segnale) nessuna delle funzioni registrate verrà
553 eseguita e che se invece si crea un nuovo processo con \func{fork} (vedi
554 sez.~\ref{sec:proc_fork}) questo manterrà tutte le funzioni già registrate.
557 \subsection{Un riepilogo}
558 \label{sec:proc_term_conclusion}
560 Data l'importanza dell'argomento è opportuno un piccolo riepilogo dei fatti
561 essenziali relativi alla esecuzione di un programma. Il primo punto da
562 sottolineare è che in un sistema unix-like l'unico modo in cui un programma
563 può essere eseguito dal kernel è attraverso la chiamata alla \textit{system
564 call} \func{execve}, sia direttamente che attraverso una delle funzioni
565 della famiglia \func{exec} che ne semplificano l'uso (vedi
566 sez.~\ref{sec:proc_exec}).
568 Allo stesso modo l'unico modo in cui un programma può concludere
569 volontariamente la propria esecuzione è attraverso una chiamata alla
570 \textit{system call} \func{\_exit}, sia che questa venga fatta esplicitamente,
571 o in maniera indiretta attraverso l'uso di \func{exit} o il ritorno di
574 Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
575 normalmente un programma è riportato in fig.~\ref{fig:proc_prog_start_stop}.
579 % \includegraphics[width=9cm]{img/proc_beginend}
580 \begin{tikzpicture}[>=stealth]
581 \filldraw[fill=black!35] (-0.3,0) rectangle (12,1);
582 \draw(5.5,0.5) node {\large{\textsf{kernel}}};
584 \filldraw[fill=black!15] (1.5,2) rectangle (4,3);
585 \draw (2.75,2.5) node {\texttt{ld-linux.so}};
586 \draw [->] (2.75,1) -- (2.75,2);
587 \draw (2.75,1.5) node [anchor=west]{\texttt{execve}};
589 \filldraw[fill=black!15,rounded corners] (1.5,4) rectangle (4,5);
590 \draw (2.75,4.5) node {\texttt{main}};
592 \draw [<->, dashed] (2.75,3) -- (2.75,4);
593 \draw [->] (1.5,4.5) -- (0.3,4.5) -- (0.3,1);
594 \draw (0.9,4.5) node [anchor=south] {\texttt{\_exit}};
596 \filldraw[fill=black!15,rounded corners] (1.5,6) rectangle (4,7);
597 \draw (2.75,6.5) node {\texttt{funzione}};
599 \draw [<->, dashed] (2.75,5) -- (2.75,6);
600 \draw [->] (1.5,6.5) -- (0.05,6.5) -- (0.05,1);
601 \draw (0.9,6.5) node [anchor=south] {\texttt{\_exit}};
603 \draw (6.75,4.5) node (exit) [rectangle,fill=black!15,minimum width=2.5cm,minimum height=1cm,rounded corners, draw]{\texttt{exit}};
605 \draw[->] (4,6.5) -- node[anchor=south west]{\texttt{exit}} (exit);
606 \draw[->] (4,4.5) -- node[anchor=south]{\texttt{exit}} (exit);
607 \draw[->] (exit) -- node[anchor=east]{\texttt{\_exit}}(6.75,1);
609 \draw (10,4.5) node (exithandler1) [rectangle,fill=black!15,rounded corners, draw]{\textsf{exit handler}};
610 \draw (10,5.5) node (exithandler2) [rectangle,fill=black!15,rounded corners, draw]{\textsf{exit handler}};
611 \draw (10,3.5) node (stream) [rectangle,fill=black!15,rounded corners, draw]{\textsf{chiusura stream}};
613 \draw[<->, dashed] (exithandler1) -- (exit);
614 \draw[<->, dashed] (exithandler2) -- (exit);
615 \draw[<->, dashed] (stream) -- (exit);
617 \caption{Schema dell'avvio e della conclusione di un programma.}
618 \label{fig:proc_prog_start_stop}
621 Si ricordi infine che un programma può anche essere interrotto dall'esterno
622 attraverso l'uso di un segnale (modalità di conclusione non mostrata in
623 fig.~\ref{fig:proc_prog_start_stop}); tratteremo nei dettagli i segnali e la
624 loro gestione nel capitolo \ref{cha:signals}.
628 \section{I processi e l'uso della memoria}
629 \label{sec:proc_memory}
631 Una delle risorse più importanti che ciascun processo ha a disposizione è la
632 memoria, e la gestione della memoria è appunto uno degli aspetti più complessi
633 di un sistema unix-like. In questa sezione, dopo una breve introduzione ai
634 concetti di base, esamineremo come la memoria viene vista da parte di un
635 programma in esecuzione, e le varie funzioni utilizzabili per la sua gestione.
638 \subsection{I concetti generali}
639 \label{sec:proc_mem_gen}
641 \index{memoria~virtuale|(}
643 Ci sono vari modi in cui i sistemi operativi organizzano la memoria, ed i
644 dettagli di basso livello dipendono spesso in maniera diretta
645 dall'architettura dell'hardware, ma quello più tipico, usato dai sistemi
646 unix-like come Linux è la cosiddetta \textsl{memoria virtuale} che consiste
647 nell'assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare,
648 in cui gli indirizzi vanno da zero ad un qualche valore massimo.\footnote{nel
649 caso di Linux fino al kernel 2.2 detto massimo era, per macchine a 32bit, di
650 2Gb. Con il kernel 2.4 ed il supporto per la \textit{high-memory} il limite
651 è stato esteso anche per macchine a 32 bit.} Come accennato nel
652 cap.~\ref{cha:intro_unix} questo spazio di indirizzi è virtuale e non
653 corrisponde all'effettiva posizione dei dati nella RAM del computer. In
654 generale detto spazio non è neppure continuo, cioè non tutti gli indirizzi
655 possibili sono utilizzabili, e quelli usabili non sono necessariamente
658 Per la gestione da parte del kernel la memoria viene divisa in pagine di
659 dimensione fissa. Inizialmente queste pagine erano di 4kb sulle macchine a 32
660 bit e di 8kb sulle alpha. Con le versioni più recenti del kernel è possibile
661 anche utilizzare pagine di dimensioni maggiori (di 4Mb, dette
662 \itindex{huge~page} \textit{huge page}), per sistemi con grandi quantitativi
663 di memoria in cui l'uso di pagine troppo piccole comporta una perdita di
664 prestazioni. In alcuni sistemi la costante \const{PAGE\_SIZE}, definita in
665 \headfile{limits.h}, indica la dimensione di una pagina in byte, con Linux
666 questo non avviene e per ottenere questa dimensione si deve ricorrere alla
667 funzione \func{getpagesize} (vedi sez.~\ref{sec:sys_memory_res}).
669 Ciascuna pagina di memoria nello spazio di indirizzi virtuale è associata ad
670 un supporto che può essere una pagina di memoria reale o ad un dispositivo di
671 stoccaggio secondario (come lo spazio disco riservato alla \textit{swap}, o i
672 file che contengono il codice). Per ciascun processo il kernel si cura di
673 mantenere un mappa di queste corrispondenze nella cosiddetta
674 \itindex{page~table} \textit{page table}.\footnote{questa è una
675 semplificazione brutale, il meccanismo è molto più complesso; una buona
676 trattazione di come Linux gestisce la memoria virtuale si trova su
679 Una stessa pagina di memoria reale può fare da supporto a diverse pagine di
680 memoria virtuale appartenenti a processi diversi, come accade in genere per le
681 pagine che contengono il codice delle librerie condivise. Ad esempio il codice
682 della funzione \func{printf} starà su una sola pagina di memoria reale che
683 farà da supporto a tutte le pagine di memoria virtuale di tutti i processi che
684 hanno detta funzione nel loro codice.
686 \index{paginazione|(}
688 La corrispondenza fra le pagine della memoria virtuale di un processo e quelle
689 della memoria fisica della macchina viene gestita in maniera trasparente dal
690 kernel.\footnote{in genere con l'ausilio dell'hardware di gestione della
691 memoria (la \textit{Memory Management Unit} del processore), con i kernel
692 della serie 2.6 è comunque diventato possibile utilizzare Linux anche su
693 architetture che non dispongono di una MMU.} Poiché in genere la memoria
694 fisica è solo una piccola frazione della memoria virtuale, è necessario un
695 meccanismo che permetta di trasferire le pagine che servono dal supporto su
696 cui si trovano in memoria, eliminando quelle che non servono. Questo
697 meccanismo è detto \textsl{paginazione} (o \textit{paging}), ed è uno dei
698 compiti principali del kernel.
700 Quando un processo cerca di accedere ad una pagina che non è nella memoria
701 reale, avviene quello che viene chiamato un \itindex{page~fault} \textit{page
702 fault}; la gestione della memoria genera un'interruzione e passa il
703 controllo al kernel il quale sospende il processo e si incarica di mettere in
704 RAM la pagina richiesta, effettuando tutte le operazioni necessarie per
705 reperire lo spazio necessario, per poi restituire il controllo al processo.
707 Dal punto di vista di un processo questo meccanismo è completamente
708 trasparente, e tutto avviene come se tutte le pagine fossero sempre
709 disponibili in memoria. L'unica differenza avvertibile è quella dei tempi di
710 esecuzione, che passano dai pochi nanosecondi necessari per l'accesso in RAM
711 se la pagina è direttamente disponibile, a tempi estremamente più lunghi,
712 dovuti all'intervento del kernel, qualora sia necessario reperire pagine
713 riposte nella \textit{swap}.
715 Normalmente questo è il prezzo da pagare per avere un multitasking reale, ed
716 in genere il sistema è molto efficiente in questo lavoro; quando però ci siano
717 esigenze specifiche di prestazioni è possibile usare delle funzioni che
718 permettono di bloccare il meccanismo della paginazione e mantenere fisse delle
719 pagine in memoria (vedi sez.~\ref{sec:proc_mem_lock}).
721 \index{paginazione|)}
722 \index{memoria~virtuale|)}
724 \subsection{La struttura della memoria di un processo}
725 \label{sec:proc_mem_layout}
727 Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
728 una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
729 tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
730 commette quando si è manipolato male un puntatore e genera quella che viene
731 chiamata una \itindex{segment~violation} \textit{segment violation}. Se si
732 tenta cioè di leggere o scrivere con un indirizzo per il quale non esiste
733 un'associazione nella memoria virtuale, il kernel risponde al relativo
734 \itindex{page~fault} \textit{page fault} mandando un segnale \signal{SIGSEGV}
735 al processo, che normalmente ne causa la terminazione immediata.
737 È pertanto importante capire come viene strutturata la memoria virtuale di un
738 processo. Essa viene divisa in \textsl{segmenti}, cioè un insieme contiguo di
739 indirizzi virtuali ai quali il processo può accedere. Solitamente un
740 programma C viene suddiviso nei seguenti segmenti:
742 \item Il \index{segmento!testo} segmento di testo o \textit{text segment}.
743 Contiene il codice del programma, delle funzioni di librerie da esso
744 utilizzate, e le costanti. Normalmente viene condiviso fra tutti i processi
745 che eseguono lo stesso programma e nel caso delle librerie anche da processi
746 che eseguono altri programmi.
748 Quando l'architettura hardware lo supporta viene marcato in sola lettura per
749 evitare sovrascritture accidentali (o maliziose) che ne modifichino le
750 istruzioni. Viene allocato da \func{execve} all'avvio del programma e resta
751 invariato per tutto il tempo dell'esecuzione.
753 \item Il \index{segmento!dati} segmento dei dati o \textit{data
754 segment}. Contiene tutti i dati del programma, come le
755 \index{variabili!globali} variabili globali, cioè quelle definite al di
756 fuori di tutte le funzioni che compongono il programma, e le
757 \index{variabili!statiche} variabili statiche, cioè quelle dichiarate con
758 l'attributo \direct{static},\footnote{la direttiva \direct{static} indica al
759 compilatore C che una variabile così dichiarata all'interno di una
760 funzione deve essere mantenuta staticamente in memoria (nel
761 \index{segmento!dati} segmento dati appunto); questo significa che la
762 variabile verrà inizializzata una sola volta alla prima invocazione della
763 funzione e che il suo valore sarà mantenuto fra diverse esecuzioni della
764 funzione stessa, la differenza con una \index{variabili!globali} variabile
765 globale è che essa può essere vista solo all'interno della funzione in cui
766 è dichiarata.} e la memoria allocata dinamicamente. Di norma è diviso in
770 \item Il segmento dei dati inizializzati, che contiene le variabili il cui
771 valore è stato assegnato esplicitamente. Ad esempio se si definisce:
772 \includecodesnip{listati/pi.c}
773 questo valore sarà immagazzinato in questo segmento. La memoria di questo
774 segmento viene preallocata all'avvio del programma e inizializzata ai valori
776 \item Il segmento dei dati non inizializzati, che contiene le variabili il
777 cui valore non è stato assegnato esplicitamente. Ad esempio se si
779 \includecodesnip{listati/vect.c}
780 questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
781 allocato all'avvio, e tutte le variabili vengono inizializzate a zero (ed
782 i puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
783 variabili che vanno nel \index{segmento!dati} segmento dati, e non è
784 affatto vero in generale.} Storicamente questa seconda parte del
785 \index{segmento!dati} segmento dati viene chiamata BSS (da \textit{Block
786 Started by Symbol}). La sua dimensione è fissa.
787 \item Lo \itindex{heap} \textit{heap}, detto anche \textit{free
788 store}. Tecnicamente lo si può considerare l'estensione del segmento dei
789 dati non inizializzati, a cui di solito è posto giusto di seguito. Questo
790 è il segmento che viene utilizzato per l'allocazione dinamica della
791 memoria. Lo \textit{heap} può essere ridimensionato allargandolo e
792 restringendolo per allocare e disallocare la memoria dinamica con le
793 apposite funzioni (vedi sez.~\ref{sec:proc_mem_alloc}), ma il suo limite
794 inferiore, quello adiacente al segmento dei dati non inizializzati, ha una
798 \item Il segmento di \itindex{stack} \textit{stack}, che contiene quello che
799 viene chiamato \textit{stack} del programma. Tutte le volte che si effettua
800 una chiamata ad una funzione è qui che viene salvato l'indirizzo di ritorno
801 e le informazioni dello stato del chiamante (come il contenuto di alcuni
802 registri della CPU), poi la funzione chiamata alloca qui lo spazio per le
803 sue variabili locali. Tutti questi dati vengono \textit{impilati} (da questo
804 viene il nome \itindex{stack} \textit{stack}) in sequenza uno sull'altro; in
805 questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
806 della funzione lo spazio è automaticamente rilasciato e
807 ``\textsl{ripulito}''.\footnote{il compilatore si incarica di generare
808 automaticamente il codice necessario, seguendo quella che viene chiamata
809 una \textit{calling convention}; quella standard usata con il C ed il C++
810 è detta \textit{cdecl} e prevede che gli argomenti siano caricati nello
811 \textit{stack} dal chiamante da destra a sinistra, e che sia il chiamante
812 stesso ad eseguire la ripulitura dello \textit{stack} al ritorno della
813 funzione, se ne possono però utilizzare di alternative (ad esempio nel
814 Pascal gli argomenti sono inseriti da sinistra a destra ed è compito del
815 chiamato ripulire lo \textit{stack}), in genere non ci si deve preoccupare
816 di questo fintanto che non si mescolano funzioni scritte con linguaggi
819 La dimensione di questo segmento aumenta seguendo la crescita dello
820 \itindex{stack} \textit{stack} del programma, ma non viene ridotta quando
821 quest'ultimo si restringe.
826 % \includegraphics[height=12cm]{img/memory_layout}
828 \draw (0,0) rectangle (4,1);
829 \draw (2,0.5) node {\textit{text}};
830 \draw (0,1) rectangle (4,2.5);
831 \draw (2,1.75) node {dati inizializzati};
832 \draw (0,2.5) rectangle (4,5);
833 \draw (2,3.75) node {dati non inizializzati};
834 \draw (0,5) rectangle (4,9);
835 \draw[dashed] (0,6) -- (4,6);
836 \draw[dashed] (0,8) -- (4,8);
837 \draw (2,5.5) node {\textit{heap}};
838 \draw (2,8.5) node {\textit{stack}};
839 \draw [->] (2,6) -- (2,6.5);
840 \draw [->] (2,8) -- (2,7.5);
841 \draw (0,9) rectangle (4,10);
842 \draw (2,9.5) node {\textit{environment}};
843 \draw (4,0) node [anchor=west] {\texttt{0x08000000}};
844 \draw (4,5) node [anchor=west] {\texttt{0x08xxxxxx}};
845 \draw (4,9) node [anchor=west] {\texttt{0xC0000000}};
847 \caption{Disposizione tipica dei segmenti di memoria di un processo.}
848 \label{fig:proc_mem_layout}
851 Una disposizione tipica dei vari segmenti (testo, dati inizializzati e non
852 inizializzati, \itindex{heap} \textit{heap}, \itindex{stack} \textit{stack},
853 ecc.) è riportata in fig.~\ref{fig:proc_mem_layout}. Si noti come in figura
854 sia indicata una ulteriore regione, marcata \textit{environment}, che è quella
855 che contiene i dati relativi alle variabili di ambiente passate al programma
856 al suo avvio (torneremo su questo argomento in sez.~\ref{sec:proc_environ}).
858 Usando il comando \cmd{size} su un programma se ne può stampare le dimensioni
859 dei \index{segmento!testo} segmenti di testo e \index{segmento!dati} di dati
860 (solo però per i dati inizializzati ed il BSS, dato che lo \itindex{heap}
861 \textit{heap} ha una dimensione dinamica). Si tenga presente comunque che il
862 BSS, contrariamente al segmento dei dati inizializzati, non è mai salvato sul
863 file che contiene l'eseguibile, dato che viene sempre inizializzato a zero al
864 caricamento del programma.
867 \subsection{Allocazione della memoria per i programmi C}
868 \label{sec:proc_mem_alloc}
870 Il C supporta direttamente, come linguaggio di programmazione, soltanto due
871 modalità di allocazione della memoria: l'\textsl{allocazione statica} e
872 l'\textsl{allocazione automatica}.
874 L'\textsl{allocazione statica} è quella con cui sono memorizzate le
875 \index{variabili!globali} variabili globali e le \index{variabili!statiche}
876 variabili statiche, cioè le variabili il cui valore deve essere mantenuto per
877 tutta la durata del programma. Come accennato queste variabili vengono
878 allocate nel \index{segmento!dati} segmento dei dati all'avvio del programma
879 come parte delle operazioni svolte da \func{exec}, e lo spazio da loro
880 occupato non viene liberato fino alla sua conclusione.
882 L'\textsl{allocazione automatica} è quella che avviene per gli argomenti di
883 una funzione e per le sue variabili locali, quelle che vengono definite
884 all'interno della funzione che esistono solo per la durata della sua esecuzione
885 e che per questo vengono anche dette \index{variabili!automatiche}
886 \textsl{variabili automatiche}. Lo spazio per queste variabili viene allocato
887 nello \itindex{stack} \textit{stack} quando viene eseguita la funzione e
888 liberato quando si esce dalla medesima.
890 Esiste però un terzo tipo di allocazione, l'\textsl{allocazione dinamica}
891 della memoria, che non è prevista direttamente all'interno del linguaggio C,
892 ma che è necessaria quando il quantitativo di memoria che serve è
893 determinabile solo durante il corso dell'esecuzione del programma. Il C non
894 consente di usare variabili allocate dinamicamente, non è possibile cioè
895 definire in fase di programmazione una variabile le cui dimensioni possano
896 essere modificate durante l'esecuzione del programma. Per questo la libreria
897 standard del C fornisce una opportuna serie di funzioni per eseguire
898 l'allocazione dinamica di memoria, che come accennato avviene nello
899 \itindex{heap} \textit{heap}.
901 Le variabili il cui contenuto è allocato in questo modo non potranno essere
902 usate direttamente come le altre (quelle nello \itindex{stack}
903 \textit{stack}), ma l'accesso sarà possibile solo in maniera indiretta,
904 attraverso i puntatori alla memoria loro riservata che si sono ottenuti dalle
905 funzioni di allocazione.
907 Le funzioni previste dallo standard ANSI C per la gestione della memoria sono
908 quattro: \func{malloc}, \func{calloc}, \func{realloc} e \func{free}. Le prime
909 due, \funcd{malloc} e \funcd{calloc} allocano nuovo spazio di memoria; i
910 rispettivi prototipi sono:
914 \fdecl{void *calloc(size\_t nmemb, size\_t size)}
915 \fdesc{Alloca un'area di memoria inizializzata a 0.}
916 \fdecl{void *malloc(size\_t size)}
917 \fdesc{Alloca un'area di memoria non inizializzata.}
919 {Entrambe le funzioni restituiscono il puntatore alla zona di memoria allocata
920 in caso di successo e \val{NULL} in caso di fallimento, nel qual caso
921 \var{errno} assumerà il valore \errcode{ENOMEM}.}
924 In genere si usano \func{malloc} e \func{calloc} per allocare dinamicamente
925 un'area di memoria.\footnote{queste funzioni presentano un comportamento
926 diverso fra le \acr{glibc} e le \acr{uClib} quando il valore di \param{size}
927 è nullo. Nel primo caso viene comunque restituito un puntatore valido,
928 anche se non è chiaro a cosa esso possa fare riferimento, nel secondo caso
929 viene restituito \val{NULL}. Il comportamento è analogo con
930 \code{realloc(NULL, 0)}.} Dato che i puntatori ritornati sono di tipo
931 generico non è necessario effettuare un cast per assegnarli a puntatori al
932 tipo di variabile per la quale si effettua l'allocazione, inoltre le funzioni
933 garantiscono che i puntatori siano allineati correttamente per tutti i tipi di
934 dati; ad esempio sulle macchine a 32 bit in genere sono allineati a multipli
935 di 4 byte e sulle macchine a 64 bit a multipli di 8 byte.
937 Nel caso di \func{calloc} l'area di memoria viene allocata nello \textit{heap}
938 come un vettore di \param{nmemb} membri di \param{size} byte di dimensione, e
939 preventivamente inizializzata a zero, nel caso di \func{malloc} invece vengono
940 semplicemente allocati \param{size} byte e l'area di memoria non viene
943 Una volta che non sia più necessaria la memoria allocata dinamicamente deve
944 essere esplicitamente rilasciata usando la funzione \funcd{free},\footnote{le
945 glibc provvedono anche una funzione \funcm{cfree} definita per compatibilità
946 con SunOS, che è deprecata.} il suo prototipo è:
950 \fdecl{void free(void *ptr)}
951 \fdesc{Disalloca un'area di memoria precedentemente allocata.}
953 {La funzione non ritorna nulla e non riporta errori.}
956 Questa funzione vuole come argomento \var{ptr} il puntatore restituito da una
957 precedente chiamata ad una qualunque delle funzioni di allocazione che non sia
958 già stato liberato da un'altra chiamata a \func{free}. Se il valore
959 di \param{ptr} è \val{NULL} la funzione non fa niente, mentre se l'area di
960 memoria era già stata liberata da un precedente chiamata il comportamento
961 della funzione è dichiarato indefinito, ma in genere comporta la corruzione
962 dei dati di gestione dell'allocazione, che può dar luogo a problemi gravi, ad
963 esempio un \textit{segmentation fault} in una successiva chiamata di una di
966 Dato che questo errore, chiamato in gergo \itindex{double~free} \textit{double
967 free}, è abbastanza frequente, specie quando si manipolano vettori di
968 puntatori, e dato che le conseguenze possono essere pesanti ed inaspettate, si
969 suggerisce come soluzione precauzionale di assegnare sempre a \val{NULL} ogni
970 puntatore su cui sia stata eseguita \func{free} immediatamente dopo
971 l'esecuzione della funzione. In questo modo, dato che con un puntatore nullo
972 \func{free} non esegue nessuna operazione, si evitano i problemi del
973 \itindex{double~free} \textit{double free}.
975 Infine la funzione \funcd{realloc} consente di modificare, in genere di
976 aumentare, la dimensione di un'area di memoria precedentemente allocata; il
981 \fdecl{void *realloc(void *ptr, size\_t size)}
982 \fdesc{Cambia la dimensione di un'area di memoria precedentemente allocata.}
983 } {La funzione ritorna il puntatore alla zona di memoria allocata in caso
984 di successo e \val{NULL} per un errore, nel qual caso \var{errno}
985 assumerà il valore \errcode{ENOMEM}.}
988 La funzione vuole come primo argomento il puntatore restituito da una
989 precedente chiamata a \func{malloc} o \func{calloc} e come secondo argomento
990 la nuova dimensione (in byte) che si intende ottenere. Se si passa
991 per \param{ptr} il valore \val{NULL} allora la funzione si comporta come
992 \func{malloc}.\footnote{questo è vero per Linux e l'implementazione secondo lo
993 standard ANSI C, ma non è vero per alcune vecchie implementazioni, inoltre
994 alcune versioni delle librerie del C consentivano di usare \func{realloc}
995 anche per un puntatore liberato con \func{free} purché non ci fossero state
996 nel frattempo altre chiamate a funzioni di allocazione, questa funzionalità
997 è totalmente deprecata e non è consentita sotto Linux.}
999 La funzione si usa ad esempio quando si deve far crescere la dimensione di un
1000 vettore. In questo caso se è disponibile dello spazio adiacente al precedente
1001 la funzione lo utilizza, altrimenti rialloca altrove un blocco della
1002 dimensione voluta, copiandoci automaticamente il contenuto; lo spazio aggiunto
1003 non viene inizializzato. Se la funzione fallisce l'area di memoria originale
1004 non viene assolutamente toccata.
1006 Si deve sempre avere ben presente il fatto che il blocco di memoria restituito
1007 da \func{realloc} può non essere un'estensione di quello che gli si è passato
1008 in ingresso; per questo si dovrà \emph{sempre} eseguire la riassegnazione di
1009 \param{ptr} al valore di ritorno della funzione, e reinizializzare o provvedere
1010 ad un adeguato aggiornamento di tutti gli altri puntatori all'interno del
1011 blocco di dati ridimensionato.
1013 La \acr{glibc} ha un'implementazione delle funzioni di allocazione che è
1014 controllabile dall'utente attraverso alcune variabili di ambiente (vedi
1015 sez.~\ref{sec:proc_environ}), in particolare diventa possibile tracciare
1016 questo tipo di errori usando la variabile di ambiente \envvar{MALLOC\_CHECK\_}
1017 che quando viene definita mette in uso una versione meno efficiente delle
1018 funzioni suddette, che però è più tollerante nei confronti di piccoli errori
1019 come quello dei \itindex{double~free} \textit{double~free} o i
1020 \itindex{buffer~overrun} \textit{buffer overrun} di un byte.\footnote{uno
1021 degli errori più comuni, causato ad esempio dalla scrittura di una stringa
1022 di dimensione pari a quella del buffer, in cui ci si dimentica dello zero di
1023 terminazione finale.} In particolare:
1025 \item se la variabile è posta a $0$ gli errori vengono ignorati;
1026 \item se la variabile è posta a $1$ viene stampato un avviso sullo
1027 \textit{standard error} (vedi sez.~\ref{sec:file_fd});
1028 \item se la variabile è posta a $2$ viene chiamata la funzione \func{abort}
1029 (vedi sez.~\ref{sec:sig_alarm_abort}), che in genere causa l'immediata
1030 terminazione del programma;
1031 \item se la variabile è posta a $3$ viene stampato l'avviso e chiamata
1035 L'errore di programmazione più comune e più difficile da risolvere che si
1036 incontra con le funzioni di allocazione è quando non viene opportunamente
1037 liberata la memoria non più utilizzata, quello che in inglese viene chiamato
1038 \itindex{memory~leak} \textit{memory leak}, cioè una \textsl{perdita di
1041 Un caso tipico che illustra il problema è quello in cui in una propria
1042 funzione si alloca della memoria per uso locale senza liberarla prima di
1043 uscire. La memoria resta così allocata fino alla terminazione del processo.
1044 Chiamate ripetute alla stessa funzione continueranno ad effettuare altre
1045 allocazioni, che si accumuleranno causando a lungo andare un esaurimento della
1046 memoria disponibile e la probabile impossibilità di proseguire l'esecuzione
1049 Il problema è che l'esaurimento della memoria può avvenire in qualunque
1050 momento, in corrispondenza ad una qualunque chiamata di \func{malloc} che può
1051 essere in una sezione del codice che non ha alcuna relazione con la funzione
1052 che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
1053 \itindex{memory~leak} \textit{memory leak}.
1055 In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
1056 programmazione ad oggetti, il problema dei \itindex{memory~leak}
1057 \textit{memory leak} si può notevolmente ridimensionare attraverso l'uso
1058 accurato di appositi oggetti come gli \textit{smartpointers}. Questo però in
1059 genere va a scapito delle prestazioni dell'applicazione in esecuzione.
1061 % TODO decidere cosa fare di questo che segue
1062 % In altri linguaggi come il java e recentemente il C\# il problema non si pone
1063 % nemmeno perché la gestione della memoria viene fatta totalmente in maniera
1064 % automatica, ovvero il programmatore non deve minimamente preoccuparsi di
1065 % liberare la memoria allocata precedentemente quando non serve più, poiché
1066 % l'infrastruttura del linguaggio gestisce automaticamente la cosiddetta
1067 % \index{\textit{garbage~collection}} \textit{garbage collection}. In tal caso,
1068 % attraverso meccanismi simili a quelli del \textit{reference counting}, quando
1069 % una zona di memoria precedentemente allocata non è più riferita da nessuna
1070 % parte del codice in esecuzione, può essere deallocata automaticamente in
1071 % qualunque momento dall'infrastruttura.
1073 % Anche questo va a scapito delle prestazioni dell'applicazione in esecuzione
1074 % (inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
1075 % eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
1076 % la presenza di una infrastruttura per la loro interpretazione e pertanto hanno
1077 % di per sé delle prestazioni più scadenti rispetto alle stesse applicazioni
1078 % compilate direttamente). Questo comporta però il problema della non
1079 % predicibilità del momento in cui viene deallocata la memoria precedentemente
1080 % allocata da un oggetto.
1082 Per limitare l'impatto di questi problemi, e semplificare la ricerca di
1083 eventuali errori, l'implementazione delle funzioni di allocazione nella
1084 \acr{glibc} mette a disposizione una serie di funzionalità che permettono di
1085 tracciare le allocazioni e le disallocazioni, e definisce anche una serie di
1086 possibili \textit{hook} (\textsl{ganci}) che permettono di sostituire alle
1087 funzioni di libreria una propria versione (che può essere più o meno
1088 specializzata per il debugging). Esistono varie librerie che forniscono dei
1089 sostituti opportuni delle funzioni di allocazione in grado, senza neanche
1090 ricompilare il programma,\footnote{esempi sono \textit{Dmalloc}
1091 \url{http://dmalloc.com/} di Gray Watson ed \textit{Electric Fence} di Bruce
1092 Perens.} di eseguire diagnostiche anche molto complesse riguardo
1093 l'allocazione della memoria. Vedremo alcune delle funzionalità di ausilio
1094 presenti nella \acr{glibc} in sez.~\ref{sec:proc_memory_adv_management}.
1096 Una possibile alternativa all'uso di \func{malloc}, per evitare di soffrire
1097 dei problemi di \itindex{memory~leak} \textit{memory leak} descritti in
1098 precedenza, è di allocare la memoria nel segmento di \itindex{stack}
1099 \textit{stack} della funzione corrente invece che nello \itindex{heap}
1100 \textit{heap}. Per farlo si può usare la funzione \funcd{alloca}, la cui
1101 sintassi è identica a quella di \func{malloc}; il suo prototipo è:
1105 \fdecl{void *alloca(size\_t size)}
1106 \fdesc{Alloca un'area di memoria nello \textit{stack}.}
1108 {La funzione ritorna il puntatore alla zona di memoria allocata, in caso
1109 di errore il comportamento è indefinito.}
1112 La funzione alloca la quantità di memoria (non inizializzata) richiesta
1113 dall'argomento \param{size} nel segmento di \itindex{stack} \textit{stack}
1114 della funzione chiamante. Con questa funzione non è più necessario liberare
1115 la memoria allocata, e quindi non esiste un analogo della \func{free}, in
1116 quanto essa viene rilasciata automaticamente al ritorno della funzione.
1118 Come è evidente questa funzione ha alcuni vantaggi interessanti, anzitutto
1119 permette di evitare alla radice i problemi di \itindex{memory~leak}
1120 \textit{memory leak}, dato che non serve più la deallocazione esplicita;
1121 inoltre la deallocazione automatica funziona anche quando si usa
1122 \func{longjmp} per uscire da una subroutine con un salto non locale da una
1123 funzione (vedi sez.~\ref{sec:proc_longjmp}). Un altro vantaggio è che in
1124 Linux la funzione è molto più veloce di \func{malloc} e non viene sprecato
1125 spazio, infatti non è necessario gestire un pool di memoria da riservare e si
1126 evitano così anche i problemi di frammentazione di quest'ultimo, che
1127 comportano inefficienze sia nell'allocazione della memoria che nell'esecuzione
1130 Gli svantaggi sono che questa funzione non è disponibile su tutti gli Unix, e
1131 non è inserita né nello standard POSIX né in SUSv3 (ma è presente in BSD), il
1132 suo utilizzo quindi limita la portabilità dei programmi. Inoltre la funzione
1133 non può essere usata nella lista degli argomenti di una funzione, perché lo
1134 spazio verrebbe allocato nel mezzo degli stessi. Inoltre non è chiaramente
1135 possibile usare \func{alloca} per allocare memoria che deve poi essere usata
1136 anche al di fuori della funzione in cui essa viene chiamata, dato che
1137 all'uscita dalla funzione lo spazio allocato diventerebbe libero, e potrebbe
1138 essere sovrascritto all'invocazione di nuove funzioni. Questo è lo stesso
1139 problema che si può avere con le \index{variabili!automatiche} variabili
1140 automatiche, su cui torneremo in sez.~\ref{sec:proc_var_passing}.
1142 Infine non esiste un modo di sapere se l'allocazione ha avuto successo, la
1143 funzione infatti viene realizzata inserendo del codice \textit{inline} nel
1144 programma\footnote{questo comporta anche il fatto che non è possibile
1145 sostituirla con una propria versione o modificarne il comportamento
1146 collegando il proprio programma con un'altra libreria.} che si limita a
1147 modificare il puntatore nello \itindex{stack} \textit{stack} e non c'è modo di
1148 sapere se se ne sono superate le dimensioni, per cui in caso di fallimento
1149 nell'allocazione il comportamento del programma può risultare indefinito,
1150 dando luogo ad una \itindex{segment~violation} \textit{segment violation} la
1151 prima volta che cercherà di accedere alla memoria non effettivamente
1155 \index{segmento!dati|(}
1157 Le due funzioni seguenti\footnote{le due funzioni sono state definite con BSD
1158 4.3, sono marcate obsolete in SUSv2 e non fanno parte delle librerie
1159 standard del C e mentre sono state esplicitamente rimosse dallo standard
1160 POSIX.1-2001.} vengono utilizzate soltanto quando è necessario effettuare
1161 direttamente la gestione della memoria associata allo spazio dati di un
1162 processo, per poterle utilizzare è necessario definire una della macro di
1163 funzionalità (vedi sez.~\ref{sec:intro_gcc_glibc_std}) fra
1164 \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE} (ad un
1165 valore maggiore o uguale di 500). La prima funzione è \funcd{brk}, ed il suo
1170 \fdecl{int brk(void *addr)}
1171 \fdesc{Sposta la fine del segmento dati del processo.}
1173 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
1174 nel qual caso \var{errno} assumerà il valore \errcode{ENOMEM}.}
1177 La funzione è un'interfaccia all'omonima \textit{system call} ed imposta
1178 l'indirizzo finale del segmento dati di un processo (più precisamente dello
1179 \itindex{heap} \textit{heap}) all'indirizzo specificato
1180 da \param{addr}. Quest'ultimo deve essere un valore ragionevole, e la
1181 dimensione totale non deve comunque eccedere un eventuale limite (vedi
1182 sez.~\ref{sec:sys_resource_limit}) imposto sulle dimensioni massime del
1183 segmento dati del processo.
1185 Il valore di ritorno della funzione fa riferimento alla versione fornita dalla
1186 \acr{glibc}, in realtà in Linux la \textit{system call} corrispondente
1187 restituisce come valore di ritorno il nuovo valore della fine del segmento
1188 dati in caso di successo e quello corrente in caso di fallimento, è la
1189 funzione di interfaccia usata dalla \acr{glibc} che fornisce i valori di
1190 ritorno appena descritti; se si usano librerie diverse questo potrebbe non
1193 Una seconda funzione per la manipolazione diretta delle dimensioni del
1194 segmento dati\footnote{in questo caso si tratta soltanto di una funzione di
1195 libreria, anche se basata sulla stessa \textit{system call}.} è
1196 \funcd{sbrk}, ed il suo prototipo è:
1200 \fdecl{void *sbrk(intptr\_t increment)}
1201 \fdesc{Incrementa la dimensione del segmento dati del processo.}
1203 {La funzione ritorna il puntatore all'inizio della nuova zona di memoria
1204 allocata in caso di successo e \val{NULL} per un errore, nel qual
1205 caso \var{errno} assumerà il valore \errcode{ENOMEM}.}
1208 La funzione incrementa la dimensione dello \itindex{heap} \textit{heap} di un
1209 programma del valore indicato dall'argomento \param{increment}, restituendo il
1210 nuovo indirizzo finale dello stesso. L'argomento è definito come di tipo
1211 \type{intptr\_t}, ma a seconda della versione delle librerie e del sistema può
1212 essere indicato con una serie di tipi equivalenti come \type{ptrdiff\_t},
1213 \type{ssize\_t}, \ctyp{int}. Se invocata con un valore nullo la funzione
1214 permette di ottenere l'attuale posizione della fine del segmento dati.
1216 Queste due funzioni sono state deliberatamente escluse dallo standard POSIX.1
1217 dato che per i normali programmi è sempre opportuno usare le funzioni di
1218 allocazione standard descritte in precedenza, a meno di non voler realizzare
1219 per proprio conto un diverso meccanismo di gestione della memoria del segmento
1222 \index{segmento!dati|)}
1225 \subsection{Il controllo della memoria virtuale}
1226 \label{sec:proc_mem_lock}
1228 \index{memoria~virtuale|(}
1230 Come spiegato in sez.~\ref{sec:proc_mem_gen} il kernel gestisce la memoria
1231 virtuale in maniera trasparente ai processi, decidendo quando rimuovere pagine
1232 dalla memoria per metterle nell'area di \textit{swap}, sulla base
1233 dell'utilizzo corrente da parte dei vari processi.
1235 Nell'uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il
1236 meccanismo della paginazione riporta in RAM, ed in maniera trasparente, tutte
1237 le pagine che gli occorrono; esistono però esigenze particolari in cui non si
1238 vuole che questo meccanismo si attivi. In generale i motivi per cui si possono
1239 avere di queste necessità sono due:
1241 \item \textsl{La velocità}. Il processo della paginazione è trasparente solo
1242 se il programma in esecuzione non è sensibile al tempo che occorre a
1243 riportare la pagina in memoria; per questo motivo processi critici che hanno
1244 esigenze di tempo reale o tolleranze critiche nelle risposte (ad esempio
1245 processi che trattano campionamenti sonori) possono non essere in grado di
1246 sopportare le variazioni della velocità di accesso dovuta alla paginazione.
1248 In certi casi poi un programmatore può conoscere meglio dell'algoritmo di
1249 allocazione delle pagine le esigenze specifiche del suo programma e decidere
1250 quali pagine di memoria è opportuno che restino in memoria per un aumento
1251 delle prestazioni. In genere queste sono esigenze particolari e richiedono
1252 anche un aumento delle priorità in esecuzione del processo (vedi
1253 sez.~\ref{sec:proc_real_time}).
1255 \item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro
1256 in memoria queste possono essere portate su disco dal meccanismo della
1257 paginazione. Questo rende più lungo il periodo di tempo in cui detti segreti
1258 sono presenti in chiaro e più complessa la loro cancellazione: un processo
1259 infatti può cancellare la memoria su cui scrive le sue variabili, ma non può
1260 toccare lo spazio disco su cui una pagina di memoria può essere stata
1261 salvata. Per questo motivo di solito i programmi di crittografia richiedono
1262 il blocco di alcune pagine di memoria.
1265 Per ottenere informazioni sulle modalità in cui un programma sta usando la
1266 memoria virtuale è disponibile una apposita funzione di sistema,
1267 \funcd{mincore}, che però non è standardizzata da POSIX e pertanto non è
1268 disponibile su tutte le versioni di kernel unix-like;\footnote{nel caso di
1269 Linux devono essere comunque definite le macro \macro{\_BSD\_SOURCE} e
1270 \macro{\_SVID\_SOURCE}.} il suo prototipo è:
1275 \fdecl{int mincore(void *addr, size\_t length, unsigned char *vec)}
1276 \fdesc{Ritorna lo stato delle pagine di memoria occupate da un processo.}
1278 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1279 caso \var{errno} assumerà uno dei valori:
1281 \item[\errcode{EAGAIN}] il kernel è temporaneamente non in grado di fornire
1283 \item[\errcode{EFAULT}] \param{vec} punta ad un indirizzo non valido.
1284 \item[\errcode{EINVAL}] \param{addr} non è un multiplo delle dimensioni di
1286 \item[\errcode{ENOMEM}] o \param{addr}$+$\param{length} eccede la dimensione
1287 della memoria usata dal processo o l'intervallo di indirizzi specificato
1292 La funzione permette di ottenere le informazioni sullo stato della mappatura
1293 della memoria per il processo chiamante, specificando l'intervallo da
1294 esaminare con l'indirizzo iniziale, indicato con l'argomento \param{addr}, e
1295 la lunghezza, indicata con l'argomento \param{length}. L'indirizzo iniziale
1296 deve essere un multiplo delle dimensioni di una pagina, mentre la lunghezza
1297 può essere qualunque, fintanto che si resta nello spazio di indirizzi del
1298 processo,\footnote{in caso contrario si avrà un errore di \errcode{ENOMEM};
1299 fino al kernel 2.6.11 in questo caso veniva invece restituito
1300 \errcode{EINVAL}, in considerazione che il caso più comune in cui si
1301 verifica questo errore è quando si usa per sbaglio un valore negativo
1302 di \param{length}, che nel caso verrebbe interpretato come un intero
1303 positivo di grandi dimensioni.} ma il risultato verrà comunque fornito per
1304 l'intervallo compreso fino al multiplo successivo.
1306 I risultati della funzione vengono forniti nel vettore puntato da \param{vec},
1307 che deve essere allocato preventivamente e deve essere di dimensione
1308 sufficiente a contenere tanti byte quante sono le pagine contenute
1309 nell'intervallo di indirizzi specificato, la dimensione cioè deve essere
1310 almeno pari a \code{(length+PAGE\_SIZE-1)/PAGE\_SIZE}. Al ritorno della
1311 funzione il bit meno significativo di ciascun byte del vettore sarà acceso se
1312 la pagina di memoria corrispondente è al momento residente in memoria, o
1313 cancellato altrimenti. Il comportamento sugli altri bit è indefinito, essendo
1314 questi al momento riservati per usi futuri. Per questo motivo in genere è
1315 comunque opportuno inizializzare a zero il contenuto del vettore, così che le
1316 pagine attualmente residenti in memoria saranno indicata da un valore non
1317 nullo del byte corrispondente.
1319 Dato che lo stato della memoria di un processo può cambiare continuamente, il
1320 risultato di \func{mincore} è assolutamente provvisorio e lo stato delle
1321 pagine potrebbe essere già cambiato al ritorno stesso della funzione, a meno
1322 che, come vedremo ora, non si sia attivato il meccanismo che forza il
1323 mantenimento di una pagina sulla memoria.
1325 \itindbeg{memory~locking}
1327 Il meccanismo che previene la paginazione di parte della memoria virtuale di
1328 un processo è chiamato \textit{memory locking} (o \textsl{blocco della
1329 memoria}). Il blocco è sempre associato alle pagine della memoria virtuale
1330 del processo, e non al segmento reale di RAM su cui essa viene mantenuta. La
1331 regola è che se un segmento di RAM fa da supporto ad almeno una pagina
1332 bloccata allora esso viene escluso dal meccanismo della paginazione. I blocchi
1333 non si accumulano, se si blocca due volte la stessa pagina non è necessario
1334 sbloccarla due volte, una pagina o è bloccata oppure no.
1336 Il \textit{memory lock} persiste fintanto che il processo che detiene la
1337 memoria bloccata non la sblocca. Chiaramente la terminazione del processo
1338 comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
1339 tutti i suoi \textit{memory lock}. Inoltre i \textit{memory lock} non sono
1340 ereditati dai processi figli, ma siccome Linux usa il \itindex{copy~on~write}
1341 \textit{copy on write} (vedi sez.~\ref{sec:proc_fork}) gli indirizzi virtuali
1342 del figlio sono mantenuti sullo stesso segmento di RAM del padre, e quindi
1343 fintanto che un figlio non scrive su un segmento bloccato, può usufruire del
1344 \textit{memory lock} del padre. Infine i \textit{memory lock} vengono
1345 automaticamente rimossi se si pone in esecuzione un altro programma con
1346 \func{exec} (vedi sez.~\ref{sec:proc_exec}).
1348 Il sistema pone dei limiti all'ammontare di memoria di un processo che può
1349 essere bloccata e al totale di memoria fisica che si può dedicare a questo, lo
1350 standard POSIX.1 richiede che sia definita in \headfile{unistd.h} la macro
1351 \macro{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
1352 \textit{memory locking}.
1354 Siccome la richiesta di un \textit{memory lock} da parte di un processo riduce
1355 la memoria fisica disponibile nel sistema per gli altri processi, questo ha un
1356 evidente impatto su tutti gli altri processi, per cui fino al kernel 2.6.9
1357 solo un processo dotato di privilegi amministrativi (la \textit{capability}
1358 \const{CAP\_IPC\_LOCK}, vedi sez.~\ref{sec:proc_capabilities}) aveva la
1359 capacità di bloccare una pagina di memoria.
1361 A partire dal kernel 2.6.9 anche un processo normale può bloccare la propria
1362 memoria\footnote{la funzionalità è stata introdotta per non essere costretti a
1363 dare privilegi eccessivi a programmi di crittografia, che necessitano di
1364 questa funzionalità, ma che devono essere usati da utenti normali.} ma
1365 mentre un processo privilegiato non ha limiti sulla quantità di memoria che
1366 può bloccare, un processo normale è soggetto al limite della risorsa
1367 \const{RLIMIT\_MEMLOCK} (vedi sez.~\ref{sec:sys_resource_limit}). In generale
1368 poi ogni processo può sbloccare le pagine relative alla propria memoria, se
1369 però diversi processi bloccano la stessa pagina questa resterà bloccata
1370 fintanto che ci sarà almeno un processo che la blocca.
1372 Le funzioni di sistema per bloccare e sbloccare la paginazione di singole
1373 sezioni di memoria sono rispettivamente \funcd{mlock} e \funcd{munlock}; i
1374 loro prototipi sono:
1378 \fdecl{int mlock(const void *addr, size\_t len)}
1379 \fdesc{Blocca la paginazione su un intervallo di memoria.}
1381 \fdecl{int munlock(const void *addr, size\_t len)}
1382 \fdesc{Rimuove il blocco della paginazione su un intervallo di memoria.}
1384 {Entrambe le funzioni ritornano $0$ in caso di successo e $-1$ in caso di
1385 errore, nel qual caso \var{errno} assumerà uno dei valori:
1387 \item[\errcode{EINVAL}] \param{len} non è un valore positivo.
1388 \item[\errcode{ENOMEM}] alcuni indirizzi dell’intervallo specificato non
1389 corrispondono allo spazio di indirizzi del processo o si è superato il
1390 limite di \const{RLIMIT\_MEMLOCK} per un processo non privilegiato (solo
1391 per kernel a partire dal 2.6.9).
1392 \item[\errcode{EPERM}] il processo non è privilegiato (per kernel precedenti
1393 il 2.6.9) o si ha un limite nullo per \const{RLIMIT\_MEMLOCK} e
1394 il processo non è privilegiato (per kernel a partire dal 2.6.9).
1398 Le due funzioni permettono rispettivamente di bloccare e sbloccare la
1399 \index{paginazione} paginazione per l'intervallo di memoria iniziante
1400 all'indirizzo \param{addr} e lungo \param{len} byte. Tutte le pagine che
1401 contengono una parte dell'intervallo bloccato sono mantenute in RAM per tutta
1402 la durata del blocco. Con kernel diversi da Linux si può ottenere un errore di
1403 \errcode{EINVAL} se \param{addr} non è un multiplo della dimensione delle
1404 pagine di memoria, pertanto se si ha a cuore la portabilità si deve avere cura
1405 di allinearne correttamente il valore.
1407 Altre due funzioni di sistema, \funcd{mlockall} e \funcd{munlockall},
1408 consentono di bloccare genericamente la \index{paginazione} paginazione per
1409 l'intero spazio di indirizzi di un processo. I prototipi di queste funzioni
1414 \fdecl{int mlockall(int flags)}
1415 \fdesc{Blocca la paginazione per lo spazio di indirizzi del processo corrente.}
1416 \fdecl{int munlockall(void)}
1417 \fdesc{Sblocca la paginazione per lo spazio di indirizzi del processo corrente.}
1419 {Codici di ritorno ed errori sono gli stessi di \func{mlock} e \func{munlock},
1420 tranne per \errcode{EINVAL} che viene restituito solo se si è specificato
1421 con \func{mlockall} un valore sconosciuto per \param{flags}.}
1424 L'argomento \param{flags} di \func{mlockall} permette di controllarne il
1425 comportamento; esso deve essere specificato come maschera binaria dei valori
1426 espressi dalle costanti riportate in tab.~\ref{tab:mlockall_flags}.
1431 \begin{tabular}[c]{|l|p{8cm}|}
1433 \textbf{Valore} & \textbf{Significato} \\
1436 \const{MCL\_CURRENT}& blocca tutte le pagine correntemente mappate nello
1437 spazio di indirizzi del processo.\\
1438 \const{MCL\_FUTURE} & blocca tutte le pagine che verranno mappate nello
1439 spazio di indirizzi del processo.\\
1442 \caption{Valori e significato dell'argomento \param{flags} della funzione
1444 \label{tab:mlockall_flags}
1447 Con \func{mlockall} si possono bloccare tutte le pagine mappate nello spazio
1448 di indirizzi del processo, sia che comprendano il \index{segmento!dati}
1449 \index{segmento!testo} segmento di testo, di dati, lo \itindex{stack}
1450 \textit{stack}, lo \itindex{heap} \textit{heap} e pure le funzioni di libreria
1451 chiamate, i file mappati in memoria, i dati del kernel mappati in user space,
1452 la memoria condivisa. L'uso dell'argomento \param{flags} permette di
1453 selezionare con maggior finezza le pagine da bloccare, ad esempio usando
1454 \const{MCL\_FUTURE} ci si può limitare a tutte le pagine allocate a partire
1455 dalla chiamata della funzione.
1457 In ogni caso un processo real-time che deve entrare in una
1458 \index{sezione~critica} sezione critica deve provvedere a riservare memoria
1459 sufficiente prima dell'ingresso, per scongiurare l'occorrenza di un eventuale
1460 \itindex{page~fault} \textit{page fault} causato dal meccanismo di
1461 \itindex{copy~on~write} \textit{copy on write}. Infatti se nella
1462 \index{sezione~critica} sezione critica si va ad utilizzare memoria che non è
1463 ancora stata riportata in RAM si potrebbe avere un \itindex{page~fault}
1464 \textit{page fault} durante l'esecuzione della stessa, con conseguente
1465 rallentamento (probabilmente inaccettabile) dei tempi di esecuzione.
1467 In genere si ovvia a questa problematica chiamando una funzione che ha
1468 allocato una quantità sufficientemente ampia di \index{variabili!automatiche}
1469 variabili automatiche, in modo che esse vengano mappate in RAM dallo
1470 \itindex{stack} \textit{stack}, dopo di che, per essere sicuri che esse siano
1471 state effettivamente portate in memoria, ci si scrive sopra.
1473 \itindend{memory~locking}
1475 \index{memoria~virtuale|)}
1478 \subsection{Gestione avanzata dell'allocazione della memoria}
1479 \label{sec:proc_memory_adv_management}
1481 La trattazione delle funzioni di allocazione di sez.~\ref{sec:proc_mem_alloc}
1482 si è limitata a coprire le esigenze generiche di un programma, in cui non si
1483 hanno dei requisiti specifici e si lascia il controllo delle modalità di
1484 allocazione alle funzioni di libreria. Tuttavia esistono una serie di casi in
1485 cui può essere necessario avere un controllo più dettagliato delle modalità
1486 con cui la memoria viene allocata; nel qual caso potranno venire in aiuto le
1487 funzioni trattate in questa sezione.
1489 Le prime funzioni che tratteremo sono quelle che consentono di richiedere di
1490 allocare un blocco di memoria ``\textsl{allineato}'' ad un multiplo una certa
1491 dimensione. Questo tipo di esigenza emerge usualmente quando si devono
1492 allocare dei buffer da utilizzare per eseguire dell'I/O diretto su dispositivi
1493 a blocchi. In questo caso infatti il trasferimento di dati viene eseguito per
1494 blocchi di dimensione fissa, ed è richiesto che l'indirizzo di partenza del
1495 buffer sia un multiplo intero di questa dimensione, usualmente 512 byte. In
1496 tal caso l'uso di \func{malloc} non è sufficiente, ed occorre utilizzare una
1499 Tradizionalmente per rispondere a questa esigenza sono state create due
1500 funzioni diverse, \funcd{memalign} e \funcd{valloc}, oggi obsolete; i
1501 rispettivi prototipi sono:
1505 \fdecl{void *valloc(size\_t size)}
1506 \fdesc{Alloca un blocco di memoria allineato alla dimensione di una pagina di
1508 \fdecl{void *memalign(size\_t boundary, size\_t size)}
1509 \fdesc{Alloca un blocco di memoria allineato ad un multiplo
1510 di \param{boundary}.}
1512 {Entrambe le funzioni ritornano un puntatore al blocco di memoria allocato in
1513 caso di successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
1514 assumerà uno dei valori:
1516 \item[\errcode{EINVAL}] \param{boundary} non è una potenza di due.
1517 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione.
1521 Le funzioni restituiscono il puntatore al buffer di memoria allocata di
1522 dimensioni pari a \param{size}, che per \func{memalign} sarà un multiplo
1523 di \param{boundary} mentre per \func{valloc} un multiplo della dimensione di
1524 una pagina di memoria. Nel caso della versione fornita dalla \acr{glibc} la
1525 memoria allocata con queste funzioni deve essere liberata con \func{free},
1526 cosa che non è detto accada con altre implementazioni.
1528 Nessuna delle due funzioni ha una chiara standardizzazione e nessuna delle due
1529 compare in POSIX.1, inoltre ci sono indicazioni discordi sui file che ne
1530 contengono la definizione;\footnote{secondo SUSv2 \func{valloc} è definita in
1531 \headfile{stdlib.h}, mentre sia le \acr{glibc} che le precedenti \acr{libc4}
1532 e \acr{libc5} la dichiarano in \headfile{malloc.h}, lo stesso vale per
1533 \func{memalign} che in alcuni sistemi è dichiarata in \headfile{stdlib.h}.}
1534 per questo motivo il loro uso è sconsigliato, essendo state sostituite dalla
1535 nuova \funcd{posix\_memalign}, che è stata standardizzata in POSIX.1d; il suo
1540 \fdecl{posix\_memalign(void **memptr, size\_t alignment, size\_t size)}
1541 \fdesc{Alloca un buffer di memoria allineato ad un multiplo
1542 di \param{alignment}.}
1544 {Entrambe le funzioni ritornano un puntatore al blocco di memoria allocato in
1545 caso di successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
1546 assumerà uno dei valori:
1548 \item[\errcode{EINVAL}] \param{alignment} non è potenza di due e multiplo
1549 di \code{sizeof(void *)}.
1550 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione.
1554 La funzione restituisce il puntatore al buffer allocato di dimensioni pari
1555 a \param{size} nella variabile (di tipo \texttt{void *}) posta all'indirizzo
1556 indicato da \param{memptr}. La funzione fallisce nelle stesse condizioni delle
1557 due funzioni precedenti, ma a loro differenza restituisce direttamente come
1558 valore di ritorno il codice di errore. Come per le precedenti la memoria
1559 allocata con \func{posix\_memalign} deve essere disallocata con \func{free},
1560 che in questo caso però è quanto richiesto dallo standard. Si tenga presente
1561 infine che nessuna di queste funzioni inizializza il buffer di memoria
1562 allocato, il loro comportamento cioè è analogo, allineamento a parte, a quello
1565 Un secondo caso in cui risulta estremamente utile poter avere un maggior
1566 controllo delle modalità di allocazione della memoria è quello in cui cercano
1567 errori di programmazione. Esempi di questi errori sono i \itindex{double~free}
1568 \textit{double free}, o i cosiddetti \itindex{buffer~overrun} \textit{buffer
1569 overrun}, cioè le scritture su un buffer oltre le dimensioni della sua
1570 allocazione,\footnote{entrambe queste operazioni causano in genere la
1571 corruzione dei dati di controllo delle funzioni di allocazione, che vengono
1572 anch'essi mantenuti nello \itindex{heap} \textit{heap} per tenere traccia
1573 delle zone di memoria allocata.} o i classici \itindex{memory~leak}
1574 \textit{memory leak}.
1576 Abbiamo visto in sez.~\ref{sec:proc_mem_lock} come una prima funzionalità di
1577 ausilio nella ricerca di questi errori sia l'uso della variabile di ambiente
1578 \envvar{MALLOC\_CHECK\_}. Una modalità alternativa per effettuare dei
1579 controlli di consistenza sullo stato delle allocazioni di memoria eseguite con
1580 \func{malloc}, anche questa fornita come estensione specifica (e non standard)
1581 della \acr{glibc}, è quella di utilizzare la funzione \funcd{mcheck}, che deve
1582 essere chiamata prima di eseguire qualunque allocazione con \func{malloc}; il
1587 \fdecl{int mcheck(void (*abortfn) (enum mcheck\_status status))}
1588 \fdesc{Attiva i controlli di consistenza delle allocazioni di memoria.}
1590 {La funzione ritorna $0$ in caso di successo e $-1$ per un errorre;
1591 \var{errno} non viene impostata.}
1594 La funzione consente di registrare una funzione di emergenza che verrà
1595 eseguita tutte le volte che, in una successiva esecuzione di \func{malloc},
1596 venissero trovate delle inconsistenze, come delle operazioni di scrittura
1597 oltre i limiti dei buffer allocati. Per questo motivo la funzione deve essere
1598 chiamata prima di qualunque allocazione di memoria, altrimenti fallirà.
1600 Se come primo argomento di \func{mcheck} si passa \val{NULL} verrà utilizzata
1601 una funzione predefinita che stampa un messaggio di errore ed invoca la
1602 funzione \func{abort} (vedi sez.~\ref{sec:sig_alarm_abort}), altrimenti si
1603 dovrà creare una funzione personalizzata in grado di ricevere il tipo di
1604 errore ed agire di conseguenza.
1606 Nonostante la scarsa leggibilità del prototipo si tratta semplicemente di
1607 definire una funzione di tipo \code{void abortfn(enum mcheck\_status status)},
1608 che non deve restituire nulla e che deve avere un unico argomento di tipo
1609 \code{mcheck\_status}. In caso di errore la funzione verrà eseguita ricevendo
1610 un opportuno valore di \param{status} che è un tipo enumerato che può assumere
1611 soltanto i valori di tab.~\ref{tab:mcheck_status_value} che indicano la
1612 tipologia di errore riscontrata.
1617 \begin{tabular}[c]{|l|p{7cm}|}
1619 \textbf{Valore} & \textbf{Significato} \\
1622 \const{MCHECK\_OK} & Riportato a \func{mprobe} se nessuna
1623 inconsistenza è presente.\\
1624 \const{MCHECK\_DISABLED}& Riportato a \func{mprobe} se si è chiamata
1625 \func{mcheck} dopo aver già usato
1627 \const{MCHECK\_HEAD} & I dati immediatamente precedenti il buffer sono
1628 stati modificati, avviene in genere quando si
1629 decrementa eccessivamente il valore di un
1630 puntatore scrivendo poi prima dell'inizio del
1632 \const{MCHECK\_TAIL} & I dati immediatamente seguenti il buffer sono
1633 stati modificati, succede quando si va scrivere
1634 oltre la dimensione corretta del buffer.\\
1635 \const{MCHECK\_FREE} & Il buffer è già stato disallocato.\\
1638 \caption{Valori dello stato dell'allocazione di memoria ottenibili dalla
1639 funzione di terminazione installata con \func{mcheck}.}
1640 \label{tab:mcheck_status_value}
1643 Una volta che si sia chiamata \func{mcheck} con successo si può anche
1644 controllare esplicitamente lo stato delle allocazioni senza aspettare un
1645 errore nelle relative funzioni utilizzando la funzione \funcd{mprobe}, il cui
1650 \fdecl{enum mcheck\_status mprobe(ptr)}
1651 \fdesc{Esegue un controllo di consistenza delle allocazioni.}
1653 {La funzione ritorna un codice fra quelli riportati in
1654 tab.~\ref{tab:mcheck_status_value} e non ha errori.}
1657 La funzione richiede che si passi come argomento un puntatore ad un blocco di
1658 memoria precedentemente allocato con \func{malloc} o \func{realloc}, e
1659 restituisce lo stesso codice di errore che si avrebbe per la funzione di
1660 emergenza ad una successiva chiamata di una funzione di allocazione, e poi i
1661 primi due codici che indicano rispettivamente quando tutto è a posto o il
1662 controllo non è possibile per non aver chiamato \func{mcheck} in tempo.
1664 % TODO: trattare le altre funzionalità avanzate di \func{malloc}, mallopt,
1665 % mtrace, muntrace, mallinfo e gli hook con le glibc 2.10 c'è pure malloc_info
1666 % a sostituire mallinfo, vedi http://udrepper.livejournal.com/20948.html
1669 \section{Argomenti, ambiente ed altre proprietà di un processo}
1670 \label{sec:proc_options}
1672 In questa sezione esamineremo le funzioni che permettono di gestire gli
1673 argomenti e le opzioni, e quelle che consentono di manipolare ed utilizzare le
1674 variabili di ambiente. Accenneremo infine alle modalità con cui si può gestire
1675 la localizzazione di un programma modificandone il comportamento a seconda
1676 della lingua o del paese a cui si vuole faccia riferimento nelle sue
1679 \subsection{Il formato degli argomenti}
1680 \label{sec:proc_par_format}
1682 Tutti i programmi hanno la possibilità di ricevere argomenti e opzioni quando
1683 vengono lanciati e come accennato in sez.~\ref{sec:proc_main} questo viene
1684 effettuato attraverso gli argomenti \param{argc} e \param{argv} ricevuti nella
1685 funzione \code{main} all'avvio del programma. Questi argomenti vengono passati
1686 al programma dalla shell o dal processo che esegue la \func{exec} (secondo le
1687 modalità che vedremo in sez.~\ref{sec:proc_exec}) quando questo viene messo in
1690 Nel caso più comune il passaggio di argomenti ed opzioni viene effettuato
1691 dalla shell, che si incarica di leggere la linea di comando con cui si lancia
1692 il programma e di effettuarne la scansione (il cosiddetto \textit{parsing})
1693 per individuare le parole che la compongono, ciascuna delle quali potrà essere
1694 considerata un argomento o un'opzione.
1696 Di norma per individuare le parole che andranno a costituire la lista degli
1697 argomenti viene usato come carattere di separazione lo spazio o il tabulatore,
1698 ma la cosa dipende ovviamente dalle modalità con cui si effettua la scansione
1699 e dalle convenzioni adottate dal programma che la esegue: ad esempio la shell
1700 consente di proteggere con opportuni caratteri di controllo argomenti che
1701 contengono degli spazi evitando di spezzarli in parole diverse.
1705 % \includegraphics[width=13cm]{img/argv_argc}
1706 % \includegraphics[width=13cm]{img/argv_argc}
1707 \begin{tikzpicture}[>=stealth]
1708 \draw (0.5,2.5) rectangle (3.5,3);
1709 \draw (2,2.75) node {\texttt{argc = 5}};
1710 \draw (5,2.5) rectangle (8,3);
1711 \draw (6.5,2.75) node {\texttt{argv[0]}};
1712 \draw [->] (8,2.75) -- (9,2.75);
1713 \draw (9,2.75) node [anchor=west] {\texttt{"touch"}};
1714 \draw (5,2) rectangle (8,2.5);
1715 \draw (6.5,2.25) node {\texttt{argv[1]}};
1716 \draw [->] (8,2.25) -- (9,2.25);
1717 \draw (9,2.25) node [anchor=west] {\texttt{"-r"}};
1718 \draw (5,1.5) rectangle (8,2);
1719 \draw (6.5,1.75) node {\texttt{argv[2]}};
1720 \draw [->] (8,1.75) -- (9,1.75);
1721 \draw (9,1.75) node [anchor=west] {\texttt{"riferimento.txt"}};
1722 \draw (5,1.0) rectangle (8,1.5);
1723 \draw (6.5,1.25) node {\texttt{argv[3]}};
1724 \draw [->] (8,1.25) -- (9,1.25);
1725 \draw (9,1.25) node [anchor=west] {\texttt{"-m"}};
1726 \draw (5,0.5) rectangle (8,1.0);
1727 \draw (6.5,0.75) node {\texttt{argv[4]}};
1728 \draw [->] (8,0.75) -- (9,0.75);
1729 \draw (9,0.75) node [anchor=west] {\texttt{"questofile.txt"}};
1730 \draw (4.25,3.5) node{\texttt{"touch -r riferimento.txt -m questofile.txt"}};
1733 \caption{Esempio dei valori di \param{argv} e \param{argc} generati nella
1734 scansione di una riga di comando.}
1735 \label{fig:proc_argv_argc}
1738 Indipendentemente da come viene eseguita, il risultato finale della scansione
1739 dovrà comunque essere la costruzione del vettore di puntatori \param{argv} in
1740 cui si devono inserire in successione i puntatori alle stringhe costituenti i
1741 vari argomenti ed opzioni da passare al programma, e della
1742 variabile \param{argc} che deve essere inizializzata al numero di stringhe
1743 contenute in \param{argv}. Nel caso della shell questo comporta ad esempio che
1744 il primo argomento sia sempre il nome del programma. Un esempio di questo
1745 meccanismo è mostrato in fig.~\ref{fig:proc_argv_argc}, che illustra il
1746 risultato della scansione di una riga di comando.
1749 \subsection{La gestione delle opzioni}
1750 \label{sec:proc_opt_handling}
1752 In generale un programma Unix riceve da linea di comando sia gli argomenti che
1753 le opzioni, queste ultime sono standardizzate per essere riconosciute come
1754 tali: un elemento di \param{argv} successivo al primo che inizia con il
1755 carattere ``\texttt{-}'' e che non sia un singolo ``\texttt{-}'' o un
1756 ``\texttt{-{}-}'' viene considerato un'opzione. In genere le opzioni sono
1757 costituite da una lettera singola (preceduta dal carattere ``\texttt{-}'') e
1758 possono avere o no un parametro associato. Un esempio tipico può essere quello
1759 mostrato in fig.~\ref{fig:proc_argv_argc}. In quel caso le opzioni sono
1760 \cmd{-r} e \cmd{-m} e la prima vuole un parametro mentre la seconda no
1761 (\cmd{questofile.txt} è un argomento del programma, non un parametro di
1764 Per gestire le opzioni all'interno degli argomenti a linea di comando passati
1765 in \param{argv} la libreria standard del C fornisce la funzione
1766 \funcd{getopt}, che ha il seguente prototipo:
1770 \fdecl{int getopt(int argc, char * const argv[], const char *optstring)}
1771 \fdesc{Esegue la scansione delle opzioni negli argomenti della funzione
1774 {Ritorna il carattere che segue l'opzione, ``\texttt{:}'' se manca un
1775 parametro all'opzione, ``\texttt{?}'' se l'opzione è sconosciuta, e $-1$ se
1776 non esistono altre opzioni.}
1779 Questa funzione prende come argomenti le due variabili \param{argc} e
1780 \param{argv} che devono essere quelle passate come argomenti di \code{main}
1781 all'esecuzione del programma, ed una stringa \param{optstring} che indica
1782 quali sono le opzioni valide. La funzione effettua la scansione della lista
1783 degli argomenti ricercando ogni stringa che comincia con il carattere
1784 ``\texttt{-}'' e ritorna ogni volta che trova un'opzione valida.
1786 La stringa \param{optstring} indica quali sono le opzioni riconosciute ed è
1787 costituita da tutti i caratteri usati per identificare le singole opzioni, se
1788 l'opzione ha un parametro al carattere deve essere fatto seguire il carattere
1789 di due punti (``\texttt{:}''); nel caso di fig.~\ref{fig:proc_argv_argc} ad
1790 esempio la stringa di opzioni avrebbe dovuto contenere \texttt{"r:m"}.
1792 La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
1793 funzione all'interno di un ciclo, fintanto che essa non ritorna il valore $-1$
1794 che indica che non ci sono più opzioni. Nel caso si incontri un'opzione non
1795 dichiarata in \param{optstring} viene ritornato il carattere ``\texttt{?}''
1796 mentre se un'opzione che lo richiede non è seguita da un parametro viene
1797 ritornato il carattere ``\texttt{:}'', infine se viene incontrato il valore
1798 ``\texttt{-{}-}'' la scansione viene considerata conclusa, anche se vi sono
1799 altri elementi di \param{argv} che cominciano con il carattere ``\texttt{-}''.
1801 \begin{figure}[!htb]
1802 \footnotesize \centering
1803 \begin{minipage}[c]{\codesamplewidth}
1804 \includecodesample{listati/option_code.c}
1807 \caption{Esempio di codice per la gestione delle opzioni.}
1808 \label{fig:proc_options_code}
1811 Quando \func{getopt} trova un'opzione fra quelle indicate in \param{optstring}
1812 essa ritorna il valore numerico del carattere, in questo modo si possono
1813 eseguire azioni specifiche usando uno \instruction{switch}; la funzione
1814 inoltre inizializza alcune \index{variabili!globali} variabili globali:
1816 \item \var{char *optarg} contiene il puntatore alla stringa parametro
1818 \item \var{int optind} alla fine della scansione restituisce l'indice del
1819 primo elemento di \param{argv} che non è un'opzione.
1820 \item \var{int opterr} previene, se posto a zero, la stampa di un messaggio
1821 di errore in caso di riconoscimento di opzioni non definite.
1822 \item \var{int optopt} contiene il carattere dell'opzione non riconosciuta.
1825 In fig.~\ref{fig:proc_options_code} si è mostrata la sezione del programma
1826 \file{fork\_test.c}, che useremo nel prossimo capitolo per effettuare dei test
1827 sulla creazione dei processi, deputata alla decodifica delle opzioni a riga di
1828 comando da esso supportate.
1830 Si può notare che si è anzitutto (\texttt{\small 1}) disabilitata la stampa di
1831 messaggi di errore per opzioni non riconosciute, per poi passare al ciclo per
1832 la verifica delle opzioni (\texttt{\small 2-27}); per ciascuna delle opzioni
1833 possibili si è poi provveduto ad un'azione opportuna, ad esempio per le tre
1834 opzioni che prevedono un parametro si è effettuata la decodifica del medesimo,
1835 il cui indirizzo è contenuto nella variabile \var{optarg}), avvalorando la
1836 relativa variabile (\texttt{\small 12-14}, \texttt{\small 15-17} e
1837 \texttt{\small 18-20}). Completato il ciclo troveremo in \var{optind}
1838 l'indice in \code{argv[]} del primo degli argomenti rimanenti nella linea di
1841 Normalmente \func{getopt} compie una permutazione degli elementi di
1842 \param{argv} cosicché alla fine della scansione gli elementi che non sono
1843 opzioni sono spostati in coda al vettore. Oltre a questa esistono altre due
1844 modalità di gestire gli elementi di \param{argv}; se \param{optstring} inizia
1845 con il carattere ``\texttt{+}'' (o è impostata la variabile di ambiente
1846 \macro{POSIXLY\_CORRECT}) la scansione viene fermata non appena si incontra un
1847 elemento che non è un'opzione.
1849 L'ultima modalità, usata quando un programma può gestire la mescolanza fra
1850 opzioni e argomenti, ma se li aspetta in un ordine definito, si attiva
1851 quando \param{optstring} inizia con il carattere ``\texttt{-}''. In questo caso
1852 ogni elemento che non è un'opzione viene considerato comunque un'opzione e
1853 associato ad un valore di ritorno pari ad 1, questo permette di identificare
1854 gli elementi che non sono opzioni, ma non effettua il riordinamento del
1855 vettore \param{argv}.
1858 \subsection{Le variabili di ambiente}
1859 \label{sec:proc_environ}
1861 \index{variabili!di~ambiente|(}
1862 Oltre agli argomenti passati a linea di comando esiste un'altra modalità che
1863 permette di trasferire ad un processo delle informazioni in modo da
1864 modificarne il comportamento. Ogni processo infatti riceve dal sistema, oltre
1865 alle variabili \param{argv} e \param{argc} anche un \textsl{ambiente} (in
1866 inglese \textit{environment}); questo viene espresso nella forma di una lista
1867 (chiamata \textit{environment list}) delle cosiddette \textsl{variabili di
1868 ambiente}, i valori di queste variabili possono essere poi usati dal
1871 Anche in questo caso la lista delle \textsl{variabili di ambiente} deve essere
1872 costruita ed utilizzata nella chiamata alla funzione \func{exec} (torneremo su
1873 questo in sez.~\ref{sec:proc_exec}) quando questo viene lanciato. Come per la
1874 lista degli argomenti anche questa lista è un vettore di puntatori a
1875 caratteri, ciascuno dei quali punta ad una stringa, terminata da un
1876 \val{NULL}. A differenza di \code{argv[]} in questo caso non si ha una
1877 lunghezza del vettore data da un equivalente di \param{argc}, ma la lista è
1878 terminata da un puntatore nullo.
1880 L'indirizzo della lista delle variabili di ambiente è passato attraverso la
1881 \index{variabili!globali} variabile globale \var{environ}, che viene definita
1882 automaticamente per ciascun processo, e a cui si può accedere attraverso una
1883 semplice dichiarazione del tipo:
1884 \includecodesnip{listati/env_ptr.c}
1885 un esempio della struttura di questa lista, contenente alcune delle variabili
1886 più comuni che normalmente sono definite dal sistema, è riportato in
1887 fig.~\ref{fig:proc_envirno_list}.
1890 % \includegraphics[width=15 cm]{img/environ_var}
1891 \begin{tikzpicture}[>=stealth]
1892 \draw (2,3.5) node {\textsf{Environment pointer}};
1893 \draw (6,3.5) node {\textsf{Environment list}};
1894 \draw (10.5,3.5) node {\textsf{Environment string}};
1895 \draw (0.5,2.5) rectangle (3.5,3);
1896 \draw (2,2.75) node {\texttt{environ}};
1897 \draw [->] (3.5,2.75) -- (4.5,2.75);
1898 \draw (4.5,2.5) rectangle (7.5,3);
1899 \draw (6,2.75) node {\texttt{environ[0]}};
1900 \draw (4.5,2) rectangle (7.5,2.5);
1901 \draw (6,2.25) node {\texttt{environ[1]}};
1902 \draw (4.5,1.5) rectangle (7.5,2);
1903 \draw (4.5,1) rectangle (7.5,1.5);
1904 \draw (4.5,0.5) rectangle (7.5,1);
1905 \draw (4.5,0) rectangle (7.5,0.5);
1906 \draw (6,0.25) node {\texttt{NULL}};
1907 \draw [->] (7.5,2.75) -- (8.5,2.75);
1908 \draw (8.5,2.75) node[right] {\texttt{HOME=/home/piccardi}};
1909 \draw [->] (7.5,2.25) -- (8.5,2.25);
1910 \draw (8.5,2.25) node[right] {\texttt{PATH=:/bin:/usr/bin}};
1911 \draw [->] (7.5,1.75) -- (8.5,1.75);
1912 \draw (8.5,1.75) node[right] {\texttt{SHELL=/bin/bash}};
1913 \draw [->] (7.5,1.25) -- (8.5,1.25);
1914 \draw (8.5,1.25) node[right] {\texttt{EDITOR=emacs}};
1915 \draw [->] (7.5,0.75) -- (8.5,0.75);
1916 \draw (8.5,0.75) node[right] {\texttt{OSTYPE=linux-gnu}};
1918 \caption{Esempio di lista delle variabili di ambiente.}
1919 \label{fig:proc_envirno_list}
1922 Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
1923 \textsl{\texttt{NOME=valore}} ed in questa forma che le funzioni di gestione
1924 che vedremo a breve se le aspettano, se pertanto si dovesse costruire
1925 manualmente un ambiente si abbia cura di rispettare questa convenzione.
1926 Inoltre alcune variabili, come quelle elencate in
1927 fig.~\ref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
1928 da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
1929 usare nomi espressi in caratteri maiuscoli.\footnote{ma si tratta solo di una
1930 convenzione, niente vieta di usare caratteri minuscoli, come avviene in vari
1933 Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
1934 riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
1935 costituiscono un modo comodo per definire un comportamento specifico senza
1936 dover ricorrere all'uso di opzioni a linea di comando o di file di
1937 configurazione. É di norma cura della shell, quando esegue un comando, passare
1938 queste variabili al programma messo in esecuzione attraverso un uso opportuno
1939 delle relative chiamate (si veda sez.~\ref{sec:proc_exec}).
1941 La shell ad esempio ne usa molte per il suo funzionamento, come \envvar{PATH}
1942 per indicare la lista delle directory in cui effettuare la ricerca dei comandi
1943 o \envvar{PS1} per impostare il proprio \textit{prompt}. Alcune di esse, come
1944 \envvar{HOME}, \envvar{USER}, ecc. sono invece definite al login (per i
1945 dettagli si veda sez.~\ref{sec:sess_login}), ed in genere è cura della propria
1946 distribuzione definire le opportune variabili di ambiente in uno script di
1947 avvio. Alcune servono poi come riferimento generico per molti programmi, come
1948 \envvar{EDITOR} che indica l'editor preferito da invocare in caso di
1949 necessità. Una in particolare, \envvar{LANG}, serve a controllare la
1950 localizzazione del programma
1951 %(su cui torneremo in sez.~\ref{sec:proc_localization})
1952 per adattarlo alla lingua ed alle convezioni
1955 Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
1956 comuni), come riportato in tab.~\ref{tab:proc_env_var}. GNU/Linux le supporta
1957 tutte e ne definisce anche altre, in particolare poi alcune funzioni di
1958 libreria prevedono la presenza di specifiche variabili di ambiente che ne
1959 modificano il comportamento, come quelle usate per indicare una localizzazione
1960 e quelle per indicare un fuso orario; una lista più completa che comprende
1961 queste ed ulteriori variabili si può ottenere con il comando \cmd{man 7
1967 \begin{tabular}[c]{|l|c|c|c|l|}
1969 \textbf{Variabile} & \textbf{POSIX} & \textbf{XPG3}
1970 & \textbf{Linux} & \textbf{Descrizione} \\
1973 \texttt{USER} &$\bullet$&$\bullet$&$\bullet$& Nome utente.\\
1974 \texttt{LOGNAME}&$\bullet$&$\bullet$&$\bullet$& Nome di login.\\
1975 \texttt{HOME} &$\bullet$&$\bullet$&$\bullet$& Directory base
1977 \texttt{LANG} &$\bullet$&$\bullet$&$\bullet$& Localizzazione.\\
1978 \texttt{PATH} &$\bullet$&$\bullet$&$\bullet$& Elenco delle directory
1980 \texttt{PWD} &$\bullet$&$\bullet$&$\bullet$& Directory corrente.\\
1981 \texttt{SHELL} &$\bullet$&$\bullet$&$\bullet$& Shell in uso.\\
1982 \texttt{TERM} &$\bullet$&$\bullet$&$\bullet$& Tipo di terminale.\\
1983 \texttt{PAGER} &$\bullet$&$\bullet$&$\bullet$& Programma per vedere i
1985 \texttt{EDITOR} &$\bullet$&$\bullet$&$\bullet$& Editor preferito.\\
1986 \texttt{BROWSER}&$\bullet$&$\bullet$&$\bullet$& Browser preferito.\\
1987 \texttt{TMPDIR} &$\bullet$&$\bullet$&$\bullet$& Directory dei file
1991 \caption{Esempi delle variabili di ambiente più comuni definite da vari
1993 \label{tab:proc_env_var}
1996 Lo standard ANSI C prevede l'esistenza di un ambiente, e pur non entrando
1997 nelle specifiche di come sono strutturati i contenuti, definisce la funzione
1998 \funcd{getenv} che permette di ottenere i valori delle variabili di ambiente;
2003 \fdecl{char *getenv(const char *name)}
2004 \fdesc{Cerca una variabile di ambiente del processo.}
2006 {La funzione ritorna il puntatore alla stringa contenente il valore della
2007 variabile di ambiente in caso di successo e \val{NULL} per un errore.}
2010 La funzione effettua una ricerca nell'ambiente del processo cercando una
2011 variabile il cui nome corrisponda a quanto indicato con
2012 l'argomento \param{name}, ed in caso di successo ritorna il puntatore alla
2013 stringa che ne contiene il valore, nella forma ``\texttt{NOME=valore}''.
2018 \begin{tabular}[c]{|l|c|c|c|c|c|c|}
2020 \textbf{Funzione} & \textbf{ANSI C} & \textbf{POSIX.1} & \textbf{XPG3} &
2021 \textbf{SVr4} & \textbf{BSD} & \textbf{Linux} \\
2024 \func{getenv} & $\bullet$ & $\bullet$ & $\bullet$
2025 & $\bullet$ & $\bullet$ & $\bullet$ \\
2026 \func{setenv} & -- & -- & --
2027 & -- & $\bullet$ & $\bullet$ \\
2028 \func{unsetenv}& -- & -- & --
2029 & -- & $\bullet$ & $\bullet$ \\
2030 \func{putenv} & -- & opz. & $\bullet$
2031 & -- & $\bullet$ & $\bullet$ \\
2032 \func{clearenv}& -- & opz. & --
2033 & -- & -- & $\bullet$ \\
2036 \caption{Funzioni per la gestione delle variabili di ambiente.}
2037 \label{tab:proc_env_func}
2040 Oltre a questa funzione di lettura, che è l'unica definita dallo standard ANSI
2041 C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
2042 utilizzare per impostare, modificare e per cancellare le variabili di
2043 ambiente. Uno schema delle funzioni previste nei vari standard e disponibili
2044 in Linux è riportato in tab.~\ref{tab:proc_env_func}. Tutte le funzioni sono
2045 state comunque inserite nello standard POSIX.1-2001, ad eccetto di
2046 \func{clearenv} che è stata rigettata.
2048 In Linux sono definite tutte le funzioni elencate in
2049 tab.~\ref{tab:proc_env_func},\footnote{in realtà nelle libc4 e libc5 sono
2050 definite solo le prime quattro, \func{clearenv} è stata introdotta con la
2051 \acr{glibc} 2.0.} anche se parte delle funzionalità sono ridondanti. La
2052 prima funzione di manipolazione che prenderemo in considerazione è
2053 \funcd{putenv}, che consente di aggiungere, modificare e cancellare una
2054 variabile di ambiente; il suo prototipo è:
2057 \fdecl{int putenv(char *string)}
2058 \fdesc{Inserisce, modifica o rimuove una variabile d'ambiente.}
2060 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, che può
2061 essere solo \errval{ENOMEM}.}
2064 La funzione prende come argomento una stringa analoga a quella restituita da
2065 \func{getenv} e sempre nella forma ``\texttt{NOME=valore}''. Se la variabile
2066 specificata (nel caso \texttt{NOME}) non esiste la stringa sarà aggiunta
2067 all'ambiente, se invece esiste il suo valore sarà impostato a quello
2068 specificato dal contenuto di \param{string} (nel caso \texttt{valore}). Se
2069 invece si passa come argomento solo il nome di una variabile di ambiente
2070 (cioè \param{string} è nella forma ``\texttt{NOME}'' e non contiene il
2071 carattere ``\texttt{=}'') allora questa, se presente nell'ambiente, verrà
2074 Si tenga presente che, seguendo lo standard SUSv2, le \acr{glibc} successive
2075 alla versione 2.1.2 aggiungono direttamente \param{string} nella lista delle
2076 variabili di ambiente illustrata in fig.~\ref{fig:proc_envirno_list}
2077 sostituendo il relativo puntatore;\footnote{il comportamento è lo stesso delle
2078 vecchie \acr{libc4} e \acr{libc5}; nella \acr{glibc}, dalla versione 2.0
2079 alla 2.1.1, veniva invece fatta una copia, seguendo il comportamento di
2080 BSD4.4; dato che questo può dar luogo a perdite di memoria e non rispetta lo
2081 standard il comportamento è stato modificato a partire dalle 2.1.2,
2082 eliminando anche, sempre in conformità a SUSv2, l'attributo \direct{const}
2083 dal prototipo.} pertanto ogni cambiamento alla stringa in questione si
2084 riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
2085 questa funzione una \index{variabili!automatiche} variabile automatica (per
2086 evitare i problemi esposti in sez.~\ref{sec:proc_var_passing}). Benché non sia
2087 richiesto dallo standard nelle versioni della \acr{glibc} a partire dalla 2.1
2088 la funzione è rientrante (vedi sez.~\ref{sec:proc_reentrant}).
2090 Infine quando una chiamata a \func{putenv} comporta la necessità di creare una
2091 nuova versione del vettore \var{environ} questo sarà allocato automaticamente,
2092 ma la versione corrente sarà deallocata solo se anch'essa è risultante da
2093 un'allocazione fatta in precedenza da un'altra \func{putenv}. Questo avviene
2094 perché il vettore delle variabili di ambiente iniziale, creato dalla chiamata
2095 ad \func{exec} (vedi sez.~\ref{sec:proc_exec}) è piazzato nella memoria al di
2096 sopra dello \itindex{stack} \textit{stack}, (vedi
2097 fig.~\ref{fig:proc_mem_layout}) e non nello \itindex{heap} \textit{heap} e
2098 quindi non può essere deallocato. Inoltre la memoria associata alle variabili
2099 di ambiente eliminate non viene liberata.
2101 Come alternativa a \func{putenv} si può usare la funzione \funcd{setenv} che
2102 però consente solo di aggiungere o modificare una variabile di ambiente; il
2107 \fdecl{int setenv(const char *name, const char *value, int overwrite)}
2108 \fdesc{Inserisce o modifica una variabile di ambiente.}
2110 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
2111 nel qual caso \var{errno} assumerà uno dei valori:
2113 \item[\errcode{EINVAL}] \param{name} è \val{NULL} o una stringa di lunghezza
2114 nulla o che contiene il carattere ``\texttt{=}''.
2115 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per aggiungere una nuova
2116 variabile all'ambiente.
2120 La funzione consente di specificare separatamente nome e valore della
2121 variabile di ambiente da aggiungere negli argomenti \param{name}
2122 e \param{value}. Se la variabile è già presente nell'ambiente
2123 l'argomento \param{overwrite} specifica il comportamento della funzione, se
2124 diverso da zero sarà sovrascritta, se uguale a zero sarà lasciata immutata. A
2125 differenza di \func{putenv} la funzione esegue delle copie del contenuto degli
2126 argomenti \param{name} e \param{value} e non è necessario preoccuparsi di
2127 allocarli in maniera permanente.
2129 La cancellazione di una variabile di ambiente viene invece gestita
2130 esplicitamente con \funcd{unsetenv}, il cui prototipo è:
2134 \fdecl{int unsetenv(const char *name)}
2135 \fdesc{Rimuove una variabile di ambiente.}
2137 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
2138 nel qual caso \var{errno} assumerà uno dei valori:
2140 \item[\errcode{EINVAL}] \param{name} è \val{NULL} o una stringa di lunghezza
2141 nulla o che contiene il carattere ``\texttt{=}''.
2145 La funzione richiede soltanto il nome della variabile di ambiente
2146 nell'argomento \param{name}, se la variabile non esiste la funzione ritorna
2147 comunque con un valore di successo.\footnote{questo con le versioni della
2148 \acr{glibc} successive la 2.2.2, per le precedenti \func{unsetenv} era
2149 definita come \texttt{void} e non restituiva nessuna informazione.}
2151 L'ultima funzione per la gestione dell'ambiente è
2152 \funcd{clearenv},\footnote{che come accennato è l'unica non presente nello
2153 standard POSIX.1-2000, ed è disponibili solo per versioni della \acr{glibc}
2154 a partire dalla 2.0; per poterla utilizzare occorre aver definito le macro
2155 \macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE}.} che viene usata per
2156 cancellare completamente tutto l'ambiente; il suo prototipo è:
2160 \fdecl{int clearenv(void)}
2161 \fdesc{Cancella tutto l'ambiente.}
2163 {La funzione ritorna $0$ in caso di successo e un valore diverso da zero per
2167 In genere si usa questa funzione in maniera precauzionale per evitare i
2168 problemi di sicurezza connessi nel trasmettere ai programmi che si invocano un
2169 ambiente che può contenere dei dati non controllati, le cui variabili possono
2170 causare effetti indesiderati. Con l'uso della funzione si provvede alla
2171 cancellazione di tutto l'ambiente originale in modo da poterne costruirne una
2172 versione ``\textsl{sicura}'' da zero.
2174 \index{variabili!di~ambiente|)}
2177 % \subsection{La localizzazione}
2178 % \label{sec:proc_localization}
2180 % Abbiamo accennato in sez.~\ref{sec:proc_environ} come la variabile di ambiente
2181 % \envvar{LANG} sia usata per indicare ai processi il valore della cosiddetta
2182 % \textsl{localizzazione}. Si tratta di una funzionalità fornita dalle librerie
2183 % di sistema\footnote{prenderemo in esame soltanto il caso della \acr{glibc}.}
2184 % che consente di gestire in maniera automatica sia la lingua in cui vengono
2185 % stampati i vari messaggi (come i messaggi associati agli errori che vedremo in
2186 % sez.~\ref{sec:sys_strerror}) che le convenzioni usate nei vari paesi per una
2187 % serie di aspetti come il formato dell'ora, quello delle date, gli ordinamenti
2188 % alfabetici, le espressioni della valute, ecc.
2192 % La localizzazione di un programma si può selezionare con la
2194 % In realtà perché un programma sia effettivamente localizzato non è sufficiente
2196 % TODO trattare, quando ci sarà tempo, setlocale ed il resto
2199 %\subsection{Opzioni in formato esteso}
2200 %\label{sec:proc_opt_extended}
2202 %Oltre alla modalità ordinaria di gestione delle opzioni trattata in
2203 %sez.~\ref{sec:proc_opt_handling} le \acr{glibc} forniscono una modalità
2204 %alternativa costituita dalle cosiddette \textit{long-options}, che consente di
2205 %esprimere le opzioni in una forma più descrittiva che nel caso più generale è
2206 %qualcosa del tipo di ``\texttt{-{}-option-name=parameter}''.
2208 %(NdA: questa parte verrà inserita in seguito).
2210 % TODO opzioni in formato esteso
2212 % TODO trattare il vettore ausiliario e getauxval (vedi
2213 % http://lwn.net/Articles/519085/)
2216 \section{Problematiche di programmazione generica}
2217 \label{sec:proc_gen_prog}
2219 Benché questo non sia un libro sul linguaggio C, è opportuno affrontare alcune
2220 delle problematiche generali che possono emergere nella programmazione con
2221 questo linguaggio e di quali precauzioni o accorgimenti occorre prendere per
2222 risolverle. Queste problematiche non sono specifiche di sistemi unix-like o
2223 multitasking, ma avendo trattato in questo capitolo il comportamento dei
2224 processi visti come entità a sé stanti, le riportiamo qui.
2227 \subsection{Il passaggio di variabili e valori di ritorno nelle funzioni}
2228 \label{sec:proc_var_passing}
2230 Una delle caratteristiche standard del C è che le variabili vengono passate
2231 alle funzioni che si invocano in un programma attraverso un meccanismo che
2232 viene chiamato \textit{by value}, diverso ad esempio da quanto avviene con il
2233 Fortran, dove le variabili sono passate, come suol dirsi, \textit{by
2234 reference}, o dal C++ dove la modalità del passaggio può essere controllata
2235 con l'operatore \cmd{\&}.
2237 Il passaggio di una variabile \textit{by value} significa che in realtà quello
2238 che viene passato alla funzione è una copia del valore attuale di quella
2239 variabile, copia che la funzione potrà modificare a piacere, senza che il
2240 valore originale nella funzione chiamante venga toccato. In questo modo non
2241 occorre preoccuparsi di eventuali effetti delle operazioni svolte nella
2242 funzione stessa sulla variabile passata come argomento.
2244 Questo però va inteso nella maniera corretta. Il passaggio \textit{by value}
2245 vale per qualunque variabile, puntatori compresi; quando però in una funzione
2246 si usano dei puntatori (ad esempio per scrivere in un buffer) in realtà si va
2247 a modificare la zona di memoria a cui essi puntano, per cui anche se i
2248 puntatori sono copie, i dati a cui essi puntano saranno sempre gli stessi, e
2249 le eventuali modifiche avranno effetto e saranno visibili anche nella funzione
2252 Nella maggior parte delle funzioni di libreria e delle \textit{system call} i
2253 puntatori vengono usati per scambiare dati (attraverso i buffer o le strutture
2254 a cui fanno riferimento) e le variabili normali vengono usate per specificare
2255 argomenti; in genere le informazioni a riguardo dei risultati vengono passate
2256 alla funzione chiamante attraverso il valore di ritorno. È buona norma
2257 seguire questa pratica anche nella programmazione normale.
2259 Talvolta però è necessario che la funzione possa restituire indietro alla
2260 funzione chiamante un valore relativo ad uno dei suoi argomenti usato anche in
2261 ingresso. Per far questo si usa il cosiddetto \itindex{value~result~argument}
2262 \textit{value result argument}, si passa cioè, invece di una normale
2263 variabile, un puntatore alla stessa. Gli esempi di questa modalità di
2264 passaggio sono moltissimi, ad esempio essa viene usata nelle funzioni che
2265 gestiscono i socket (in sez.~\ref{sec:TCP_functions}), in cui, per permettere
2266 al kernel di restituire informazioni sulle dimensioni delle strutture degli
2267 indirizzi utilizzate, viene usato proprio questo meccanismo.
2269 Occorre tenere ben presente questa differenza, perché le variabili passate in
2270 maniera ordinaria, che vengono inserite nello \textit{stack}, cessano di
2271 esistere al ritorno di una funzione, ed ogni loro eventuale modifica
2272 all'interno della stessa sparisce con la conclusione della stessa, per poter
2273 passare delle informazioni occorre quindi usare un puntatore che faccia
2274 riferimento ad un indirizzo accessibile alla funzione chiamante.
2276 Questo requisito di accessibilità è fondamentale, infatti dei possibili
2277 problemi che si possono avere con il passaggio dei dati è quello di restituire
2278 alla funzione chiamante dei dati che sono contenuti in una
2279 \index{variabili!automatiche} variabile automatica. Ovviamente quando la
2280 funzione ritorna la sezione dello \itindex{stack} \textit{stack} che conteneva
2281 la \index{variabili!automatiche} variabile automatica (si ricordi quanto detto
2282 in sez.~\ref{sec:proc_mem_alloc}) verrà liberata automaticamente e potrà
2283 essere riutilizzata all'invocazione di un'altra funzione, con le immaginabili
2284 conseguenze, quasi invariabilmente catastrofiche, di sovrapposizione e
2285 sovrascrittura dei dati.
2287 Per questo una delle regole fondamentali della programmazione in C è che
2288 all'uscita di una funzione non deve restare nessun riferimento alle sue
2289 \index{variabili!automatiche} variabili locali. Qualora sia necessario
2290 utilizzare delle variabili che devono essere viste anche dalla funzione
2291 chiamante queste devono essere allocate esplicitamente, o in maniera statica
2292 usando variabili globali o dichiarate come \direct{extern},\footnote{la
2293 direttiva \direct{extern} informa il compilatore che la variabile che si è
2294 dichiarata in una funzione non è da considerarsi locale, ma globale, e per
2295 questo allocata staticamente e visibile da tutte le funzioni dello stesso
2296 programma.} o dinamicamente con una delle funzioni della famiglia
2297 \func{malloc}, passando opportunamente il relativo puntatore fra le funzioni.
2300 \subsection{Il passaggio di un numero variabile di argomenti}
2301 \label{sec:proc_variadic}
2303 \index{funzioni!variadic|(}
2305 Come vedremo nei capitoli successivi, non sempre è possibile specificare un
2306 numero fisso di argomenti per una funzione. Lo standard ISO C prevede nella
2307 sua sintassi la possibilità di definire delle \textit{variadic function} che
2308 abbiano un numero variabile di argomenti, attraverso l'uso nella dichiarazione
2309 della funzione dello speciale costrutto ``\texttt{...}'', che viene chiamato
2312 Lo standard però non provvede a livello di linguaggio alcun meccanismo con cui
2313 dette funzioni possono accedere ai loro argomenti. L'accesso viene pertanto
2314 realizzato a livello della libreria standard del C che fornisce gli strumenti
2315 adeguati. L'uso di una \textit{variadic function} prevede quindi tre punti:
2317 \item \textsl{dichiarare} la funzione come \textit{variadic} usando un
2318 prototipo che contenga una \textit{ellipsis};
2319 \item \textsl{definire} la funzione come \textit{variadic} usando la stessa
2320 \textit{ellipsis}, ed utilizzare le apposite macro che consentono la
2321 gestione di un numero variabile di argomenti;
2322 \item \textsl{invocare} la funzione specificando prima gli argomenti fissi, ed
2323 a seguire quelli addizionali.
2326 Lo standard ISO C prevede che una \textit{variadic function} abbia sempre
2327 almeno un argomento fisso. Prima di effettuare la dichiarazione deve essere
2328 incluso l'apposito \textit{header file} \headfile{stdarg.h}; un esempio di
2329 dichiarazione è il prototipo della funzione \func{execl} che vedremo in
2330 sez.~\ref{sec:proc_exec}:
2331 \includecodesnip{listati/exec_sample.c}
2332 in questo caso la funzione prende due argomenti fissi ed un numero variabile
2333 di altri argomenti, che andranno a costituire gli elementi successivi al primo
2334 del vettore \param{argv} passato al nuovo processo. Lo standard ISO C richiede
2335 inoltre che l'ultimo degli argomenti fissi sia di tipo
2336 \textit{self-promoting}\footnote{il linguaggio C prevede che quando si
2337 mescolano vari tipi di dati, alcuni di essi possano essere \textsl{promossi}
2338 per compatibilità; ad esempio i tipi \ctyp{float} vengono convertiti
2339 automaticamente a \ctyp{double} ed i \ctyp{char} e gli \ctyp{short} ad
2340 \ctyp{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
2341 a sé stesso.} il che esclude vettori, puntatori a funzioni e interi di tipo
2342 \ctyp{char} o \ctyp{short} (con segno o meno). Una restrizione ulteriore di
2343 alcuni compilatori è di non dichiarare l'ultimo argomento fisso come variabile
2344 di tipo \direct{register}.\footnote{la direttiva \direct{register} del
2345 compilatore chiede che la variabile dichiarata tale sia mantenuta, nei
2346 limiti del possibile, all'interno di un registro del processore; questa
2347 direttiva è originaria dell'epoca dai primi compilatori, quando stava al
2348 programmatore scrivere codice ottimizzato, riservando esplicitamente alle
2349 variabili più usate l'uso dei registri del processore, oggi questa direttiva
2350 è in disuso pressoché completo dato che tutti i compilatori sono normalmente
2351 in grado di valutare con maggior efficacia degli stessi programmatori quando
2352 sia il caso di eseguire questa ottimizzazione.}
2354 Una volta dichiarata la funzione il secondo passo è accedere ai vari argomenti
2355 quando la si va a definire. Gli argomenti fissi infatti hanno un loro nome, ma
2356 quelli variabili vengono indicati in maniera generica dalla
2357 \textit{ellipsis}. L'unica modalità in cui essi possono essere recuperati è
2358 pertanto quella sequenziale, in cui vengono estratti dallo \itindex{stack}
2359 \textit{stack} secondo l'ordine in cui sono stati scritti nel prototipo della
2362 Per fare questo in \headfile{stdarg.h} sono definite delle macro specifiche,
2363 previste dallo standard ISO C89, che consentono di eseguire questa operazione.
2364 La prima di queste macro è \macro{va\_start}, che inizializza opportunamente
2365 una lista degli argomenti, la sua definizione è:
2370 \fdecl{void va\_start(va\_list ap, last)}
2371 \fdesc{Inizializza una lista degli argomenti di una funzione
2376 La macro inizializza il puntatore alla lista di argomenti \param{ap} che
2377 deve essere una apposita variabile di tipo \type{va\_list}; il
2378 parametro \param{last} deve indicare il nome dell'ultimo degli argomenti fissi
2379 dichiarati nel prototipo della funzione \textit{variadic}.
2381 La seconda macro di gestione delle liste di argomenti di una funzione
2382 \textit{variadic} è \macro{va\_arg}, che restituisce in successione un
2383 argomento della lista; la sua definizione è:
2388 \fdecl{type va\_arg(va\_list ap, type)}
2389 \fdesc{Restituisce il valore del successivo argomento opzionale.}
2393 La macro restituisce il valore di un argomento, modificando opportunamente la
2394 lista \param{ap} perché una chiamata successiva restituisca l'argomento
2395 seguente. La macro richiede che si specifichi il tipo dell'argomento che si
2396 andrà ad estrarre attraverso il parametro \param{type} che sarà anche il tipo
2397 del valore da essa restituito. Si ricordi che il tipo deve essere
2398 \textit{self-promoting}.
2400 In generale è perfettamente legittimo richiedere meno argomenti di quelli che
2401 potrebbero essere stati effettivamente forniti, per cui nella esecuzione delle
2402 \macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
2403 saranno ignorati. Se invece si richiedono più argomenti di quelli
2404 effettivamente forniti si otterranno dei valori indefiniti. Si avranno
2405 risultati indefiniti anche quando si chiama \macro{va\_arg} specificando un
2406 tipo che non corrisponde a quello usato per il corrispondente argomento.
2408 Infine una volta completata l'estrazione occorre indicare che si sono concluse
2409 le operazioni con la macro \macro{va\_end}, la cui definizione è:
2414 \fdecl{void va\_end(va\_list ap)}
2415 \fdesc{Conclude l'estrazione degli argomenti di una funzione
2420 Dopo l'uso di \macro{va\_end} la variabile \param{ap} diventa indefinita e
2421 successive chiamate a \macro{va\_arg} non funzioneranno. Nel caso del
2422 \cmd{gcc} l'uso di \macro{va\_end} può risultare inutile, ma è comunque
2423 necessario usarla per chiarezza del codice, per compatibilità con diverse
2424 implementazioni e per eventuali eventuali modifiche future a questo
2427 Riassumendo la procedura da seguire per effettuare l'estrazione degli
2428 argomenti di una funzione \textit{variadic} è la seguente:
2430 \item inizializzare una lista degli argomenti attraverso la macro
2432 \item accedere agli argomenti con chiamate successive alla macro
2433 \macro{va\_arg}: la prima chiamata restituirà il primo argomento, la seconda
2434 il secondo e così via;
2435 \item dichiarare la conclusione dell'estrazione degli argomenti invocando la
2436 macro \macro{va\_end}.
2439 Si tenga presente che si possono usare anche più liste degli argomenti,
2440 ciascuna di esse andrà inizializzata con \macro{va\_start} e letta con
2441 \macro{va\_arg}, e ciascuna potrà essere usata per scandire la lista degli
2442 argomenti in modo indipendente. Infine ciascuna scansione dovrà essere
2443 terminata con \macro{va\_end}.
2445 Un limite di queste macro è che i passi 1) e 3) devono essere eseguiti nel
2446 corpo principale della funzione, il passo 2) invece può essere eseguito anche
2447 in un'altra funzione, passandole lista degli argomenti \param{ap}. In questo
2448 caso però al ritorno della funzione \macro{va\_arg} non può più essere usata
2449 (anche se non si era completata l'estrazione) dato che il valore di \param{ap}
2450 risulterebbe indefinito.
2452 Esistono dei casi in cui è necessario eseguire più volte la scansione degli
2453 argomenti e poter memorizzare una posizione durante la stessa. In questo caso
2454 sembrerebbe naturale copiarsi la lista degli argomenti \param{ap} con una
2455 semplice assegnazione ad un'altra variabile dello stesso tipo. Dato che una
2456 delle realizzazioni più comuni di \type{va\_list} è quella di un puntatore
2457 nello \itindex{stack} \textit{stack} all'indirizzo dove sono stati salvati gli
2458 argomenti, è assolutamente normale pensare di poter effettuare questa
2461 In generale però possono esistere anche realizzazioni diverse, ed è per questo
2462 motivo che invece che di un semplice puntatore viene \type{va\_list} è quello
2463 che viene chiamato un \index{tipo!opaco} \textsl{tipo opaco}. Si chiamano così
2464 quei tipi di dati, in genere usati da una libreria, la cui struttura interna
2465 non deve essere vista dal programma chiamante (da cui deriva il nome opaco)
2466 che li devono utilizzare solo attraverso dalle opportune funzioni di
2469 Per questo motivo una variabile di tipo \type{va\_list} non può essere
2470 assegnata direttamente ad un'altra variabile dello stesso tipo, ma lo standard
2471 ISO C99\footnote{alcuni sistemi che non hanno questa macro provvedono al suo
2472 posto \macro{\_\_va\_copy} che era il nome proposto in una bozza dello
2473 standard.} ha previsto una macro ulteriore che permette di eseguire la
2474 copia di una lista degli argomenti:
2479 \fdecl{void va\_copy(va\_list dest, va\_list src)}
2480 \fdesc{Copia la lista degli argomenti di una funzione \textit{variadic}.}
2484 La macro copia l'attuale della lista degli argomenti \param{src} su una nuova
2485 lista \param{dest}. Anche in questo caso è buona norma chiudere ogni
2486 esecuzione di una \macro{va\_copy} con una corrispondente \macro{va\_end} sul
2487 nuovo puntatore alla lista degli argomenti.
2489 La chiamata di una funzione con un numero variabile di argomenti, posto che la
2490 si sia dichiarata e definita come tale, non prevede nulla di particolare;
2491 l'invocazione è identica alle altre, con gli argomenti, sia quelli fissi che
2492 quelli opzionali, separati da virgole. Quello che però è necessario tenere
2493 presente è come verranno convertiti gli argomenti variabili.
2495 In Linux gli argomenti dello stesso tipo sono passati allo stesso modo, sia
2496 che siano fissi sia che siano opzionali (alcuni sistemi trattano diversamente
2497 gli opzionali), ma dato che il prototipo non può specificare il tipo degli
2498 argomenti opzionali, questi verranno sempre promossi, pertanto nella ricezione
2499 dei medesimi occorrerà tenerne conto (ad esempio un \ctyp{char} verrà visto da
2500 \macro{va\_arg} come \ctyp{int}).
2502 Un altro dei problemi che si devono affrontare con le funzioni con un numero
2503 variabile di argomenti è che non esiste un modo generico che permetta di
2504 stabilire quanti sono gli argomenti effettivamente passati in una chiamata.
2506 Esistono varie modalità per affrontare questo problema; una delle più
2507 immediate è quella di specificare il numero degli argomenti opzionali come uno
2508 degli argomenti fissi. Una variazione di questo metodo è l'uso di un argomento
2509 fisso per specificare anche il tipo degli argomenti variabili, come fa la
2510 stringa di formato per \func{printf} (vedi sez.~\ref{sec:file_formatted_io}).
2512 Infine una ulteriore modalità diversa, che può essere applicata solo quando il
2513 tipo degli argomenti lo rende possibile, è quella che prevede di usare un
2514 valore speciale per l'ultimo argomento, come fa ad esempio \func{execl} che
2515 usa un puntatore \val{NULL} per indicare la fine della lista degli argomenti
2516 (vedi sez.~\ref{sec:proc_exec}).
2518 \index{funzioni!variadic|)}
2520 \subsection{Il controllo di flusso non locale}
2521 \label{sec:proc_longjmp}
2523 Il controllo del flusso di un programma in genere viene effettuato con le
2524 varie istruzioni del linguaggio C; fra queste la più bistrattata è il
2525 \instruction{goto}, che viene deprecato in favore dei costrutti della
2526 programmazione strutturata, che rendono il codice più leggibile e
2527 mantenibile. Esiste però un caso in cui l'uso di questa istruzione porta
2528 all'implementazione più efficiente e più chiara anche dal punto di vista della
2529 struttura del programma: quello dell'uscita in caso di errore.
2531 \index{salto~non-locale|(}
2533 Il C però non consente di effettuare un salto ad una etichetta definita in
2534 un'altra funzione, per cui se l'errore avviene in una funzione, e la sua
2535 gestione ordinaria è in un'altra, occorre usare quello che viene chiamato un
2536 \textsl{salto non-locale}. Il caso classico in cui si ha questa necessità,
2537 citato sia in \cite{APUE} che in \cite{GlibcMan}, è quello di un programma nel
2538 cui corpo principale vengono letti dei dati in ingresso sui quali viene
2539 eseguita, tramite una serie di funzioni di analisi, una scansione dei
2540 contenuti, da cui si ottengono le indicazioni per l'esecuzione di opportune
2543 Dato che l'analisi può risultare molto complessa, ed opportunamente suddivisa
2544 in fasi diverse, la rilevazione di un errore nei dati in ingresso può accadere
2545 all'interno di funzioni profondamente annidate l'una nell'altra. In questo
2546 caso si dovrebbe gestire, per ciascuna fase, tutta la casistica del passaggio
2547 all'indietro di tutti gli errori rilevabili dalle funzioni usate nelle fasi
2548 successive. Questo comporterebbe una notevole complessità, mentre sarebbe
2549 molto più comodo poter tornare direttamente al ciclo di lettura principale,
2550 scartando l'input come errato.\footnote{a meno che, come precisa
2551 \cite{GlibcMan}, alla chiusura di ciascuna fase non siano associate
2552 operazioni di pulizia specifiche (come deallocazioni, chiusure di file,
2553 ecc.), che non potrebbero essere eseguite con un salto non-locale.}
2555 Tutto ciò può essere realizzato proprio con un salto non-locale; questo di
2556 norma viene realizzato salvando il contesto dello \itindex{stack}
2557 \textit{stack} nel punto in cui si vuole tornare in caso di errore, e
2558 ripristinandolo, in modo da tornare quando serve nella funzione da cui si era
2559 partiti. La funzione che permette di salvare il contesto dello
2560 \itindex{stack} \textit{stack} è \funcd{setjmp}, il cui prototipo è:
2564 \fdecl{int setjmp(jmp\_buf env)}
2565 \fdesc{Salva il contesto dello \textit{stack}.}
2567 {La funzione ritorna $0$ quando è chiamata direttamente ed un valore diverso
2568 da zero quando ritorna da una chiamata di \func{longjmp} che usa il contesto
2569 salvato in precedenza.}
2572 Quando si esegue la funzione il contesto corrente dello \itindex{stack}
2573 \textit{stack} viene salvato nell'argomento \param{env}, una variabile di tipo
2574 \type{jmp\_buf}\footnote{anche questo è un classico esempio di variabile di
2575 \index{tipo!opaco} \textsl{tipo opaco}.} che deve essere stata definita in
2576 precedenza. In genere le variabili di tipo \type{jmp\_buf} vengono definite
2577 come \index{variabili!globali} variabili globali in modo da poter essere viste
2578 in tutte le funzioni del programma.
2580 Quando viene eseguita direttamente la funzione ritorna sempre zero, un valore
2581 diverso da zero viene restituito solo quando il ritorno è dovuto ad una
2582 chiamata di \func{longjmp} in un'altra parte del programma che ripristina lo
2583 \itindex{stack} \textit{stack} effettuando il salto non-locale. Si tenga conto
2584 che il contesto salvato in \param{env} viene invalidato se la funzione che ha
2585 chiamato \func{setjmp} ritorna, nel qual caso un successivo uso di
2586 \func{longjmp} può comportare conseguenze imprevedibili (e di norma fatali)
2589 Come accennato per effettuare un salto non-locale ad un punto precedentemente
2590 stabilito con \func{setjmp} si usa la funzione \funcd{longjmp}; il suo
2595 \fdecl{void longjmp(jmp\_buf env, int val)}
2596 \fdesc{Ripristina il contesto dello stack.}
2598 {La funzione non ritorna.}
2601 La funzione ripristina il contesto dello \itindex{stack} \textit{stack}
2602 salvato da una chiamata a \func{setjmp} nell'argomento \param{env}. Dopo
2603 l'esecuzione della funzione il programma prosegue nel codice successivo alla
2604 chiamata della \func{setjmp} con cui si era salvato \param{env}, che
2605 restituirà il valore dell'argomento \param{val} invece di zero. Il valore
2606 dell'argomento \param{val} deve essere sempre diverso da zero, se si è
2607 specificato 0 sarà comunque restituito 1 al suo posto.
2609 In sostanza l'esecuzione di \func{longjmp} è analoga a quella di una
2610 istruzione \instruction{return}, solo che invece di ritornare alla riga
2611 successiva della funzione chiamante, il programma in questo caso ritorna alla
2612 posizione della relativa \func{setjmp}. L'altra differenza fondamentale con
2613 \instruction{return} è che il ritorno può essere effettuato anche attraverso
2614 diversi livelli di funzioni annidate.
2616 L'implementazione di queste funzioni comporta alcune restrizioni dato che esse
2617 interagiscono direttamente con la gestione dello \itindex{stack}
2618 \textit{stack} ed il funzionamento del compilatore stesso. In particolare
2619 \func{setjmp} è implementata con una macro, pertanto non si può cercare di
2620 ottenerne l'indirizzo, ed inoltre le chiamate a questa funzione sono sicure
2621 solo in uno dei seguenti casi:
2623 \item come espressione di controllo in un comando condizionale, di selezione o
2624 di iterazione (come \instruction{if}, \instruction{switch} o
2625 \instruction{while});
2626 \item come operando per un operatore di uguaglianza o confronto in una
2627 espressione di controllo di un comando condizionale, di selezione o di
2629 \item come operando per l'operatore di negazione (\code{!}) in una espressione
2630 di controllo di un comando condizionale, di selezione o di iterazione;
2631 \item come espressione a sé stante.
2634 In generale, dato che l'unica differenza fra la chiamata diretta e quella
2635 ottenuta nell'uscita con un \func{longjmp} è costituita dal valore di ritorno
2636 di \func{setjmp}, pertanto quest'ultima viene usualmente chiamata all'interno
2637 di un una istruzione \instruction{if} che permetta di distinguere i due casi.
2639 Uno dei punti critici dei salti non-locali è quello del valore delle
2640 variabili, ed in particolare quello delle \index{variabili!automatiche}
2641 variabili automatiche della funzione a cui si ritorna. In generale le
2642 \index{variabili!globali} variabili globali e \index{variabili!statiche}
2643 statiche mantengono i valori che avevano al momento della chiamata di
2644 \func{longjmp}, ma quelli delle \index{variabili!automatiche} variabili
2645 automatiche (o di quelle dichiarate \direct{register}) sono in genere
2648 Quello che succede infatti è che i valori delle variabili che sono tenute in
2649 memoria manterranno il valore avuto al momento della chiamata di
2650 \func{longjmp}, mentre quelli tenuti nei registri del processore (che nella
2651 chiamata ad un'altra funzione vengono salvati nel contesto nello
2652 \itindex{stack} \textit{stack}) torneranno al valore avuto al momento della
2653 chiamata di \func{setjmp}; per questo quando si vuole avere un comportamento
2654 coerente si può bloccare l'ottimizzazione che porta le variabili nei registri
2655 dichiarandole tutte come \direct{volatile}.\footnote{la direttiva
2656 \direct{volatile} informa il compilatore che la variabile che è dichiarata
2657 può essere modificata, durante l'esecuzione del nostro, da altri programmi.
2658 Per questo motivo occorre dire al compilatore che non deve essere mai
2659 utilizzata l'ottimizzazione per cui quanto opportuno essa viene mantenuta in
2660 un registro, poiché in questo modo si perderebbero le eventuali modifiche
2661 fatte dagli altri programmi (che avvengono solo in una copia posta in
2664 \index{salto~non-locale|)}
2667 \subsection{La \textit{endianness}}
2668 \label{sec:sock_endianness}
2670 \itindbeg{endianness}
2672 Un altro dei problemi di programmazione che può dar luogo ad effetti
2673 imprevisti è quello relativo alla cosiddetta \textit{endianness}. Questa è una
2674 caratteristica generale dell'architettura hardware di un computer che dipende
2675 dal fatto che la rappresentazione di un numero binario può essere fatta in due
2676 modi, chiamati rispettivamente \textit{big endian} e \textit{little endian} a
2677 seconda di come i singoli bit vengono aggregati per formare le variabili
2678 intere (ed in genere in diretta corrispondenza a come sono poi in realtà
2679 cablati sui bus interni del computer).
2681 \begin{figure}[!htb]
2682 \centering \includegraphics[height=3cm]{img/endianness}
2683 \caption{Schema della disposizione dei dati in memoria a seconda della
2684 \textit{endianness}.}
2685 \label{fig:sock_endianness}
2688 Per capire meglio il problema si consideri un intero a 32 bit scritto in una
2689 locazione di memoria posta ad un certo indirizzo. Come illustrato in
2690 fig.~\ref{fig:sock_endianness} i singoli bit possono essere disposti in memoria
2691 in due modi: a partire dal più significativo o a partire dal meno
2692 significativo. Così nel primo caso si troverà il byte che contiene i bit più
2693 significativi all'indirizzo menzionato e il byte con i bit meno significativi
2694 nell'indirizzo successivo; questo ordinamento è detto \textit{big endian},
2695 dato che si trova per prima la parte più grande. Il caso opposto, in cui si
2696 parte dal bit meno significativo è detto per lo stesso motivo \textit{little
2699 Si può allora verificare quale tipo di \textit{endianness} usa il proprio
2700 computer con un programma elementare che si limita ad assegnare un valore ad
2701 una variabile per poi ristamparne il contenuto leggendolo un byte alla volta.
2702 Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
2703 allora se lo eseguiamo su un normale PC compatibile, che è \textit{little
2704 endian} otterremo qualcosa del tipo:
2706 [piccardi@gont sources]$ \textbf{./endtest}
2707 Using value ABCDEF01
2714 mentre su un vecchio Macintosh con PowerPC, che è \textit{big endian} avremo
2717 piccardi@anarres:~/gapil/sources$ \textbf{./endtest}
2718 Using value ABCDEF01
2726 L'attenzione alla \textit{endianness} nella programmazione è importante, perché
2727 se si fanno assunzioni relative alla propria architettura non è detto che
2728 queste restino valide su un'altra architettura. Inoltre, come vedremo ad
2729 esempio in sez.~\ref{sec:sock_addr_func}, si possono avere problemi quando ci
2730 si trova a usare valori di un formato con una infrastruttura che ne usa
2733 La \textit{endianness} di un computer dipende essenzialmente dalla architettura
2734 hardware usata; Intel e Digital usano il \textit{little endian}, Motorola,
2735 IBM, Sun (sostanzialmente tutti gli altri) usano il \textit{big endian}. Il
2736 formato dei dati contenuti nelle intestazioni dei protocolli di rete (il
2737 cosiddetto \textit{network order}) è anch'esso \textit{big endian}; altri
2738 esempi di uso di questi due diversi formati sono quello del bus PCI, che è
2739 \textit{little endian}, o quello del bus VME che è \textit{big endian}.
2741 Esistono poi anche dei processori che possono scegliere il tipo di formato
2742 all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
2743 da un tipo di ordinamento all'altro con una specifica istruzione. In ogni caso
2744 in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
2745 in genere resta sempre lo stesso,\footnote{su architettura PowerPC è possibile
2746 cambiarlo, si veda sez.~\ref{sec:process_prctl}.} anche quando il processore
2747 permetterebbe di eseguire questi cambiamenti.
2749 \begin{figure}[!htbp]
2750 \footnotesize \centering
2751 \begin{minipage}[c]{\codesamplewidth}
2752 \includecodesample{listati/endian.c}
2755 \caption{La funzione \samplefunc{endian}, usata per controllare il tipo di
2756 architettura della macchina.}
2757 \label{fig:sock_endian_code}
2760 Per controllare quale tipo di ordinamento si ha sul proprio computer si è
2761 scritta una piccola funzione di controllo, il cui codice è riportato
2762 fig.~\ref{fig:sock_endian_code}, che restituisce un valore nullo (falso) se
2763 l'architettura è \textit{big endian} ed uno non nullo (vero) se l'architettura
2764 è \textit{little endian}.
2766 Come si vede la funzione è molto semplice, e si limita, una volta assegnato
2767 (\texttt{\small 9}) un valore di test pari a \texttt{0xABCD} ad una variabile
2768 di tipo \ctyp{short} (cioè a 16 bit), a ricostruirne una copia byte a byte.
2769 Per questo prima (\texttt{\small 10}) si definisce il puntatore \var{ptr} per
2770 accedere al contenuto della prima variabile, ed infine calcola (\texttt{\small
2771 11}) il valore della seconda assumendo che il primo byte sia quello meno
2772 significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianness}, che sia
2773 \textit{little endian}). Infine la funzione restituisce (\texttt{\small 12})
2774 il valore del confronto delle due variabili.
2776 In generale non ci si deve preoccupare della \textit{endianness} all'interno
2777 di un programma fintanto che questo non deve generare o manipolare dei dati
2778 che sono scambiati con altre macchine, ad esempio tramite via rete o tramite
2779 dei file binari. Nel primo caso la scelta è già stata fatta nella
2780 standardizzazione dei protocolli, che hanno adottato il \textit{big endian}
2781 (che viene detto anche per questo \textit{network order} e vedremo in
2782 sez.~\ref{sec:sock_func_ord} le funzioni di conversione che devono essere
2785 Nel secondo caso occorre sapere quale \textit{endianness} è stata usata nei
2786 dati memorizzati sul file e tenerne conto nella rilettura e nella
2787 manipolazione e relativa modifica (e salvataggio). La gran parte dei formati
2788 binari standardizzati specificano quale \textit{endianness} viene utilizzata e
2789 basterà identificare qual'è, se se ne deve definire uno per i propri scopi
2790 basterà scegliere una volta per tutte quale usare e attenersi alla scelta.
2792 \itindend{endianness}
2795 % LocalWords: like exec kernel thread main ld linux static linker char envp Gb
2796 % LocalWords: sez POSIX exit system call cap abort shell diff errno stdlib int
2797 % LocalWords: SUCCESS FAILURE void atexit stream fclose unistd descriptor init
2798 % LocalWords: SIGCHLD wait function glibc SunOS arg argp execve fig high kb Mb
2799 % LocalWords: memory alpha swap table printf Unit MMU paging fault SIGSEGV BSS
2800 % LocalWords: multitasking text segment NULL Block Started Symbol fill black
2801 % LocalWords: heap stack calling convention size malloc calloc realloc nmemb
2802 % LocalWords: ENOMEM ptr uClib cfree error leak smartpointers hook Dmalloc brk
2803 % LocalWords: Gray Watson Electric Fence Bruce Perens sbrk longjmp SUSv BSD ap
2804 % LocalWords: ptrdiff increment locking lock copy write capabilities IPC mlock
2805 % LocalWords: capability MEMLOCK limits getpagesize RLIMIT munlock sys const
2806 % LocalWords: addr len EINVAL EPERM mlockall munlockall flags l'OR CURRENT IFS
2807 % LocalWords: argc argv parsing questofile txt getopt optstring switch optarg
2808 % LocalWords: optind opterr optopt POSIXLY CORRECT long options NdA
2809 % LocalWords: option parameter list environ PATH HOME XPG tab LOGNAME LANG PWD
2810 % LocalWords: TERM PAGER TMPDIR getenv name SVr setenv unsetenv putenv opz gcc
2811 % LocalWords: clearenv libc value overwrite string reference result argument
2812 % LocalWords: socket variadic ellipsis header stdarg execl self promoting last
2813 % LocalWords: float double short register type dest src extern setjmp jmp buf
2814 % LocalWords: env return if while Di page cdecl rectangle node anchor west PS
2815 % LocalWords: environment rounded corners dashed south width height draw east
2816 % LocalWords: exithandler handler violation inline SOURCE SVID XOPEN mincore
2817 % LocalWords: length unsigned vec EFAULT EAGAIN dell'I memalign valloc posix
2818 % LocalWords: boundary memptr alignment sizeof overrun mcheck abortfn enum big
2819 % LocalWords: mprobe DISABLED HEAD TAIL touch right emacs OSTYPE endianness IBM
2820 % LocalWords: endian little endtest Macintosh PowerPC Intel Digital Motorola
2821 % LocalWords: Sun order VME loader Windows DLL shared objects PRELOAD termios
2822 % LocalWords: is to LC SIG str mem wcs assert ctype dirent fcntl signal stdio
2823 % LocalWords: times library utmp syscall number Filesystem Hierarchy pathname
2824 % LocalWords: context assembler sysconf fork Dinamic huge segmentation program
2825 % LocalWords: break store Using
2827 %%% Local Variables:
2829 %%% TeX-master: "gapil"