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 \textit{thread} in Linux sarà
39 trattata a parte in cap.~\ref{cha:threads}.
42 \subsection{L'avvio e l'esecuzione di un programma}
45 \itindbeg{link-loader}
46 \itindbeg{shared~objects}
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 \textit{shared objects} viene caricato in memoria dal kernel
61 una sola volta per tutti i programmi che lo usano.
62 \itindend{shared~objects}
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 \headfiled{assert.h}&$\bullet$& -- & Verifica le asserzioni fatte in un
218 \headfiled{ctype.h} &$\bullet$& -- & Tipi standard.\\
219 \headfiled{dirent.h}& -- &$\bullet$& Manipolazione delle directory.\\
220 \headfiled{errno.h} & -- &$\bullet$& Errori di sistema.\\
221 \headfiled{fcntl.h} & -- &$\bullet$& Controllo sulle opzioni dei
223 \headfiled{limits.h}& -- &$\bullet$& Limiti e parametri del sistema.\\
224 \headfiled{malloc.h}&$\bullet$& -- & Allocazione della memoria.\\
225 \headfiled{setjmp.h}&$\bullet$& -- & Salti non locali.\\
226 \headfiled{signal.h}& -- &$\bullet$& Gestione dei segnali.\\
227 \headfiled{stdarg.h}&$\bullet$& -- & Gestione di funzioni a argomenti
229 \headfiled{stdio.h} &$\bullet$& -- & I/O bufferizzato in standard ANSI
231 \headfiled{stdlib.h}&$\bullet$& -- & Definizioni della libreria
233 \headfiled{string.h}&$\bullet$& -- & Manipolazione delle stringhe.\\
234 \headfiled{time.h} & -- &$\bullet$& Gestione dei tempi.\\
235 \headfiled{times.h} &$\bullet$& -- & Gestione dei tempi.\\
236 \headfiled{unistd.h}& -- &$\bullet$& Unix standard library.\\
237 \headfiled{utmp.h} & -- &$\bullet$& Registro connessioni utenti.\\
240 \caption{Elenco dei principali \textit{header file} definiti dagli standard
242 \label{tab:intro_posix_header}
245 Un esempio di inclusione di questi file, preso da uno dei programmi di
246 esempio, è il seguente, e si noti come gli \textit{header file} possano essere
247 referenziati con il nome fra parentesi angolari, nel qual caso si indica l'uso
248 di quelli installati con il sistema,\footnote{in un sistema GNU/Linux che
249 segue le specifiche del \textit{Filesystem Hierarchy Standard} (per maggiori
250 informazioni si consulti sez.~1.2.3 di \cite{AGL}) si trovano sotto
251 \texttt{/usr/include}.} o fra virgolette, nel qual caso si fa riferimento
252 ad una versione locale, da indicare con un \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 \headfiled{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 \constd{EXIT\_SUCCESS} e \constd{EXIT\_FAILURE}, da
431 usare sempre per specificare lo stato di uscita di un processo. Su Linux, ed
432 in generale in qualunque sistema POSIX, ad esse sono assegnati rispettivamente
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 \constd{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
660 Per la gestione da parte del kernel la memoria viene divisa in pagine di
661 dimensione fissa. Inizialmente queste pagine erano di 4kb sulle macchine a 32
662 bit e di 8kb sulle alpha. Con le versioni più recenti del kernel è possibile
663 anche utilizzare pagine di dimensioni maggiori (di 4Mb, dette \textit{huge
664 page}), per sistemi con grandi quantitativi di memoria in cui l'uso di
665 pagine troppo piccole comporta una perdita di prestazioni. In alcuni sistemi
666 la costante \constd{PAGE\_SIZE}, definita in \headfile{limits.h}, indica la
667 dimensione di una pagina in byte, con Linux questo non avviene e per ottenere
668 questa dimensione si deve ricorrere alla funzione \func{getpagesize} (vedi
669 sez.~\ref{sec:sys_memory_res}).
672 \itindbeg{page~table}
674 Ciascuna pagina di memoria nello spazio di indirizzi virtuale è associata ad
675 un supporto che può essere una pagina di memoria reale o ad un dispositivo di
676 stoccaggio secondario (come lo spazio disco riservato alla \textit{swap}, o i
677 file che contengono il codice). Per ciascun processo il kernel si cura di
678 mantenere un mappa di queste corrispondenze nella cosiddetta \textit{page
679 table}.\footnote{questa è una semplificazione brutale, il meccanismo è molto
680 più complesso; una buona trattazione di come Linux gestisce la memoria
681 virtuale si trova su \cite{LinVM}.}
683 \itindend{page~table}
685 Una stessa pagina di memoria reale può fare da supporto a diverse pagine di
686 memoria virtuale appartenenti a processi diversi, come accade in genere per le
687 pagine che contengono il codice delle librerie condivise. Ad esempio il codice
688 della funzione \func{printf} starà su una sola pagina di memoria reale che
689 farà da supporto a tutte le pagine di memoria virtuale di tutti i processi che
690 hanno detta funzione nel loro codice.
692 \index{paginazione|(}
694 La corrispondenza fra le pagine della memoria virtuale di un processo e quelle
695 della memoria fisica della macchina viene gestita in maniera trasparente dal
696 kernel.\footnote{in genere con l'ausilio dell'hardware di gestione della
697 memoria (la \textit{Memory Management Unit} del processore), con i kernel
698 della serie 2.6 è comunque diventato possibile utilizzare Linux anche su
699 architetture che non dispongono di una MMU.} Poiché in genere la memoria
700 fisica è solo una piccola frazione della memoria virtuale, è necessario un
701 meccanismo che permetta di trasferire le pagine che servono dal supporto su
702 cui si trovano in memoria, eliminando quelle che non servono. Questo
703 meccanismo è detto \textsl{paginazione} (o \textit{paging}), ed è uno dei
704 compiti principali del kernel.
706 \itindbeg{page~fault}
708 Quando un processo cerca di accedere ad una pagina che non è nella memoria
709 reale, avviene quello che viene chiamato un \textit{page fault}; la gestione
710 della memoria genera un'interruzione e passa il controllo al kernel il quale
711 sospende il processo e si incarica di mettere in RAM la pagina richiesta,
712 effettuando tutte le operazioni necessarie per reperire lo spazio necessario,
713 per poi restituire il controllo al processo.
715 Dal punto di vista di un processo questo meccanismo è completamente
716 trasparente, e tutto avviene come se tutte le pagine fossero sempre
717 disponibili in memoria. L'unica differenza avvertibile è quella dei tempi di
718 esecuzione, che passano dai pochi nanosecondi necessari per l'accesso in RAM
719 se la pagina è direttamente disponibile, a tempi estremamente più lunghi,
720 dovuti all'intervento del kernel, qualora sia necessario reperire pagine
721 riposte nella \textit{swap}.
723 \itindend{page~fault}
725 Normalmente questo è il prezzo da pagare per avere un multitasking reale, ed
726 in genere il sistema è molto efficiente in questo lavoro; quando però ci siano
727 esigenze specifiche di prestazioni è possibile usare delle funzioni che
728 permettono di bloccare il meccanismo della paginazione e mantenere fisse delle
729 pagine in memoria (vedi sez.~\ref{sec:proc_mem_lock}).
731 \index{paginazione|)}
732 \index{memoria~virtuale|)}
735 \subsection{La struttura della memoria di un processo}
736 \label{sec:proc_mem_layout}
738 \itindbeg{segment~violation}
740 Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
741 una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
742 tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
743 commette quando si è manipolato male un puntatore e genera quella che viene
744 chiamata una \textit{segment violation}. Se si tenta cioè di leggere o
745 scrivere con un indirizzo per il quale non esiste un'associazione nella
746 memoria virtuale, il kernel risponde al relativo \textit{page fault} mandando
747 un segnale \signal{SIGSEGV} al processo, che normalmente ne causa la
748 terminazione immediata.
750 \itindend{segment~violation}
752 È pertanto importante capire come viene strutturata la memoria virtuale di un
753 processo. Essa viene divisa in \textsl{segmenti}, cioè un insieme contiguo di
754 indirizzi virtuali ai quali il processo può accedere. Solitamente un
755 programma C viene suddiviso nei seguenti segmenti:
756 \index{segmento!testo|(}
757 \index{segmento!dati|(}
761 \item Il \textsl{segmento di testo} o \textit{text segment}. Contiene il
762 codice del programma, delle funzioni di librerie da esso utilizzate, e le
763 costanti. Normalmente viene condiviso fra tutti i processi che eseguono lo
764 stesso programma e nel caso delle librerie anche da processi che eseguono
767 Quando l'architettura hardware lo supporta viene marcato in sola lettura per
768 evitare sovrascritture accidentali (o maliziose) che ne modifichino le
769 istruzioni. Viene allocato da \func{execve} all'avvio del programma e resta
770 invariato per tutto il tempo dell'esecuzione.
771 \index{variabili!globali|(}
772 \index{variabili!statiche|(}
773 \item Il \textsl{segmento dei dati} o \textit{data segment}. Contiene tutti i
774 dati del programma, come le \textsl{variabili globali}, cioè quelle definite
775 al di fuori di tutte le funzioni che compongono il programma, e le
776 \textsl{variabili statiche}, cioè quelle dichiarate con l'attributo
777 \direct{static},\footnote{la direttiva \direct{static} indica al compilatore
778 C che una variabile così dichiarata all'interno di una funzione deve
779 essere mantenuta staticamente in memoria (nel segmento dati appunto);
780 questo significa che la variabile verrà inizializzata una sola volta alla
781 prima invocazione della funzione e che il suo valore sarà mantenuto fra
782 diverse esecuzioni della funzione stessa, la differenza con una variabile
783 globale è che essa può essere vista solo all'interno della funzione in cui
784 è dichiarata.} e la memoria allocata dinamicamente. Di norma è diviso in
787 \item Il segmento dei dati inizializzati, che contiene le variabili il cui
788 valore è stato assegnato esplicitamente. Ad esempio se si definisce:
789 \includecodesnip{listati/pi.c}
790 questo valore sarà immagazzinato in questo segmento. La memoria di questo
791 segmento viene preallocata all'avvio del programma e inizializzata ai valori
793 \item Il segmento dei dati non inizializzati, che contiene le variabili il
794 cui valore non è stato assegnato esplicitamente. Ad esempio se si
796 \includecodesnip{listati/vect.c}
797 questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
798 allocato all'avvio, e tutte le variabili vengono inizializzate a zero (ed
799 i puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
800 variabili che vanno nel segmento dati, e non è affatto vero in
801 generale.} Storicamente questa seconda parte del segmento dati viene
802 chiamata \itindex{Block~Started~by~Symbol~(BSS)} BSS (da \textit{Block
803 Started by Symbol}). La sua dimensione è fissa.
804 \index{variabili!globali|)} \index{variabili!statiche|)}
805 \item Lo \textit{heap}, detto anche \textit{free store}. Tecnicamente lo si
806 può considerare l'estensione del segmento dei dati non inizializzati, a
807 cui di solito è posto giusto di seguito. Questo è il segmento che viene
808 utilizzato per l'allocazione dinamica della memoria. Lo \textit{heap} può
809 essere ridimensionato allargandolo e restringendolo per allocare e
810 disallocare la memoria dinamica con le apposite funzioni (vedi
811 sez.~\ref{sec:proc_mem_alloc}), ma il suo limite inferiore, quello
812 adiacente al segmento dei dati non inizializzati, ha una posizione fissa.
814 \item Il segmento di \textit{stack}, che contiene quello che viene chiamato lo
815 ``\textit{stack}'' del programma. Tutte le volte che si effettua una
816 chiamata ad una funzione è qui che viene salvato l'indirizzo di ritorno e le
817 informazioni dello stato del chiamante (come il contenuto di alcuni registri
818 della CPU), poi la funzione chiamata alloca qui lo spazio per le sue
819 variabili locali. Tutti questi dati vengono \textit{impilati} (da questo
820 viene il nome \textit{stack}) in sequenza uno sull'altro; in questo modo le
821 funzioni possono essere chiamate ricorsivamente. Al ritorno della funzione
822 lo spazio è automaticamente rilasciato e ``\textsl{ripulito}''.\footnote{il
823 compilatore si incarica di generare automaticamente il codice necessario,
824 seguendo quella che viene chiamata una \textit{calling convention}; quella
825 standard usata con il C ed il C++ è detta \textit{cdecl} e prevede che gli
826 argomenti siano caricati nello \textit{stack} dal chiamante da destra a
827 sinistra, e che sia il chiamante stesso ad eseguire la ripulitura dello
828 \textit{stack} al ritorno della funzione, se ne possono però utilizzare di
829 alternative (ad esempio nel Pascal gli argomenti sono inseriti da sinistra
830 a destra ed è compito del chiamato ripulire lo \textit{stack}), in genere
831 non ci si deve preoccupare di questo fintanto che non si mescolano
832 funzioni scritte con linguaggi diversi.}
834 La dimensione di questo segmento aumenta seguendo la crescita dello
835 \textit{stack} del programma, ma non viene ridotta quando quest'ultimo si
841 % \includegraphics[height=12cm]{img/memory_layout}
843 \draw (0,0) rectangle (4,1);
844 \draw (2,0.5) node {\textit{text}};
845 \draw (0,1) rectangle (4,2.5);
846 \draw (2,1.75) node {dati inizializzati};
847 \draw (0,2.5) rectangle (4,5);
848 \draw (2,3.75) node {dati non inizializzati};
849 \draw (0,5) rectangle (4,9);
850 \draw[dashed] (0,6) -- (4,6);
851 \draw[dashed] (0,8) -- (4,8);
852 \draw (2,5.5) node {\textit{heap}};
853 \draw (2,8.5) node {\textit{stack}};
854 \draw [->] (2,6) -- (2,6.5);
855 \draw [->] (2,8) -- (2,7.5);
856 \draw (0,9) rectangle (4,10);
857 \draw (2,9.5) node {\textit{environment}};
858 \draw (4,0) node [anchor=west] {\texttt{0x08000000}};
859 \draw (4,5) node [anchor=west] {\texttt{0x08xxxxxx}};
860 \draw (4,9) node [anchor=west] {\texttt{0xC0000000}};
862 \caption{Disposizione tipica dei segmenti di memoria di un processo.}
863 \label{fig:proc_mem_layout}
866 Una disposizione tipica dei vari segmenti (testo, dati inizializzati e non
867 inizializzati, \textit{heap}, \textit{stack}, ecc.) è riportata in
868 fig.~\ref{fig:proc_mem_layout}. Si noti come in figura sia indicata una
869 ulteriore regione, marcata \textit{environment}, che è quella che contiene i
870 dati relativi alle variabili di ambiente passate al programma al suo avvio
871 (torneremo su questo argomento in sez.~\ref{sec:proc_environ}).
873 Usando il comando \cmd{size} su un programma se ne può stampare le dimensioni
874 dei segmenti di testo e di dati (solo però per i dati inizializzati ed il BSS,
875 dato che lo \textit{heap} ha una dimensione dinamica). Si tenga presente
876 comunque che il BSS, contrariamente al segmento dei dati inizializzati, non è
877 mai salvato sul file che contiene l'eseguibile, dato che viene sempre
878 inizializzato a zero al caricamento del programma.
880 \index{segmento!testo|)}
881 \index{segmento!dati|)}
886 \subsection{Allocazione della memoria per i programmi C}
887 \label{sec:proc_mem_alloc}
889 Il C supporta direttamente, come linguaggio di programmazione, soltanto due
890 modalità di allocazione della memoria: l'\textsl{allocazione statica} e
891 l'\textsl{allocazione automatica}.
893 L'\textsl{allocazione statica} è quella con cui sono memorizzate le variabili
894 globali e le variabili statiche, cioè le variabili il cui valore deve essere
895 mantenuto per tutta la durata del programma. Come accennato queste variabili
896 vengono allocate nel segmento dei dati all'avvio del programma come parte
897 delle operazioni svolte da \func{exec}, e lo spazio da loro occupato non viene
898 liberato fino alla sua conclusione.
900 \index{variabili!automatiche|(}
902 L'\textsl{allocazione automatica} è quella che avviene per gli argomenti di
903 una funzione e per le sue variabili locali, quelle che vengono definite
904 all'interno della funzione che esistono solo per la durata della sua
905 esecuzione e che per questo vengono anche dette \textsl{variabili
906 automatiche}. Lo spazio per queste variabili viene allocato nello
907 \textit{stack} quando viene eseguita la funzione e liberato quando si esce
910 \index{variabili!automatiche|)}
912 Esiste però un terzo tipo di allocazione, l'\textsl{allocazione dinamica}
913 della memoria, che non è prevista direttamente all'interno del linguaggio C,
914 ma che è necessaria quando il quantitativo di memoria che serve è
915 determinabile solo durante il corso dell'esecuzione del programma. Il C non
916 consente di usare variabili allocate dinamicamente, non è possibile cioè
917 definire in fase di programmazione una variabile le cui dimensioni possano
918 essere modificate durante l'esecuzione del programma. Per questo la libreria
919 standard del C fornisce una opportuna serie di funzioni per eseguire
920 l'allocazione dinamica di memoria, che come accennato avviene nello
923 Le variabili il cui contenuto è allocato in questo modo non potranno essere
924 usate direttamente come le altre (quelle nello \textit{stack}), ma l'accesso
925 sarà possibile solo in maniera indiretta, attraverso i puntatori alla memoria
926 loro riservata che si sono ottenuti dalle funzioni di allocazione.
928 Le funzioni previste dallo standard ANSI C per la gestione della memoria sono
929 quattro: \func{malloc}, \func{calloc}, \func{realloc} e \func{free}. Le prime
930 due, \funcd{malloc} e \funcd{calloc} allocano nuovo spazio di memoria; i
931 rispettivi prototipi sono:
935 \fdecl{void *calloc(size\_t nmemb, size\_t size)}
936 \fdesc{Alloca un'area di memoria inizializzata a 0.}
937 \fdecl{void *malloc(size\_t size)}
938 \fdesc{Alloca un'area di memoria non inizializzata.}
940 {Entrambe le funzioni restituiscono il puntatore alla zona di memoria allocata
941 in caso di successo e \val{NULL} in caso di fallimento, nel qual caso
942 \var{errno} assumerà il valore \errcode{ENOMEM}.}
945 In genere si usano \func{malloc} e \func{calloc} per allocare dinamicamente
946 un'area di memoria.\footnote{queste funzioni presentano un comportamento
947 diverso fra le \acr{glibc} e le \acr{uClib} quando il valore di \param{size}
948 è nullo. Nel primo caso viene comunque restituito un puntatore valido,
949 anche se non è chiaro a cosa esso possa fare riferimento, nel secondo caso
950 viene restituito \val{NULL}. Il comportamento è analogo con
951 \code{realloc(NULL, 0)}.} Dato che i puntatori ritornati sono di tipo
952 generico non è necessario effettuare un cast per assegnarli a puntatori al
953 tipo di variabile per la quale si effettua l'allocazione, inoltre le funzioni
954 garantiscono che i puntatori siano allineati correttamente per tutti i tipi di
955 dati; ad esempio sulle macchine a 32 bit in genere sono allineati a multipli
956 di 4 byte e sulle macchine a 64 bit a multipli di 8 byte.
958 Nel caso di \func{calloc} l'area di memoria viene allocata nello \textit{heap}
959 come un vettore di \param{nmemb} membri di \param{size} byte di dimensione, e
960 preventivamente inizializzata a zero, nel caso di \func{malloc} invece vengono
961 semplicemente allocati \param{size} byte e l'area di memoria non viene
964 Una volta che non sia più necessaria la memoria allocata dinamicamente deve
965 essere esplicitamente rilasciata usando la funzione \funcd{free},\footnote{le
966 glibc provvedono anche una funzione \funcm{cfree} definita per compatibilità
967 con SunOS, che è deprecata.} il suo prototipo è:
971 \fdecl{void free(void *ptr)}
972 \fdesc{Disalloca un'area di memoria precedentemente allocata.}
974 {La funzione non ritorna nulla e non riporta errori.}
977 Questa funzione vuole come argomento \var{ptr} il puntatore restituito da una
978 precedente chiamata ad una qualunque delle funzioni di allocazione che non sia
979 già stato liberato da un'altra chiamata a \func{free}. Se il valore
980 di \param{ptr} è \val{NULL} la funzione non fa niente, mentre se l'area di
981 memoria era già stata liberata da un precedente chiamata il comportamento
982 della funzione è dichiarato indefinito, ma in genere comporta la corruzione
983 dei dati di gestione dell'allocazione, che può dar luogo a problemi gravi, ad
984 esempio un \textit{segmentation fault} in una successiva chiamata di una di
987 \itindbeg{double~free}
989 Dato che questo errore, chiamato in gergo \textit{double free}, è abbastanza
990 frequente, specie quando si manipolano vettori di puntatori, e dato che le
991 conseguenze possono essere pesanti ed inaspettate, si suggerisce come
992 soluzione precauzionale di assegnare sempre a \val{NULL} ogni puntatore su cui
993 sia stata eseguita \func{free} immediatamente dopo l'esecuzione della
994 funzione. In questo modo, dato che con un puntatore nullo \func{free} non
995 esegue nessuna operazione, si evitano i problemi del \textit{double free}.
997 \itindend{double~free}
999 Infine la funzione \funcd{realloc} consente di modificare, in genere di
1000 aumentare, la dimensione di un'area di memoria precedentemente allocata; il
1005 \fdecl{void *realloc(void *ptr, size\_t size)}
1006 \fdesc{Cambia la dimensione di un'area di memoria precedentemente allocata.}
1007 } {La funzione ritorna il puntatore alla zona di memoria allocata in caso
1008 di successo e \val{NULL} per un errore, nel qual caso \var{errno}
1009 assumerà il valore \errcode{ENOMEM}.}
1012 La funzione vuole come primo argomento il puntatore restituito da una
1013 precedente chiamata a \func{malloc} o \func{calloc} e come secondo argomento
1014 la nuova dimensione (in byte) che si intende ottenere. Se si passa
1015 per \param{ptr} il valore \val{NULL} allora la funzione si comporta come
1016 \func{malloc}.\footnote{questo è vero per Linux e l'implementazione secondo lo
1017 standard ANSI C, ma non è vero per alcune vecchie implementazioni, inoltre
1018 alcune versioni delle librerie del C consentivano di usare \func{realloc}
1019 anche per un puntatore liberato con \func{free} purché non ci fossero state
1020 nel frattempo altre chiamate a funzioni di allocazione, questa funzionalità
1021 è totalmente deprecata e non è consentita sotto Linux.}
1023 La funzione si usa ad esempio quando si deve far crescere la dimensione di un
1024 vettore. In questo caso se è disponibile dello spazio adiacente al precedente
1025 la funzione lo utilizza, altrimenti rialloca altrove un blocco della
1026 dimensione voluta, copiandoci automaticamente il contenuto; lo spazio aggiunto
1027 non viene inizializzato. Se la funzione fallisce l'area di memoria originale
1028 non viene assolutamente toccata.
1030 Si deve sempre avere ben presente il fatto che il blocco di memoria restituito
1031 da \func{realloc} può non essere un'estensione di quello che gli si è passato
1032 in ingresso; per questo si dovrà \emph{sempre} eseguire la riassegnazione di
1033 \param{ptr} al valore di ritorno della funzione, e reinizializzare o provvedere
1034 ad un adeguato aggiornamento di tutti gli altri puntatori all'interno del
1035 blocco di dati ridimensionato.
1037 La \acr{glibc} ha un'implementazione delle funzioni di allocazione che è
1038 controllabile dall'utente attraverso alcune variabili di ambiente (vedi
1039 sez.~\ref{sec:proc_environ}), in particolare diventa possibile tracciare
1040 questo tipo di errori usando la variabile di ambiente \envvar{MALLOC\_CHECK\_}
1041 che quando viene definita mette in uso una versione meno efficiente delle
1042 funzioni suddette, che però è più tollerante nei confronti di piccoli errori
1043 come quello dei \textit{double free} o i \textit{buffer overrun} di un
1044 byte.\footnote{uno degli errori più comuni, causato ad esempio dalla scrittura
1045 di una stringa di dimensione pari a quella del buffer, in cui ci si
1046 dimentica dello zero di terminazione finale.} In particolare:
1048 \item se la variabile è posta a $0$ gli errori vengono ignorati;
1049 \item se la variabile è posta a $1$ viene stampato un avviso sullo
1050 \textit{standard error} (vedi sez.~\ref{sec:file_fd});
1051 \item se la variabile è posta a $2$ viene chiamata la funzione \func{abort}
1052 (vedi sez.~\ref{sec:sig_alarm_abort}), che in genere causa l'immediata
1053 terminazione del programma;
1054 \item se la variabile è posta a $3$ viene stampato l'avviso e chiamata
1058 \itindbeg{memory~leak}
1060 L'errore di programmazione più comune e più difficile da risolvere che si
1061 incontra con le funzioni di allocazione è quando non viene opportunamente
1062 liberata la memoria non più utilizzata, quello che in inglese viene chiamato
1063 \textit{memory leak}, cioè una \textsl{perdita di memoria}.
1065 Un caso tipico che illustra il problema è quello in cui in una propria
1066 funzione si alloca della memoria per uso locale senza liberarla prima di
1067 uscire. La memoria resta così allocata fino alla terminazione del processo.
1068 Chiamate ripetute alla stessa funzione continueranno ad effettuare altre
1069 allocazioni, che si accumuleranno causando a lungo andare un esaurimento della
1070 memoria disponibile e la probabile impossibilità di proseguire l'esecuzione
1073 Il problema è che l'esaurimento della memoria può avvenire in qualunque
1074 momento, in corrispondenza ad una qualunque chiamata di \func{malloc} che può
1075 essere in una sezione del codice che non ha alcuna relazione con la funzione
1076 che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
1077 \textit{memory leak}. In C e C++ il problema è particolarmente sentito. In
1078 C++, per mezzo della programmazione ad oggetti, il problema dei \textit{memory
1079 leak} si può notevolmente ridimensionare attraverso l'uso accurato di
1080 appositi oggetti come gli \textit{smartpointers}. Questo però in genere va a
1081 scapito delle prestazioni dell'applicazione in esecuzione.
1083 % TODO decidere cosa fare di questo che segue In altri linguaggi come il java
1084 % e recentemente il C\# il problema non si pone nemmeno perché la gestione
1085 % della memoria viene fatta totalmente in maniera automatica, ovvero il
1086 % programmatore non deve minimamente preoccuparsi di liberare la memoria
1087 % allocata precedentemente quando non serve più, poiché l'infrastruttura del
1088 % linguaggio gestisce automaticamente la cosiddetta
1089 % \itindex{garbage~collection} \textit{garbage collection}. In tal caso,
1090 % attraverso meccanismi simili a quelli del \textit{reference counting},
1091 % quando una zona di memoria precedentemente allocata non è più riferita da
1092 % nessuna parte del codice in esecuzione, può essere deallocata
1093 % automaticamente in qualunque momento dall'infrastruttura.
1095 % Anche questo va a scapito delle prestazioni dell'applicazione in esecuzione
1096 % (inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
1097 % eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
1098 % la presenza di una infrastruttura per la loro interpretazione e pertanto hanno
1099 % di per sé delle prestazioni più scadenti rispetto alle stesse applicazioni
1100 % compilate direttamente). Questo comporta però il problema della non
1101 % predicibilità del momento in cui viene deallocata la memoria precedentemente
1102 % allocata da un oggetto.
1104 Per limitare l'impatto di questi problemi, e semplificare la ricerca di
1105 eventuali errori, l'implementazione delle funzioni di allocazione nella
1106 \acr{glibc} mette a disposizione una serie di funzionalità che permettono di
1107 tracciare le allocazioni e le disallocazioni, e definisce anche una serie di
1108 possibili \textit{hook} (\textsl{ganci}) che permettono di sostituire alle
1109 funzioni di libreria una propria versione (che può essere più o meno
1110 specializzata per il debugging). Esistono varie librerie che forniscono dei
1111 sostituti opportuni delle funzioni di allocazione in grado, senza neanche
1112 ricompilare il programma,\footnote{esempi sono \textit{Dmalloc}
1113 \url{http://dmalloc.com/} di Gray Watson ed \textit{Electric Fence} di Bruce
1114 Perens.} di eseguire diagnostiche anche molto complesse riguardo
1115 l'allocazione della memoria. Vedremo alcune delle funzionalità di ausilio
1116 presenti nella \acr{glibc} in sez.~\ref{sec:proc_memory_adv_management}.
1118 \itindend{memory~leak}
1120 Una possibile alternativa all'uso di \func{malloc}, per evitare di soffrire
1121 dei problemi di \textit{memory leak} descritti in precedenza, è di allocare la
1122 memoria nel segmento di \textit{stack} della funzione corrente invece che
1123 nello \textit{heap}. Per farlo si può usare la funzione \funcd{alloca}, la cui
1124 sintassi è identica a quella di \func{malloc}; il suo prototipo è:
1128 \fdecl{void *alloca(size\_t size)}
1129 \fdesc{Alloca un'area di memoria nello \textit{stack}.}
1131 {La funzione ritorna il puntatore alla zona di memoria allocata, in caso
1132 di errore il comportamento è indefinito.}
1135 La funzione alloca la quantità di memoria (non inizializzata) richiesta
1136 dall'argomento \param{size} nel segmento di \textit{stack} della funzione
1137 chiamante. Con questa funzione non è più necessario liberare la memoria
1138 allocata, e quindi non esiste un analogo della \func{free}, in quanto essa
1139 viene rilasciata automaticamente al ritorno della funzione.
1141 Come è evidente questa funzione ha alcuni vantaggi interessanti, anzitutto
1142 permette di evitare alla radice i problemi di \textit{memory leak}, dato che
1143 non serve più la deallocazione esplicita; inoltre la deallocazione automatica
1144 funziona anche quando si usa \func{longjmp} per uscire da una subroutine con
1145 un salto non locale da una funzione (vedi sez.~\ref{sec:proc_longjmp}). Un
1146 altro vantaggio è che in Linux la funzione è molto più veloce di \func{malloc}
1147 e non viene sprecato spazio, infatti non è necessario gestire un pool di
1148 memoria da riservare e si evitano così anche i problemi di frammentazione di
1149 quest'ultimo, che comportano inefficienze sia nell'allocazione della memoria
1150 che nell'esecuzione dell'allocazione.
1152 Gli svantaggi sono che questa funzione non è disponibile su tutti gli Unix, e
1153 non è inserita né nello standard POSIX né in SUSv3 (ma è presente in BSD), il
1154 suo utilizzo quindi limita la portabilità dei programmi. Inoltre la funzione
1155 non può essere usata nella lista degli argomenti di una funzione, perché lo
1156 spazio verrebbe allocato nel mezzo degli stessi. Inoltre non è chiaramente
1157 possibile usare \func{alloca} per allocare memoria che deve poi essere usata
1158 anche al di fuori della funzione in cui essa viene chiamata, dato che
1159 all'uscita dalla funzione lo spazio allocato diventerebbe libero, e potrebbe
1160 essere sovrascritto all'invocazione di nuove funzioni. Questo è lo stesso
1161 problema che si può avere con le variabili automatiche, su cui torneremo in
1162 sez.~\ref{sec:proc_var_passing}.
1164 Infine non esiste un modo di sapere se l'allocazione ha avuto successo, la
1165 funzione infatti viene realizzata inserendo del codice \textit{inline} nel
1166 programma\footnote{questo comporta anche il fatto che non è possibile
1167 sostituirla con una propria versione o modificarne il comportamento
1168 collegando il proprio programma con un'altra libreria.} che si limita a
1169 modificare il puntatore nello \textit{stack} e non c'è modo di sapere se se ne
1170 sono superate le dimensioni, per cui in caso di fallimento nell'allocazione il
1171 comportamento del programma può risultare indefinito, dando luogo ad una
1172 \textit{segment violation} la prima volta che cercherà di accedere alla
1173 memoria non effettivamente disponibile.
1175 \index{segmento!dati|(}
1178 Le due funzioni seguenti vengono utilizzate soltanto quando è necessario
1179 effettuare direttamente la gestione della memoria associata allo spazio dati
1180 di un processo,\footnote{le due funzioni sono state definite con BSD 4.3, sono
1181 marcate obsolete in SUSv2 e non fanno parte delle librerie standard del C e
1182 mentre sono state esplicitamente rimosse dallo standard POSIX.1-2001.} per
1183 poterle utilizzare è necessario definire una della macro di funzionalità (vedi
1184 sez.~\ref{sec:intro_gcc_glibc_std}) fra \macro{\_BSD\_SOURCE},
1185 \macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE} (ad un valore maggiore o
1186 uguale di 500). La prima funzione è \funcd{brk}, ed il suo prototipo è:
1190 \fdecl{int brk(void *addr)}
1191 \fdesc{Sposta la fine del segmento dati del processo.}
1193 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
1194 nel qual caso \var{errno} assumerà il valore \errcode{ENOMEM}.}
1197 La funzione è un'interfaccia all'omonima \textit{system call} ed imposta
1198 l'indirizzo finale del segmento dati di un processo (più precisamente dello
1199 \textit{heap}) all'indirizzo specificato da \param{addr}. Quest'ultimo deve
1200 essere un valore ragionevole e la dimensione totale non deve comunque eccedere
1201 un eventuale limite (vedi sez.~\ref{sec:sys_resource_limit}) sulle dimensioni
1202 massime del segmento dati del processo.
1204 Il valore di ritorno della funzione fa riferimento alla versione fornita dalla
1205 \acr{glibc}, in realtà in Linux la \textit{system call} corrispondente
1206 restituisce come valore di ritorno il nuovo valore della fine del segmento
1207 dati in caso di successo e quello corrente in caso di fallimento, è la
1208 funzione di interfaccia usata dalla \acr{glibc} che fornisce i valori di
1209 ritorno appena descritti; se si usano librerie diverse questo potrebbe non
1212 Una seconda funzione per la manipolazione diretta delle dimensioni del
1213 segmento dati\footnote{in questo caso si tratta soltanto di una funzione di
1214 libreria, anche se basata sulla stessa \textit{system call}.} è
1215 \funcd{sbrk}, ed il suo prototipo è:
1219 \fdecl{void *sbrk(intptr\_t increment)}
1220 \fdesc{Incrementa la dimensione del segmento dati del processo.}
1222 {La funzione ritorna il puntatore all'inizio della nuova zona di memoria
1223 allocata in caso di successo e \val{NULL} per un errore, nel qual
1224 caso \var{errno} assumerà il valore \errcode{ENOMEM}.}
1227 La funzione incrementa la dimensione dello \textit{heap} di un programma del
1228 valore indicato dall'argomento \param{increment}, restituendo il nuovo
1229 indirizzo finale dello stesso. L'argomento è definito come di tipo
1230 \typed{intptr\_t}, ma a seconda della versione delle librerie e del sistema
1231 può essere indicato con una serie di tipi equivalenti come \type{ptrdiff\_t},
1232 \type{ssize\_t}, \ctyp{int}. Se invocata con un valore nullo la funzione
1233 permette di ottenere l'attuale posizione della fine del segmento dati.
1235 Queste due funzioni sono state deliberatamente escluse dallo standard POSIX.1
1236 dato che per i normali programmi è sempre opportuno usare le funzioni di
1237 allocazione standard descritte in precedenza, a meno di non voler realizzare
1238 per proprio conto un diverso meccanismo di gestione della memoria del segmento
1241 \index{segmento!dati|)}
1244 \subsection{Il controllo della memoria virtuale}
1245 \label{sec:proc_mem_lock}
1247 \index{memoria~virtuale|(}
1249 Come spiegato in sez.~\ref{sec:proc_mem_gen} il kernel gestisce la memoria
1250 virtuale in maniera trasparente ai processi, decidendo quando rimuovere pagine
1251 dalla memoria per metterle nell'area di \textit{swap}, sulla base
1252 dell'utilizzo corrente da parte dei vari processi.
1254 Nell'uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il
1255 meccanismo della paginazione riporta in RAM, ed in maniera trasparente, tutte
1256 le pagine che gli occorrono; esistono però esigenze particolari in cui non si
1257 vuole che questo meccanismo si attivi. In generale i motivi per cui si possono
1258 avere di queste necessità sono due:
1260 \item \textsl{La velocità}. Il processo della paginazione è trasparente solo
1261 se il programma in esecuzione non è sensibile al tempo che occorre a
1262 riportare la pagina in memoria; per questo motivo processi critici che hanno
1263 esigenze di tempo reale o tolleranze critiche nelle risposte (ad esempio
1264 processi che trattano campionamenti sonori) possono non essere in grado di
1265 sopportare le variazioni della velocità di accesso dovuta alla paginazione.
1267 In certi casi poi un programmatore può conoscere meglio dell'algoritmo di
1268 allocazione delle pagine le esigenze specifiche del suo programma e decidere
1269 quali pagine di memoria è opportuno che restino in memoria per un aumento
1270 delle prestazioni. In genere queste sono esigenze particolari e richiedono
1271 anche un aumento delle priorità in esecuzione del processo (vedi
1272 sez.~\ref{sec:proc_real_time}).
1274 \item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro
1275 in memoria queste possono essere portate su disco dal meccanismo della
1276 paginazione. Questo rende più lungo il periodo di tempo in cui detti segreti
1277 sono presenti in chiaro e più complessa la loro cancellazione: un processo
1278 infatti può cancellare la memoria su cui scrive le sue variabili, ma non può
1279 toccare lo spazio disco su cui una pagina di memoria può essere stata
1280 salvata. Per questo motivo di solito i programmi di crittografia richiedono
1281 il blocco di alcune pagine di memoria.
1284 Per ottenere informazioni sulle modalità in cui un programma sta usando la
1285 memoria virtuale è disponibile una apposita funzione di sistema,
1286 \funcd{mincore}, che però non è standardizzata da POSIX e pertanto non è
1287 disponibile su tutte le versioni di kernel unix-like;\footnote{nel caso di
1288 Linux devono essere comunque definite le macro \macro{\_BSD\_SOURCE} e
1289 \macro{\_SVID\_SOURCE}.} il suo prototipo è:
1294 \fdecl{int mincore(void *addr, size\_t length, unsigned char *vec)}
1295 \fdesc{Ritorna lo stato delle pagine di memoria occupate da un processo.}
1297 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1298 caso \var{errno} assumerà uno dei valori:
1300 \item[\errcode{EAGAIN}] il kernel è temporaneamente non in grado di fornire
1302 \item[\errcode{EFAULT}] \param{vec} punta ad un indirizzo non valido.
1303 \item[\errcode{EINVAL}] \param{addr} non è un multiplo delle dimensioni di
1305 \item[\errcode{ENOMEM}] o \param{addr}$+$\param{length} eccede la dimensione
1306 della memoria usata dal processo o l'intervallo di indirizzi specificato
1311 La funzione permette di ottenere le informazioni sullo stato della mappatura
1312 della memoria per il processo chiamante, specificando l'intervallo da
1313 esaminare con l'indirizzo iniziale, indicato con l'argomento \param{addr}, e
1314 la lunghezza, indicata con l'argomento \param{length}. L'indirizzo iniziale
1315 deve essere un multiplo delle dimensioni di una pagina, mentre la lunghezza
1316 può essere qualunque, fintanto che si resta nello spazio di indirizzi del
1317 processo,\footnote{in caso contrario si avrà un errore di \errcode{ENOMEM};
1318 fino al kernel 2.6.11 in questo caso veniva invece restituito
1319 \errcode{EINVAL}, in considerazione che il caso più comune in cui si
1320 verifica questo errore è quando si usa per sbaglio un valore negativo
1321 di \param{length}, che nel caso verrebbe interpretato come un intero
1322 positivo di grandi dimensioni.} ma il risultato verrà comunque fornito per
1323 l'intervallo compreso fino al multiplo successivo.
1325 I risultati della funzione vengono forniti nel vettore puntato da \param{vec},
1326 che deve essere allocato preventivamente e deve essere di dimensione
1327 sufficiente a contenere tanti byte quante sono le pagine contenute
1328 nell'intervallo di indirizzi specificato, la dimensione cioè deve essere
1329 almeno pari a \code{(length+PAGE\_SIZE-1)/PAGE\_SIZE}. Al ritorno della
1330 funzione il bit meno significativo di ciascun byte del vettore sarà acceso se
1331 la pagina di memoria corrispondente è al momento residente in memoria, o
1332 cancellato altrimenti. Il comportamento sugli altri bit è indefinito, essendo
1333 questi al momento riservati per usi futuri. Per questo motivo in genere è
1334 comunque opportuno inizializzare a zero il contenuto del vettore, così che le
1335 pagine attualmente residenti in memoria saranno indicata da un valore non
1336 nullo del byte corrispondente.
1338 Dato che lo stato della memoria di un processo può cambiare continuamente, il
1339 risultato di \func{mincore} è assolutamente provvisorio e lo stato delle
1340 pagine potrebbe essere già cambiato al ritorno stesso della funzione, a meno
1341 che, come vedremo ora, non si sia attivato il meccanismo che forza il
1342 mantenimento di una pagina sulla memoria.
1344 \itindbeg{memory~locking}
1346 Il meccanismo che previene la paginazione di parte della memoria virtuale di
1347 un processo è chiamato \textit{memory locking} (o \textsl{blocco della
1348 memoria}). Il blocco è sempre associato alle pagine della memoria virtuale
1349 del processo, e non al segmento reale di RAM su cui essa viene mantenuta. La
1350 regola è che se un segmento di RAM fa da supporto ad almeno una pagina
1351 bloccata allora esso viene escluso dal meccanismo della paginazione. I blocchi
1352 non si accumulano, se si blocca due volte la stessa pagina non è necessario
1353 sbloccarla due volte, una pagina o è bloccata oppure no.
1355 Il \textit{memory lock} persiste fintanto che il processo che detiene la
1356 memoria bloccata non la sblocca. Chiaramente la terminazione del processo
1357 comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
1358 tutti i suoi \textit{memory lock}. Inoltre i \textit{memory lock} non sono
1359 ereditati dai processi figli, ma siccome Linux usa il \textit{copy on write}
1360 (vedi sez.~\ref{sec:proc_fork}) gli indirizzi virtuali del figlio sono
1361 mantenuti sullo stesso segmento di RAM del padre, e quindi fintanto che un
1362 figlio non scrive su un segmento bloccato, può usufruire del \textit{memory
1363 lock} del padre. Infine i \textit{memory lock} vengono automaticamente
1364 rimossi se si pone in esecuzione un altro programma con \func{exec} (vedi
1365 sez.~\ref{sec:proc_exec}).
1367 Il sistema pone dei limiti all'ammontare di memoria di un processo che può
1368 essere bloccata e al totale di memoria fisica che si può dedicare a questo, lo
1369 standard POSIX.1 richiede che sia definita in \headfile{unistd.h} la macro
1370 \macrod{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
1371 \textit{memory locking}.
1373 Siccome la richiesta di un \textit{memory lock} da parte di un processo riduce
1374 la memoria fisica disponibile nel sistema per gli altri processi, questo ha un
1375 evidente impatto su tutti gli altri processi, per cui fino al kernel 2.6.9
1376 solo un processo dotato di privilegi amministrativi (la \textit{capability}
1377 \const{CAP\_IPC\_LOCK}, vedi sez.~\ref{sec:proc_capabilities}) aveva la
1378 capacità di bloccare una pagina di memoria.
1380 A partire dal kernel 2.6.9 anche un processo normale può bloccare la propria
1381 memoria\footnote{la funzionalità è stata introdotta per non essere costretti a
1382 dare privilegi eccessivi a programmi di crittografia, che necessitano di
1383 questa funzionalità, ma che devono essere usati da utenti normali.} ma
1384 mentre un processo privilegiato non ha limiti sulla quantità di memoria che
1385 può bloccare, un processo normale è soggetto al limite della risorsa
1386 \const{RLIMIT\_MEMLOCK} (vedi sez.~\ref{sec:sys_resource_limit}). In generale
1387 poi ogni processo può sbloccare le pagine relative alla propria memoria, se
1388 però diversi processi bloccano la stessa pagina questa resterà bloccata
1389 fintanto che ci sarà almeno un processo che la blocca.
1391 Le funzioni di sistema per bloccare e sbloccare la paginazione di singole
1392 sezioni di memoria sono rispettivamente \funcd{mlock} e \funcd{munlock}; i
1393 loro prototipi sono:
1397 \fdecl{int mlock(const void *addr, size\_t len)}
1398 \fdesc{Blocca la paginazione su un intervallo di memoria.}
1400 \fdecl{int munlock(const void *addr, size\_t len)}
1401 \fdesc{Rimuove il blocco della paginazione su un intervallo di memoria.}
1403 {Entrambe le funzioni ritornano $0$ in caso di successo e $-1$ in caso di
1404 errore, nel qual caso \var{errno} assumerà uno dei valori:
1406 \item[\errcode{EINVAL}] \param{len} non è un valore positivo.
1407 \item[\errcode{ENOMEM}] alcuni indirizzi dell’intervallo specificato non
1408 corrispondono allo spazio di indirizzi del processo o si è superato il
1409 limite di \const{RLIMIT\_MEMLOCK} per un processo non privilegiato (solo
1410 per kernel a partire dal 2.6.9).
1411 \item[\errcode{EPERM}] il processo non è privilegiato (per kernel precedenti
1412 il 2.6.9) o si ha un limite nullo per \const{RLIMIT\_MEMLOCK} e
1413 il processo non è privilegiato (per kernel a partire dal 2.6.9).
1417 Le due funzioni permettono rispettivamente di bloccare e sbloccare la
1418 paginazione per l'intervallo di memoria iniziante all'indirizzo \param{addr} e
1419 lungo \param{len} byte. Tutte le pagine che contengono una parte
1420 dell'intervallo bloccato sono mantenute in RAM per tutta la durata del
1421 blocco. Con kernel diversi da Linux si può ottenere un errore di
1422 \errcode{EINVAL} se \param{addr} non è un multiplo della dimensione delle
1423 pagine di memoria, pertanto se si ha a cuore la portabilità si deve avere cura
1424 di allinearne correttamente il valore.
1426 Altre due funzioni di sistema, \funcd{mlockall} e \funcd{munlockall},
1427 consentono di bloccare genericamente la paginazione per l'intero spazio di
1428 indirizzi di un processo. I prototipi di queste funzioni sono:
1432 \fdecl{int mlockall(int flags)}
1433 \fdesc{Blocca la paginazione per lo spazio di indirizzi del processo corrente.}
1434 \fdecl{int munlockall(void)}
1435 \fdesc{Sblocca la paginazione per lo spazio di indirizzi del processo corrente.}
1437 {Codici di ritorno ed errori sono gli stessi di \func{mlock} e \func{munlock},
1438 tranne per \errcode{EINVAL} che viene restituito solo se si è specificato
1439 con \func{mlockall} un valore sconosciuto per \param{flags}.}
1442 L'argomento \param{flags} di \func{mlockall} permette di controllarne il
1443 comportamento; esso deve essere specificato come maschera binaria dei valori
1444 espressi dalle costanti riportate in tab.~\ref{tab:mlockall_flags}.
1449 \begin{tabular}[c]{|l|p{8cm}|}
1451 \textbf{Valore} & \textbf{Significato} \\
1454 \constd{MCL\_CURRENT}& blocca tutte le pagine correntemente mappate nello
1455 spazio di indirizzi del processo.\\
1456 \constd{MCL\_FUTURE} & blocca tutte le pagine che verranno mappate nello
1457 spazio di indirizzi del processo.\\
1460 \caption{Valori e significato dell'argomento \param{flags} della funzione
1462 \label{tab:mlockall_flags}
1465 Con \func{mlockall} si possono bloccare tutte le pagine mappate nello spazio
1466 di indirizzi del processo, sia che comprendano il segmento di testo, di dati,
1467 lo \textit{stack}, lo \textit{heap} e pure le funzioni di libreria chiamate, i
1468 file mappati in memoria, i dati del kernel mappati in user space, la memoria
1469 condivisa. L'uso dell'argomento \param{flags} permette di selezionare con
1470 maggior finezza le pagine da bloccare, ad esempio usando \const{MCL\_FUTURE}
1471 ci si può limitare a tutte le pagine allocate a partire dalla chiamata della
1474 In ogni caso un processo \textit{real-time} che deve entrare in una sezione
1475 critica (vedi sez.~\ref{sec:proc_race_cond}) deve provvedere a riservare
1476 memoria sufficiente prima dell'ingresso, per scongiurare l'occorrenza di un
1477 eventuale \textit{page fault} causato dal meccanismo di \textit{copy on
1478 write}. Infatti se nella sezione critica si va ad utilizzare memoria che
1479 non è ancora stata riportata in RAM si potrebbe avere un \textit{page fault}
1480 durante l'esecuzione della stessa, con conseguente rallentamento
1481 (probabilmente inaccettabile) dei tempi di esecuzione.
1483 In genere si ovvia a questa problematica chiamando una funzione che ha
1484 allocato una quantità sufficientemente ampia di variabili automatiche, in modo
1485 che esse vengano mappate in RAM dallo \textit{stack}, dopo di che, per essere
1486 sicuri che esse siano state effettivamente portate in memoria, ci si scrive
1489 \itindend{memory~locking}
1490 \index{memoria~virtuale|)}
1493 \subsection{Gestione avanzata dell'allocazione della memoria}
1494 \label{sec:proc_memory_adv_management}
1496 La trattazione delle funzioni di allocazione di sez.~\ref{sec:proc_mem_alloc}
1497 si è limitata a coprire le esigenze generiche di un programma, in cui non si
1498 hanno dei requisiti specifici e si lascia il controllo delle modalità di
1499 allocazione alle funzioni di libreria. Tuttavia esistono una serie di casi in
1500 cui può essere necessario avere un controllo più dettagliato delle modalità
1501 con cui la memoria viene allocata; nel qual caso potranno venire in aiuto le
1502 funzioni trattate in questa sezione.
1504 Le prime funzioni che tratteremo sono quelle che consentono di richiedere di
1505 allocare un blocco di memoria ``\textsl{allineato}'' ad un multiplo una certa
1506 dimensione. Questo tipo di esigenza emerge usualmente quando si devono
1507 allocare dei buffer da utilizzare per eseguire dell'I/O diretto su dispositivi
1508 a blocchi. In questo caso infatti il trasferimento di dati viene eseguito per
1509 blocchi di dimensione fissa, ed è richiesto che l'indirizzo di partenza del
1510 buffer sia un multiplo intero di questa dimensione, usualmente 512 byte. In
1511 tal caso l'uso di \func{malloc} non è sufficiente, ed occorre utilizzare una
1514 Tradizionalmente per rispondere a questa esigenza sono state create due
1515 funzioni diverse, \funcd{memalign} e \funcd{valloc}, oggi obsolete; i
1516 rispettivi prototipi sono:
1520 \fdecl{void *valloc(size\_t size)}
1521 \fdesc{Alloca un blocco di memoria allineato alla dimensione di una pagina di
1523 \fdecl{void *memalign(size\_t boundary, size\_t size)}
1524 \fdesc{Alloca un blocco di memoria allineato ad un multiplo
1525 di \param{boundary}.}
1527 {Entrambe le funzioni ritornano un puntatore al blocco di memoria allocato in
1528 caso di successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
1529 assumerà uno dei valori:
1531 \item[\errcode{EINVAL}] \param{boundary} non è una potenza di due.
1532 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione.
1536 Le funzioni restituiscono il puntatore al buffer di memoria allocata di
1537 dimensioni pari a \param{size}, che per \func{memalign} sarà un multiplo
1538 di \param{boundary} mentre per \func{valloc} un multiplo della dimensione di
1539 una pagina di memoria. Nel caso della versione fornita dalla \acr{glibc} la
1540 memoria allocata con queste funzioni deve essere liberata con \func{free},
1541 cosa che non è detto accada con altre implementazioni.
1543 Nessuna delle due funzioni ha una chiara standardizzazione e nessuna delle due
1544 compare in POSIX.1, inoltre ci sono indicazioni discordi sui file che ne
1545 contengono la definizione;\footnote{secondo SUSv2 \func{valloc} è definita in
1546 \headfile{stdlib.h}, mentre sia le \acr{glibc} che le precedenti \acr{libc4}
1547 e \acr{libc5} la dichiarano in \headfile{malloc.h}, lo stesso vale per
1548 \func{memalign} che in alcuni sistemi è dichiarata in \headfile{stdlib.h}.}
1549 per questo motivo il loro uso è sconsigliato, essendo state sostituite dalla
1550 nuova \funcd{posix\_memalign}, che è stata standardizzata in POSIX.1d; il suo
1555 \fdecl{posix\_memalign(void **memptr, size\_t alignment, size\_t size)}
1556 \fdesc{Alloca un buffer di memoria allineato ad un multiplo
1557 di \param{alignment}.}
1559 {Entrambe le funzioni ritornano un puntatore al blocco di memoria allocato in
1560 caso di successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
1561 assumerà uno dei valori:
1563 \item[\errcode{EINVAL}] \param{alignment} non è potenza di due e multiplo
1564 di \code{sizeof(void *)}.
1565 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione.
1569 La funzione restituisce il puntatore al buffer allocato di dimensioni pari
1570 a \param{size} nella variabile (di tipo \texttt{void *}) posta all'indirizzo
1571 indicato da \param{memptr}. La funzione fallisce nelle stesse condizioni delle
1572 due funzioni precedenti, ma a loro differenza restituisce direttamente come
1573 valore di ritorno il codice di errore. Come per le precedenti la memoria
1574 allocata con \func{posix\_memalign} deve essere disallocata con \func{free},
1575 che in questo caso però è quanto richiesto dallo standard. Si tenga presente
1576 infine che nessuna di queste funzioni inizializza il buffer di memoria
1577 allocato, il loro comportamento cioè è analogo, allineamento a parte, a quello
1580 Un secondo caso in cui risulta estremamente utile poter avere un maggior
1581 controllo delle modalità di allocazione della memoria è quello in cui cercano
1582 errori di programmazione. Esempi di questi errori sono i \textit{double free},
1583 o i cosiddetti \itindex{buffer~overrun} \textit{buffer overrun}, cioè le
1584 scritture su un buffer oltre le dimensioni della sua
1585 allocazione,\footnote{entrambe queste operazioni causano in genere la
1586 corruzione dei dati di controllo delle funzioni di allocazione, che vengono
1587 anch'essi mantenuti nello \textit{heap} per tenere traccia delle zone di
1588 memoria allocata.} o i classici \textit{memory leak}.
1590 Abbiamo visto in sez.~\ref{sec:proc_mem_lock} come una prima funzionalità di
1591 ausilio nella ricerca di questi errori sia l'uso della variabile di ambiente
1592 \envvar{MALLOC\_CHECK\_}. Una modalità alternativa per effettuare dei
1593 controlli di consistenza sullo stato delle allocazioni di memoria eseguite con
1594 \func{malloc}, anche questa fornita come estensione specifica (e non standard)
1595 della \acr{glibc}, è quella di utilizzare la funzione \funcd{mcheck}, che deve
1596 essere chiamata prima di eseguire qualunque allocazione con \func{malloc}; il
1601 \fdecl{int mcheck(void (*abortfn) (enum mcheck\_status status))}
1602 \fdesc{Attiva i controlli di consistenza delle allocazioni di memoria.}
1604 {La funzione ritorna $0$ in caso di successo e $-1$ per un errorre;
1605 \var{errno} non viene impostata.}
1608 La funzione consente di registrare una funzione di emergenza che verrà
1609 eseguita tutte le volte che, in una successiva esecuzione di \func{malloc},
1610 venissero trovate delle inconsistenze, come delle operazioni di scrittura
1611 oltre i limiti dei buffer allocati. Per questo motivo la funzione deve essere
1612 chiamata prima di qualunque allocazione di memoria, altrimenti fallirà.
1614 Se come primo argomento di \func{mcheck} si passa \val{NULL} verrà utilizzata
1615 una funzione predefinita che stampa un messaggio di errore ed invoca la
1616 funzione \func{abort} (vedi sez.~\ref{sec:sig_alarm_abort}), altrimenti si
1617 dovrà creare una funzione personalizzata in grado di ricevere il tipo di
1618 errore ed agire di conseguenza.
1620 Nonostante la scarsa leggibilità del prototipo si tratta semplicemente di
1621 definire una funzione di tipo \code{void abortfn(enum mcheck\_status status)},
1622 che non deve restituire nulla e che deve avere un unico argomento di tipo
1623 \code{mcheck\_status}. In caso di errore la funzione verrà eseguita ricevendo
1624 un opportuno valore di \param{status} che è un tipo enumerato che può assumere
1625 soltanto i valori di tab.~\ref{tab:mcheck_status_value} che indicano la
1626 tipologia di errore riscontrata.
1631 \begin{tabular}[c]{|l|p{7cm}|}
1633 \textbf{Valore} & \textbf{Significato} \\
1636 \constd{MCHECK\_OK} & Riportato a \func{mprobe} se nessuna
1637 inconsistenza è presente.\\
1638 \constd{MCHECK\_DISABLED}& Riportato a \func{mprobe} se si è chiamata
1639 \func{mcheck} dopo aver già usato
1641 \constd{MCHECK\_HEAD} & I dati immediatamente precedenti il buffer sono
1642 stati modificati, avviene in genere quando si
1643 decrementa eccessivamente il valore di un
1644 puntatore scrivendo poi prima dell'inizio del
1646 \constd{MCHECK\_TAIL} & I dati immediatamente seguenti il buffer sono
1647 stati modificati, succede quando si va scrivere
1648 oltre la dimensione corretta del buffer.\\
1649 \constd{MCHECK\_FREE} & Il buffer è già stato disallocato.\\
1652 \caption{Valori dello stato dell'allocazione di memoria ottenibili dalla
1653 funzione di terminazione installata con \func{mcheck}.}
1654 \label{tab:mcheck_status_value}
1657 Una volta che si sia chiamata \func{mcheck} con successo si può anche
1658 controllare esplicitamente lo stato delle allocazioni senza aspettare un
1659 errore nelle relative funzioni utilizzando la funzione \funcd{mprobe}, il cui
1664 \fdecl{enum mcheck\_status mprobe(ptr)}
1665 \fdesc{Esegue un controllo di consistenza delle allocazioni.}
1667 {La funzione ritorna un codice fra quelli riportati in
1668 tab.~\ref{tab:mcheck_status_value} e non ha errori.}
1671 La funzione richiede che si passi come argomento un puntatore ad un blocco di
1672 memoria precedentemente allocato con \func{malloc} o \func{realloc}, e
1673 restituisce lo stesso codice di errore che si avrebbe per la funzione di
1674 emergenza ad una successiva chiamata di una funzione di allocazione, e poi i
1675 primi due codici che indicano rispettivamente quando tutto è a posto o il
1676 controllo non è possibile per non aver chiamato \func{mcheck} in tempo.
1678 % TODO: trattare le altre funzionalità avanzate di \func{malloc}, mallopt,
1679 % mtrace, muntrace, mallinfo e gli hook con le glibc 2.10 c'è pure malloc_info
1680 % a sostituire mallinfo, vedi http://udrepper.livejournal.com/20948.html
1683 \section{Argomenti, ambiente ed altre proprietà di un processo}
1684 \label{sec:proc_options}
1686 In questa sezione esamineremo le funzioni che permettono di gestire gli
1687 argomenti e le opzioni, e quelle che consentono di manipolare ed utilizzare le
1688 variabili di ambiente. Accenneremo infine alle modalità con cui si può gestire
1689 la localizzazione di un programma modificandone il comportamento a seconda
1690 della lingua o del paese a cui si vuole faccia riferimento nelle sue
1693 \subsection{Il formato degli argomenti}
1694 \label{sec:proc_par_format}
1696 Tutti i programmi hanno la possibilità di ricevere argomenti e opzioni quando
1697 vengono lanciati e come accennato in sez.~\ref{sec:proc_main} questo viene
1698 effettuato attraverso gli argomenti \param{argc} e \param{argv} ricevuti nella
1699 funzione \code{main} all'avvio del programma. Questi argomenti vengono passati
1700 al programma dalla shell o dal processo che esegue la \func{exec} (secondo le
1701 modalità che vedremo in sez.~\ref{sec:proc_exec}) quando questo viene messo in
1704 Nel caso più comune il passaggio di argomenti ed opzioni viene effettuato
1705 dalla shell, che si incarica di leggere la linea di comando con cui si lancia
1706 il programma e di effettuarne la scansione (il cosiddetto \textit{parsing})
1707 per individuare le parole che la compongono, ciascuna delle quali potrà essere
1708 considerata un argomento o un'opzione.
1710 Di norma per individuare le parole che andranno a costituire la lista degli
1711 argomenti viene usato come carattere di separazione lo spazio o il tabulatore,
1712 ma la cosa dipende ovviamente dalle modalità con cui si effettua la scansione
1713 e dalle convenzioni adottate dal programma che la esegue: ad esempio la shell
1714 consente di proteggere con opportuni caratteri di controllo argomenti che
1715 contengono degli spazi evitando di spezzarli in parole diverse.
1719 % \includegraphics[width=13cm]{img/argv_argc}
1720 % \includegraphics[width=13cm]{img/argv_argc}
1721 \begin{tikzpicture}[>=stealth]
1722 \draw (0.5,2.5) rectangle (3.5,3);
1723 \draw (2,2.75) node {\texttt{argc = 5}};
1724 \draw (5,2.5) rectangle (8,3);
1725 \draw (6.5,2.75) node {\texttt{argv[0]}};
1726 \draw [->] (8,2.75) -- (9,2.75);
1727 \draw (9,2.75) node [anchor=west] {\texttt{"touch"}};
1728 \draw (5,2) rectangle (8,2.5);
1729 \draw (6.5,2.25) node {\texttt{argv[1]}};
1730 \draw [->] (8,2.25) -- (9,2.25);
1731 \draw (9,2.25) node [anchor=west] {\texttt{"-r"}};
1732 \draw (5,1.5) rectangle (8,2);
1733 \draw (6.5,1.75) node {\texttt{argv[2]}};
1734 \draw [->] (8,1.75) -- (9,1.75);
1735 \draw (9,1.75) node [anchor=west] {\texttt{"riferimento.txt"}};
1736 \draw (5,1.0) rectangle (8,1.5);
1737 \draw (6.5,1.25) node {\texttt{argv[3]}};
1738 \draw [->] (8,1.25) -- (9,1.25);
1739 \draw (9,1.25) node [anchor=west] {\texttt{"-m"}};
1740 \draw (5,0.5) rectangle (8,1.0);
1741 \draw (6.5,0.75) node {\texttt{argv[4]}};
1742 \draw [->] (8,0.75) -- (9,0.75);
1743 \draw (9,0.75) node [anchor=west] {\texttt{"questofile.txt"}};
1744 \draw (4.25,3.5) node{\texttt{"touch -r riferimento.txt -m questofile.txt"}};
1747 \caption{Esempio dei valori di \param{argv} e \param{argc} generati nella
1748 scansione di una riga di comando.}
1749 \label{fig:proc_argv_argc}
1752 Indipendentemente da come viene eseguita, il risultato finale della scansione
1753 dovrà comunque essere la costruzione del vettore di puntatori \param{argv} in
1754 cui si devono inserire in successione i puntatori alle stringhe costituenti i
1755 vari argomenti ed opzioni da passare al programma, e della
1756 variabile \param{argc} che deve essere inizializzata al numero di stringhe
1757 contenute in \param{argv}. Nel caso della shell questo comporta ad esempio che
1758 il primo argomento sia sempre il nome del programma. Un esempio di questo
1759 meccanismo è mostrato in fig.~\ref{fig:proc_argv_argc}, che illustra il
1760 risultato della scansione di una riga di comando.
1763 \subsection{La gestione delle opzioni}
1764 \label{sec:proc_opt_handling}
1766 In generale un programma Unix riceve da linea di comando sia gli argomenti che
1767 le opzioni, queste ultime sono standardizzate per essere riconosciute come
1768 tali: un elemento di \param{argv} successivo al primo che inizia con il
1769 carattere ``\texttt{-}'' e che non sia un singolo ``\texttt{-}'' o un
1770 ``\texttt{-{}-}'' viene considerato un'opzione. In genere le opzioni sono
1771 costituite da una lettera singola (preceduta dal carattere ``\texttt{-}'') e
1772 possono avere o no un parametro associato. Un esempio tipico può essere quello
1773 mostrato in fig.~\ref{fig:proc_argv_argc}. In quel caso le opzioni sono
1774 \cmd{-r} e \cmd{-m} e la prima vuole un parametro mentre la seconda no
1775 (\cmd{questofile.txt} è un argomento del programma, non un parametro di
1778 Per gestire le opzioni all'interno degli argomenti a linea di comando passati
1779 in \param{argv} la libreria standard del C fornisce la funzione
1780 \funcd{getopt}, che ha il seguente prototipo:
1784 \fdecl{int getopt(int argc, char * const argv[], const char *optstring)}
1785 \fdesc{Esegue la scansione delle opzioni negli argomenti della funzione
1788 {Ritorna il carattere che segue l'opzione, ``\texttt{:}'' se manca un
1789 parametro all'opzione, ``\texttt{?}'' se l'opzione è sconosciuta, e $-1$ se
1790 non esistono altre opzioni.}
1793 Questa funzione prende come argomenti le due variabili \param{argc} e
1794 \param{argv} che devono essere quelle passate come argomenti di \code{main}
1795 all'esecuzione del programma, ed una stringa \param{optstring} che indica
1796 quali sono le opzioni valide. La funzione effettua la scansione della lista
1797 degli argomenti ricercando ogni stringa che comincia con il carattere
1798 ``\texttt{-}'' e ritorna ogni volta che trova un'opzione valida.
1800 La stringa \param{optstring} indica quali sono le opzioni riconosciute ed è
1801 costituita da tutti i caratteri usati per identificare le singole opzioni, se
1802 l'opzione ha un parametro al carattere deve essere fatto seguire il carattere
1803 di due punti (``\texttt{:}''); nel caso di fig.~\ref{fig:proc_argv_argc} ad
1804 esempio la stringa di opzioni avrebbe dovuto contenere \texttt{"r:m"}.
1806 La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
1807 funzione all'interno di un ciclo, fintanto che essa non ritorna il valore $-1$
1808 che indica che non ci sono più opzioni. Nel caso si incontri un'opzione non
1809 dichiarata in \param{optstring} viene ritornato il carattere ``\texttt{?}''
1810 mentre se un'opzione che lo richiede non è seguita da un parametro viene
1811 ritornato il carattere ``\texttt{:}'', infine se viene incontrato il valore
1812 ``\texttt{-{}-}'' la scansione viene considerata conclusa, anche se vi sono
1813 altri elementi di \param{argv} che cominciano con il carattere ``\texttt{-}''.
1815 \begin{figure}[!htb]
1816 \footnotesize \centering
1817 \begin{minipage}[c]{\codesamplewidth}
1818 \includecodesample{listati/option_code.c}
1821 \caption{Esempio di codice per la gestione delle opzioni.}
1822 \label{fig:proc_options_code}
1825 Quando \func{getopt} trova un'opzione fra quelle indicate in \param{optstring}
1826 essa ritorna il valore numerico del carattere, in questo modo si possono
1827 eseguire azioni specifiche usando uno \instruction{switch}; la funzione
1828 inoltre inizializza alcune variabili globali:
1830 \item \var{char *optarg} contiene il puntatore alla stringa parametro
1832 \item \var{int optind} alla fine della scansione restituisce l'indice del
1833 primo elemento di \param{argv} che non è un'opzione.
1834 \item \var{int opterr} previene, se posto a zero, la stampa di un messaggio
1835 di errore in caso di riconoscimento di opzioni non definite.
1836 \item \var{int optopt} contiene il carattere dell'opzione non riconosciuta.
1839 In fig.~\ref{fig:proc_options_code} si è mostrata la sezione del programma
1840 \file{fork\_test.c}, che useremo nel prossimo capitolo per effettuare dei test
1841 sulla creazione dei processi, deputata alla decodifica delle opzioni a riga di
1842 comando da esso supportate.
1844 Si può notare che si è anzitutto (\texttt{\small 1}) disabilitata la stampa di
1845 messaggi di errore per opzioni non riconosciute, per poi passare al ciclo per
1846 la verifica delle opzioni (\texttt{\small 2-27}); per ciascuna delle opzioni
1847 possibili si è poi provveduto ad un'azione opportuna, ad esempio per le tre
1848 opzioni che prevedono un parametro si è effettuata la decodifica del medesimo,
1849 il cui indirizzo è contenuto nella variabile \var{optarg}), avvalorando la
1850 relativa variabile (\texttt{\small 12-14}, \texttt{\small 15-17} e
1851 \texttt{\small 18-20}). Completato il ciclo troveremo in \var{optind}
1852 l'indice in \code{argv[]} del primo degli argomenti rimanenti nella linea di
1855 Normalmente \func{getopt} compie una permutazione degli elementi di
1856 \param{argv} cosicché alla fine della scansione gli elementi che non sono
1857 opzioni sono spostati in coda al vettore. Oltre a questa esistono altre due
1858 modalità di gestire gli elementi di \param{argv}; se \param{optstring} inizia
1859 con il carattere ``\texttt{+}'' (o è impostata la variabile di ambiente
1860 \cmd{POSIXLY\_CORRECT}) la scansione viene fermata non appena si incontra un
1861 elemento che non è un'opzione.
1863 L'ultima modalità, usata quando un programma può gestire la mescolanza fra
1864 opzioni e argomenti, ma se li aspetta in un ordine definito, si attiva
1865 quando \param{optstring} inizia con il carattere ``\texttt{-}''. In questo caso
1866 ogni elemento che non è un'opzione viene considerato comunque un'opzione e
1867 associato ad un valore di ritorno pari ad 1, questo permette di identificare
1868 gli elementi che non sono opzioni, ma non effettua il riordinamento del
1869 vettore \param{argv}.
1872 \subsection{Le variabili di ambiente}
1873 \label{sec:proc_environ}
1875 \index{variabili!di~ambiente|(}
1876 Oltre agli argomenti passati a linea di comando esiste un'altra modalità che
1877 permette di trasferire ad un processo delle informazioni in modo da
1878 modificarne il comportamento. Ogni processo infatti riceve dal sistema, oltre
1879 alle variabili \param{argv} e \param{argc} anche un \textsl{ambiente} (in
1880 inglese \textit{environment}); questo viene espresso nella forma di una lista
1881 (chiamata \textit{environment list}) delle cosiddette \textsl{variabili di
1882 ambiente}, i valori di queste variabili possono essere poi usati dal
1885 Anche in questo caso la lista delle \textsl{variabili di ambiente} deve essere
1886 costruita ed utilizzata nella chiamata alla funzione \func{exec} (torneremo su
1887 questo in sez.~\ref{sec:proc_exec}) quando questo viene lanciato. Come per la
1888 lista degli argomenti anche questa lista è un vettore di puntatori a
1889 caratteri, ciascuno dei quali punta ad una stringa, terminata da un
1890 \val{NULL}. A differenza di \code{argv[]} in questo caso non si ha una
1891 lunghezza del vettore data da un equivalente di \param{argc}, ma la lista è
1892 terminata da un puntatore nullo.
1894 L'indirizzo della lista delle variabili di ambiente è passato attraverso la
1895 variabile globale \var{environ}, che viene definita automaticamente per
1896 ciascun processo, e a cui si può accedere attraverso una semplice
1897 dichiarazione del tipo:
1898 \includecodesnip{listati/env_ptr.c}
1899 un esempio della struttura di questa lista, contenente alcune delle variabili
1900 più comuni che normalmente sono definite dal sistema, è riportato in
1901 fig.~\ref{fig:proc_envirno_list}.
1904 % \includegraphics[width=15 cm]{img/environ_var}
1905 \begin{tikzpicture}[>=stealth]
1906 \draw (2,3.5) node {\textsf{Environment pointer}};
1907 \draw (6,3.5) node {\textsf{Environment list}};
1908 \draw (10.5,3.5) node {\textsf{Environment string}};
1909 \draw (0.5,2.5) rectangle (3.5,3);
1910 \draw (2,2.75) node {\texttt{environ}};
1911 \draw [->] (3.5,2.75) -- (4.5,2.75);
1912 \draw (4.5,2.5) rectangle (7.5,3);
1913 \draw (6,2.75) node {\texttt{environ[0]}};
1914 \draw (4.5,2) rectangle (7.5,2.5);
1915 \draw (6,2.25) node {\texttt{environ[1]}};
1916 \draw (4.5,1.5) rectangle (7.5,2);
1917 \draw (4.5,1) rectangle (7.5,1.5);
1918 \draw (4.5,0.5) rectangle (7.5,1);
1919 \draw (4.5,0) rectangle (7.5,0.5);
1920 \draw (6,0.25) node {\texttt{NULL}};
1921 \draw [->] (7.5,2.75) -- (8.5,2.75);
1922 \draw (8.5,2.75) node[right] {\texttt{HOME=/home/piccardi}};
1923 \draw [->] (7.5,2.25) -- (8.5,2.25);
1924 \draw (8.5,2.25) node[right] {\texttt{PATH=:/bin:/usr/bin}};
1925 \draw [->] (7.5,1.75) -- (8.5,1.75);
1926 \draw (8.5,1.75) node[right] {\texttt{SHELL=/bin/bash}};
1927 \draw [->] (7.5,1.25) -- (8.5,1.25);
1928 \draw (8.5,1.25) node[right] {\texttt{EDITOR=emacs}};
1929 \draw [->] (7.5,0.75) -- (8.5,0.75);
1930 \draw (8.5,0.75) node[right] {\texttt{OSTYPE=linux-gnu}};
1932 \caption{Esempio di lista delle variabili di ambiente.}
1933 \label{fig:proc_envirno_list}
1936 Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
1937 \textsl{\texttt{NOME=valore}} ed in questa forma che le funzioni di gestione
1938 che vedremo a breve se le aspettano, se pertanto si dovesse costruire
1939 manualmente un ambiente si abbia cura di rispettare questa convenzione.
1940 Inoltre alcune variabili, come quelle elencate in
1941 fig.~\ref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
1942 da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
1943 usare nomi espressi in caratteri maiuscoli.\footnote{ma si tratta solo di una
1944 convenzione, niente vieta di usare caratteri minuscoli, come avviene in vari
1947 Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
1948 riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
1949 costituiscono un modo comodo per definire un comportamento specifico senza
1950 dover ricorrere all'uso di opzioni a linea di comando o di file di
1951 configurazione. É di norma cura della shell, quando esegue un comando, passare
1952 queste variabili al programma messo in esecuzione attraverso un uso opportuno
1953 delle relative chiamate (si veda sez.~\ref{sec:proc_exec}).
1955 La shell ad esempio ne usa molte per il suo funzionamento, come \envvar{PATH}
1956 per indicare la lista delle directory in cui effettuare la ricerca dei comandi
1957 o \envvar{PS1} per impostare il proprio \textit{prompt}. Alcune di esse, come
1958 \envvar{HOME}, \envvar{USER}, ecc. sono invece definite al login (per i
1959 dettagli si veda sez.~\ref{sec:sess_login}), ed in genere è cura della propria
1960 distribuzione definire le opportune variabili di ambiente in uno script di
1961 avvio. Alcune servono poi come riferimento generico per molti programmi, come
1962 \envvar{EDITOR} che indica l'editor preferito da invocare in caso di
1963 necessità. Una in particolare, \envvar{LANG}, serve a controllare la
1964 localizzazione del programma
1965 %(su cui torneremo in sez.~\ref{sec:proc_localization})
1966 per adattarlo alla lingua ed alle convezioni
1969 Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
1970 comuni), come riportato in tab.~\ref{tab:proc_env_var}. GNU/Linux le supporta
1971 tutte e ne definisce anche altre, in particolare poi alcune funzioni di
1972 libreria prevedono la presenza di specifiche variabili di ambiente che ne
1973 modificano il comportamento, come quelle usate per indicare una localizzazione
1974 e quelle per indicare un fuso orario; una lista più completa che comprende
1975 queste ed ulteriori variabili si può ottenere con il comando \cmd{man 7
1981 \begin{tabular}[c]{|l|c|c|c|l|}
1983 \textbf{Variabile} & \textbf{POSIX} & \textbf{XPG3}
1984 & \textbf{Linux} & \textbf{Descrizione} \\
1987 \texttt{USER} &$\bullet$&$\bullet$&$\bullet$& Nome utente.\\
1988 \texttt{LOGNAME}&$\bullet$&$\bullet$&$\bullet$& Nome di login.\\
1989 \texttt{HOME} &$\bullet$&$\bullet$&$\bullet$& Directory base
1991 \texttt{LANG} &$\bullet$&$\bullet$&$\bullet$& Localizzazione.\\
1992 \texttt{PATH} &$\bullet$&$\bullet$&$\bullet$& Elenco delle directory
1994 \texttt{PWD} &$\bullet$&$\bullet$&$\bullet$& Directory corrente.\\
1995 \texttt{SHELL} &$\bullet$&$\bullet$&$\bullet$& Shell in uso.\\
1996 \texttt{TERM} &$\bullet$&$\bullet$&$\bullet$& Tipo di terminale.\\
1997 \texttt{PAGER} &$\bullet$&$\bullet$&$\bullet$& Programma per vedere i
1999 \texttt{EDITOR} &$\bullet$&$\bullet$&$\bullet$& Editor preferito.\\
2000 \texttt{BROWSER}&$\bullet$&$\bullet$&$\bullet$& Browser preferito.\\
2001 \texttt{TMPDIR} &$\bullet$&$\bullet$&$\bullet$& Directory dei file
2005 \caption{Esempi delle variabili di ambiente più comuni definite da vari
2007 \label{tab:proc_env_var}
2010 Lo standard ANSI C prevede l'esistenza di un ambiente, e pur non entrando
2011 nelle specifiche di come sono strutturati i contenuti, definisce la funzione
2012 \funcd{getenv} che permette di ottenere i valori delle variabili di ambiente;
2017 \fdecl{char *getenv(const char *name)}
2018 \fdesc{Cerca una variabile di ambiente del processo.}
2020 {La funzione ritorna il puntatore alla stringa contenente il valore della
2021 variabile di ambiente in caso di successo e \val{NULL} per un errore.}
2024 La funzione effettua una ricerca nell'ambiente del processo cercando una
2025 variabile il cui nome corrisponda a quanto indicato con
2026 l'argomento \param{name}, ed in caso di successo ritorna il puntatore alla
2027 stringa che ne contiene il valore, nella forma ``\texttt{NOME=valore}''.
2032 \begin{tabular}[c]{|l|c|c|c|c|c|c|}
2034 \textbf{Funzione} & \textbf{ANSI C} & \textbf{POSIX.1} & \textbf{XPG3} &
2035 \textbf{SVr4} & \textbf{BSD} & \textbf{Linux} \\
2038 \func{getenv} & $\bullet$ & $\bullet$ & $\bullet$
2039 & $\bullet$ & $\bullet$ & $\bullet$ \\
2040 \func{setenv} & -- & -- & --
2041 & -- & $\bullet$ & $\bullet$ \\
2042 \func{unsetenv}& -- & -- & --
2043 & -- & $\bullet$ & $\bullet$ \\
2044 \func{putenv} & -- & opz. & $\bullet$
2045 & -- & $\bullet$ & $\bullet$ \\
2046 \func{clearenv}& -- & opz. & --
2047 & -- & -- & $\bullet$ \\
2050 \caption{Funzioni per la gestione delle variabili di ambiente.}
2051 \label{tab:proc_env_func}
2054 Oltre a questa funzione di lettura, che è l'unica definita dallo standard ANSI
2055 C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
2056 utilizzare per impostare, modificare e per cancellare le variabili di
2057 ambiente. Uno schema delle funzioni previste nei vari standard e disponibili
2058 in Linux è riportato in tab.~\ref{tab:proc_env_func}. Tutte le funzioni sono
2059 state comunque inserite nello standard POSIX.1-2001, ad eccetto di
2060 \func{clearenv} che è stata rigettata.
2062 In Linux sono definite tutte le funzioni elencate in
2063 tab.~\ref{tab:proc_env_func},\footnote{in realtà nelle libc4 e libc5 sono
2064 definite solo le prime quattro, \func{clearenv} è stata introdotta con la
2065 \acr{glibc} 2.0.} anche se parte delle funzionalità sono ridondanti. La
2066 prima funzione di manipolazione che prenderemo in considerazione è
2067 \funcd{putenv}, che consente di aggiungere, modificare e cancellare una
2068 variabile di ambiente; il suo prototipo è:
2071 \fdecl{int putenv(char *string)}
2072 \fdesc{Inserisce, modifica o rimuove una variabile d'ambiente.}
2074 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, che può
2075 essere solo \errval{ENOMEM}.}
2078 La funzione prende come argomento una stringa analoga a quella restituita da
2079 \func{getenv} e sempre nella forma ``\texttt{NOME=valore}''. Se la variabile
2080 specificata (nel caso \texttt{NOME}) non esiste la stringa sarà aggiunta
2081 all'ambiente, se invece esiste il suo valore sarà impostato a quello
2082 specificato dal contenuto di \param{string} (nel caso \texttt{valore}). Se
2083 invece si passa come argomento solo il nome di una variabile di ambiente
2084 (cioè \param{string} è nella forma ``\texttt{NOME}'' e non contiene il
2085 carattere ``\texttt{=}'') allora questa, se presente nell'ambiente, verrà
2088 Si tenga presente che, seguendo lo standard SUSv2, le \acr{glibc} successive
2089 alla versione 2.1.2 aggiungono direttamente \param{string} nella lista delle
2090 variabili di ambiente illustrata in fig.~\ref{fig:proc_envirno_list}
2091 sostituendo il relativo puntatore;\footnote{il comportamento è lo stesso delle
2092 vecchie \acr{libc4} e \acr{libc5}; nella \acr{glibc}, dalla versione 2.0
2093 alla 2.1.1, veniva invece fatta una copia, seguendo il comportamento di
2094 BSD4.4; dato che questo può dar luogo a perdite di memoria e non rispetta lo
2095 standard il comportamento è stato modificato a partire dalle 2.1.2,
2096 eliminando anche, sempre in conformità a SUSv2, l'attributo \direct{const}
2097 dal prototipo.} pertanto ogni cambiamento alla stringa in questione si
2098 riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
2099 questa funzione una variabile automatica (per evitare i problemi esposti in
2100 sez.~\ref{sec:proc_var_passing}). Benché non sia richiesto dallo standard
2101 nelle versioni della \acr{glibc} a partire dalla 2.1 la funzione è rientrante
2102 (vedi sez.~\ref{sec:proc_reentrant}).
2104 Infine quando una chiamata a \func{putenv} comporta la necessità di creare una
2105 nuova versione del vettore \var{environ} questo sarà allocato automaticamente,
2106 ma la versione corrente sarà deallocata solo se anch'essa è risultante da
2107 un'allocazione fatta in precedenza da un'altra \func{putenv}. Questo avviene
2108 perché il vettore delle variabili di ambiente iniziale, creato dalla chiamata
2109 ad \func{exec} (vedi sez.~\ref{sec:proc_exec}) è piazzato nella memoria al di
2110 sopra dello \textit{stack}, (vedi fig.~\ref{fig:proc_mem_layout}) e non nello
2111 \textit{heap} e quindi non può essere deallocato. Inoltre la memoria
2112 associata alle variabili di ambiente eliminate non viene liberata.
2114 Come alternativa a \func{putenv} si può usare la funzione \funcd{setenv} che
2115 però consente solo di aggiungere o modificare una variabile di ambiente; il
2120 \fdecl{int setenv(const char *name, const char *value, int overwrite)}
2121 \fdesc{Inserisce o modifica una variabile di ambiente.}
2123 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
2124 nel qual caso \var{errno} assumerà uno dei valori:
2126 \item[\errcode{EINVAL}] \param{name} è \val{NULL} o una stringa di lunghezza
2127 nulla o che contiene il carattere ``\texttt{=}''.
2128 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per aggiungere una nuova
2129 variabile all'ambiente.
2133 La funzione consente di specificare separatamente nome e valore della
2134 variabile di ambiente da aggiungere negli argomenti \param{name}
2135 e \param{value}. Se la variabile è già presente nell'ambiente
2136 l'argomento \param{overwrite} specifica il comportamento della funzione, se
2137 diverso da zero sarà sovrascritta, se uguale a zero sarà lasciata immutata. A
2138 differenza di \func{putenv} la funzione esegue delle copie del contenuto degli
2139 argomenti \param{name} e \param{value} e non è necessario preoccuparsi di
2140 allocarli in maniera permanente.
2142 La cancellazione di una variabile di ambiente viene invece gestita
2143 esplicitamente con \funcd{unsetenv}, il cui prototipo è:
2147 \fdecl{int unsetenv(const char *name)}
2148 \fdesc{Rimuove una variabile di ambiente.}
2150 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
2151 nel qual caso \var{errno} assumerà uno dei valori:
2153 \item[\errcode{EINVAL}] \param{name} è \val{NULL} o una stringa di lunghezza
2154 nulla o che contiene il carattere ``\texttt{=}''.
2158 La funzione richiede soltanto il nome della variabile di ambiente
2159 nell'argomento \param{name}, se la variabile non esiste la funzione ritorna
2160 comunque con un valore di successo.\footnote{questo con le versioni della
2161 \acr{glibc} successive la 2.2.2, per le precedenti \func{unsetenv} era
2162 definita come \texttt{void} e non restituiva nessuna informazione.}
2164 L'ultima funzione per la gestione dell'ambiente è
2165 \funcd{clearenv},\footnote{che come accennato è l'unica non presente nello
2166 standard POSIX.1-2000, ed è disponibili solo per versioni della \acr{glibc}
2167 a partire dalla 2.0; per poterla utilizzare occorre aver definito le macro
2168 \macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE}.} che viene usata per
2169 cancellare completamente tutto l'ambiente; il suo prototipo è:
2173 \fdecl{int clearenv(void)}
2174 \fdesc{Cancella tutto l'ambiente.}
2176 {La funzione ritorna $0$ in caso di successo e un valore diverso da zero per
2180 In genere si usa questa funzione in maniera precauzionale per evitare i
2181 problemi di sicurezza connessi nel trasmettere ai programmi che si invocano un
2182 ambiente che può contenere dei dati non controllati, le cui variabili possono
2183 causare effetti indesiderati. Con l'uso della funzione si provvede alla
2184 cancellazione di tutto l'ambiente originale in modo da poterne costruirne una
2185 versione ``\textsl{sicura}'' da zero.
2187 \index{variabili!di~ambiente|)}
2190 % \subsection{La localizzazione}
2191 % \label{sec:proc_localization}
2193 % Abbiamo accennato in sez.~\ref{sec:proc_environ} come la variabile di ambiente
2194 % \envvar{LANG} sia usata per indicare ai processi il valore della cosiddetta
2195 % \textsl{localizzazione}. Si tratta di una funzionalità fornita dalle librerie
2196 % di sistema\footnote{prenderemo in esame soltanto il caso della \acr{glibc}.}
2197 % che consente di gestire in maniera automatica sia la lingua in cui vengono
2198 % stampati i vari messaggi (come i messaggi associati agli errori che vedremo in
2199 % sez.~\ref{sec:sys_strerror}) che le convenzioni usate nei vari paesi per una
2200 % serie di aspetti come il formato dell'ora, quello delle date, gli ordinamenti
2201 % alfabetici, le espressioni della valute, ecc.
2205 % La localizzazione di un programma si può selezionare con la
2207 % In realtà perché un programma sia effettivamente localizzato non è sufficiente
2209 % TODO trattare, quando ci sarà tempo, setlocale ed il resto
2212 %\subsection{Opzioni in formato esteso}
2213 %\label{sec:proc_opt_extended}
2215 %Oltre alla modalità ordinaria di gestione delle opzioni trattata in
2216 %sez.~\ref{sec:proc_opt_handling} le \acr{glibc} forniscono una modalità
2217 %alternativa costituita dalle cosiddette \textit{long-options}, che consente di
2218 %esprimere le opzioni in una forma più descrittiva che nel caso più generale è
2219 %qualcosa del tipo di ``\texttt{-{}-option-name=parameter}''.
2221 %(NdA: questa parte verrà inserita in seguito).
2223 % TODO opzioni in formato esteso
2225 % TODO trattare il vettore ausiliario e getauxval (vedi
2226 % http://lwn.net/Articles/519085/)
2229 \section{Problematiche di programmazione generica}
2230 \label{sec:proc_gen_prog}
2232 Benché questo non sia un libro sul linguaggio C, è opportuno affrontare alcune
2233 delle problematiche generali che possono emergere nella programmazione con
2234 questo linguaggio e di quali precauzioni o accorgimenti occorre prendere per
2235 risolverle. Queste problematiche non sono specifiche di sistemi unix-like o
2236 multitasking, ma avendo trattato in questo capitolo il comportamento dei
2237 processi visti come entità a sé stanti, le riportiamo qui.
2240 \subsection{Il passaggio di variabili e valori di ritorno nelle funzioni}
2241 \label{sec:proc_var_passing}
2243 Una delle caratteristiche standard del C è che le variabili vengono passate
2244 alle funzioni che si invocano in un programma attraverso un meccanismo che
2245 viene chiamato \textit{by value}, diverso ad esempio da quanto avviene con il
2246 Fortran, dove le variabili sono passate, come suol dirsi, \textit{by
2247 reference}, o dal C++ dove la modalità del passaggio può essere controllata
2248 con l'operatore \cmd{\&}.
2250 Il passaggio di una variabile \textit{by value} significa che in realtà quello
2251 che viene passato alla funzione è una copia del valore attuale di quella
2252 variabile, copia che la funzione potrà modificare a piacere, senza che il
2253 valore originale nella funzione chiamante venga toccato. In questo modo non
2254 occorre preoccuparsi di eventuali effetti delle operazioni svolte nella
2255 funzione stessa sulla variabile passata come argomento.
2257 Questo però va inteso nella maniera corretta. Il passaggio \textit{by value}
2258 vale per qualunque variabile, puntatori compresi; quando però in una funzione
2259 si usano dei puntatori (ad esempio per scrivere in un buffer) in realtà si va
2260 a modificare la zona di memoria a cui essi puntano, per cui anche se i
2261 puntatori sono copie, i dati a cui essi puntano saranno sempre gli stessi, e
2262 le eventuali modifiche avranno effetto e saranno visibili anche nella funzione
2265 Nella maggior parte delle funzioni di libreria e delle \textit{system call} i
2266 puntatori vengono usati per scambiare dati (attraverso i buffer o le strutture
2267 a cui fanno riferimento) e le variabili normali vengono usate per specificare
2268 argomenti; in genere le informazioni a riguardo dei risultati vengono passate
2269 alla funzione chiamante attraverso il valore di ritorno. È buona norma
2270 seguire questa pratica anche nella programmazione normale.
2272 \itindbeg{value~result~argument}
2274 Talvolta però è necessario che la funzione possa restituire indietro alla
2275 funzione chiamante un valore relativo ad uno dei suoi argomenti usato anche in
2276 ingresso. Per far questo si usa il cosiddetto \textit{value result argument},
2277 si passa cioè, invece di una normale variabile, un puntatore alla stessa. Gli
2278 esempi di questa modalità di passaggio sono moltissimi, ad esempio essa viene
2279 usata nelle funzioni che gestiscono i socket (in
2280 sez.~\ref{sec:TCP_functions}), in cui, per permettere al kernel di restituire
2281 informazioni sulle dimensioni delle strutture degli indirizzi utilizzate,
2282 viene usato proprio questo meccanismo.
2284 Occorre tenere ben presente questa differenza, perché le variabili passate in
2285 maniera ordinaria, che vengono inserite nello \textit{stack}, cessano di
2286 esistere al ritorno di una funzione, ed ogni loro eventuale modifica
2287 all'interno della stessa sparisce con la conclusione della stessa, per poter
2288 passare delle informazioni occorre quindi usare un puntatore che faccia
2289 riferimento ad un indirizzo accessibile alla funzione chiamante.
2291 \itindend{value~result~argument}
2293 Questo requisito di accessibilità è fondamentale, infatti dei possibili
2294 problemi che si possono avere con il passaggio dei dati è quello di restituire
2295 alla funzione chiamante dei dati che sono contenuti in una variabile
2296 automatica. Ovviamente quando la funzione ritorna la sezione dello
2297 \textit{stack} che conteneva la variabile automatica (si ricordi quanto detto
2298 in sez.~\ref{sec:proc_mem_alloc}) verrà liberata automaticamente e potrà
2299 essere riutilizzata all'invocazione di un'altra funzione, con le immaginabili
2300 conseguenze, quasi invariabilmente catastrofiche, di sovrapposizione e
2301 sovrascrittura dei dati.
2303 Per questo una delle regole fondamentali della programmazione in C è che
2304 all'uscita di una funzione non deve restare nessun riferimento alle sue
2305 variabili locali. Qualora sia necessario utilizzare delle variabili che devono
2306 essere viste anche dalla funzione chiamante queste devono essere allocate
2307 esplicitamente, o in maniera statica usando variabili globali o dichiarate
2308 come \direct{extern},\footnote{la direttiva \direct{extern} informa il
2309 compilatore che la variabile che si è dichiarata in una funzione non è da
2310 considerarsi locale, ma globale, e per questo allocata staticamente e
2311 visibile da tutte le funzioni dello stesso programma.} o dinamicamente con
2312 una delle funzioni della famiglia \func{malloc}, passando opportunamente il
2313 relativo puntatore fra le funzioni.
2316 \subsection{Il passaggio di un numero variabile di argomenti}
2317 \label{sec:proc_variadic}
2319 \index{funzioni!\textit{variadic}|(}
2321 Come vedremo nei capitoli successivi, non sempre è possibile specificare un
2322 numero fisso di argomenti per una funzione. Lo standard ISO C prevede nella
2323 sua sintassi la possibilità di definire delle \textit{variadic function} che
2324 abbiano un numero variabile di argomenti, attraverso l'uso nella dichiarazione
2325 della funzione dello speciale costrutto ``\texttt{...}'', che viene chiamato
2328 Lo standard però non provvede a livello di linguaggio alcun meccanismo con cui
2329 dette funzioni possono accedere ai loro argomenti. L'accesso viene pertanto
2330 realizzato a livello della libreria standard del C che fornisce gli strumenti
2331 adeguati. L'uso di una \textit{variadic function} prevede quindi tre punti:
2333 \item \textsl{dichiarare} la funzione come \textit{variadic} usando un
2334 prototipo che contenga una \textit{ellipsis};
2335 \item \textsl{definire} la funzione come \textit{variadic} usando la stessa
2336 \textit{ellipsis}, ed utilizzare le apposite macro che consentono la
2337 gestione di un numero variabile di argomenti;
2338 \item \textsl{invocare} la funzione specificando prima gli argomenti fissi, ed
2339 a seguire quelli addizionali.
2342 Lo standard ISO C prevede che una \textit{variadic function} abbia sempre
2343 almeno un argomento fisso. Prima di effettuare la dichiarazione deve essere
2344 incluso l'apposito \textit{header file} \headfile{stdarg.h}; un esempio di
2345 dichiarazione è il prototipo della funzione \func{execl} che vedremo in
2346 sez.~\ref{sec:proc_exec}:
2347 \includecodesnip{listati/exec_sample.c}
2348 in questo caso la funzione prende due argomenti fissi ed un numero variabile
2349 di altri argomenti, che andranno a costituire gli elementi successivi al primo
2350 del vettore \param{argv} passato al nuovo processo. Lo standard ISO C richiede
2351 inoltre che l'ultimo degli argomenti fissi sia di tipo
2352 \textit{self-promoting}\footnote{il linguaggio C prevede che quando si
2353 mescolano vari tipi di dati, alcuni di essi possano essere \textsl{promossi}
2354 per compatibilità; ad esempio i tipi \ctyp{float} vengono convertiti
2355 automaticamente a \ctyp{double} ed i \ctyp{char} e gli \ctyp{short} ad
2356 \ctyp{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
2357 a sé stesso.} il che esclude vettori, puntatori a funzioni e interi di tipo
2358 \ctyp{char} o \ctyp{short} (con segno o meno). Una restrizione ulteriore di
2359 alcuni compilatori è di non dichiarare l'ultimo argomento fisso come variabile
2360 di tipo \direct{register}.\footnote{la direttiva \direct{register} del
2361 compilatore chiede che la variabile dichiarata tale sia mantenuta, nei
2362 limiti del possibile, all'interno di un registro del processore; questa
2363 direttiva è originaria dell'epoca dai primi compilatori, quando stava al
2364 programmatore scrivere codice ottimizzato, riservando esplicitamente alle
2365 variabili più usate l'uso dei registri del processore, oggi questa direttiva
2366 è in disuso pressoché completo dato che tutti i compilatori sono normalmente
2367 in grado di valutare con maggior efficacia degli stessi programmatori quando
2368 sia il caso di eseguire questa ottimizzazione.}
2370 Una volta dichiarata la funzione il secondo passo è accedere ai vari argomenti
2371 quando la si va a definire. Gli argomenti fissi infatti hanno un loro nome, ma
2372 quelli variabili vengono indicati in maniera generica dalla
2373 \textit{ellipsis}. L'unica modalità in cui essi possono essere recuperati è
2374 pertanto quella sequenziale, in cui vengono estratti dallo \textit{stack}
2375 secondo l'ordine in cui sono stati scritti nel prototipo della funzione.
2377 \macrobeg{va\_start}
2379 Per fare questo in \headfile{stdarg.h} sono definite delle macro specifiche,
2380 previste dallo standard ISO C89, che consentono di eseguire questa operazione.
2381 La prima di queste macro è \macro{va\_start}, che inizializza opportunamente
2382 una lista degli argomenti, la sua definizione è:
2387 \fdecl{void va\_start(va\_list ap, last)}
2388 \fdesc{Inizializza una lista degli argomenti di una funzione
2393 La macro inizializza il puntatore alla lista di argomenti \param{ap} che deve
2394 essere una apposita variabile di tipo \type{va\_list}; il
2395 parametro \param{last} deve indicare il nome dell'ultimo degli argomenti fissi
2396 dichiarati nel prototipo della funzione \textit{variadic}.
2400 La seconda macro di gestione delle liste di argomenti di una funzione
2401 \textit{variadic} è \macro{va\_arg}, che restituisce in successione un
2402 argomento della lista; la sua definizione è:
2407 \fdecl{type va\_arg(va\_list ap, type)}
2408 \fdesc{Restituisce il valore del successivo argomento opzionale.}
2412 La macro restituisce il valore di un argomento, modificando opportunamente la
2413 lista \param{ap} perché una chiamata successiva restituisca l'argomento
2414 seguente. La macro richiede che si specifichi il tipo dell'argomento che si
2415 andrà ad estrarre attraverso il parametro \param{type} che sarà anche il tipo
2416 del valore da essa restituito. Si ricordi che il tipo deve essere
2417 \textit{self-promoting}.
2419 In generale è perfettamente legittimo richiedere meno argomenti di quelli che
2420 potrebbero essere stati effettivamente forniti, per cui nella esecuzione delle
2421 \macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
2422 saranno ignorati. Se invece si richiedono più argomenti di quelli
2423 effettivamente forniti si otterranno dei valori indefiniti. Si avranno
2424 risultati indefiniti anche quando si chiama \macro{va\_arg} specificando un
2425 tipo che non corrisponde a quello usato per il corrispondente argomento.
2429 Infine una volta completata l'estrazione occorre indicare che si sono concluse
2430 le operazioni con la macro \macrod{va\_end}, la cui definizione è:
2435 \fdecl{void va\_end(va\_list ap)}
2436 \fdesc{Conclude l'estrazione degli argomenti di una funzione
2441 Dopo l'uso di \macro{va\_end} la variabile \param{ap} diventa indefinita e
2442 successive chiamate a \macro{va\_arg} non funzioneranno. Nel caso del
2443 \cmd{gcc} l'uso di \macro{va\_end} può risultare inutile, ma è comunque
2444 necessario usarla per chiarezza del codice, per compatibilità con diverse
2445 implementazioni e per eventuali eventuali modifiche future a questo
2448 Riassumendo la procedura da seguire per effettuare l'estrazione degli
2449 argomenti di una funzione \textit{variadic} è la seguente:
2451 \item inizializzare una lista degli argomenti attraverso la macro
2453 \item accedere agli argomenti con chiamate successive alla macro
2454 \macro{va\_arg}: la prima chiamata restituirà il primo argomento, la seconda
2455 il secondo e così via;
2456 \item dichiarare la conclusione dell'estrazione degli argomenti invocando la
2457 macro \macro{va\_end}.
2460 Si tenga presente che si possono usare anche più liste degli argomenti,
2461 ciascuna di esse andrà inizializzata con \macro{va\_start} e letta con
2462 \macro{va\_arg}, e ciascuna potrà essere usata per scandire la lista degli
2463 argomenti in modo indipendente. Infine ciascuna scansione dovrà essere
2464 terminata con \macro{va\_end}.
2466 Un limite di queste macro è che i passi 1) e 3) devono essere eseguiti nel
2467 corpo principale della funzione, il passo 2) invece può essere eseguito anche
2468 in un'altra funzione, passandole lista degli argomenti \param{ap}. In questo
2469 caso però al ritorno della funzione \macro{va\_arg} non può più essere usata
2470 (anche se non si era completata l'estrazione) dato che il valore di \param{ap}
2471 risulterebbe indefinito.
2473 \macroend{va\_start}
2477 Esistono dei casi in cui è necessario eseguire più volte la scansione degli
2478 argomenti e poter memorizzare una posizione durante la stessa. In questo caso
2479 sembrerebbe naturale copiarsi la lista degli argomenti \param{ap} con una
2480 semplice assegnazione ad un'altra variabile dello stesso tipo. Dato che una
2481 delle realizzazioni più comuni di \type{va\_list} è quella di un puntatore
2482 nello \textit{stack} all'indirizzo dove sono stati salvati gli argomenti, è
2483 assolutamente normale pensare di poter effettuare questa operazione.
2485 \index{tipo!opaco|(}
2487 In generale però possono esistere anche realizzazioni diverse, ed è per questo
2488 motivo che invece che un semplice puntatore, \typed{va\_list} è quello che
2489 viene chiamato un \textsl{tipo opaco}. Si chiamano così quei tipi di dati, in
2490 genere usati da una libreria, la cui struttura interna non deve essere vista
2491 dal programma chiamante (da cui deriva il nome opaco) che li devono utilizzare
2492 solo attraverso dalle opportune funzioni di gestione.
2494 \index{tipo!opaco|)}
2496 Per questo motivo una variabile di tipo \typed{va\_list} non può essere
2497 assegnata direttamente ad un'altra variabile dello stesso tipo, ma lo standard
2498 ISO C99\footnote{alcuni sistemi che non hanno questa macro provvedono al suo
2499 posto \macrod{\_\_va\_copy} che era il nome proposto in una bozza dello
2500 standard.} ha previsto una macro ulteriore che permette di eseguire la
2501 copia di una lista degli argomenti:
2506 \fdecl{void va\_copy(va\_list dest, va\_list src)}
2507 \fdesc{Copia la lista degli argomenti di una funzione \textit{variadic}.}
2511 La macro copia l'attuale della lista degli argomenti \param{src} su una nuova
2512 lista \param{dest}. Anche in questo caso è buona norma chiudere ogni
2513 esecuzione di una \macrod{va\_copy} con una corrispondente \macro{va\_end} sul
2514 nuovo puntatore alla lista degli argomenti.
2516 La chiamata di una funzione con un numero variabile di argomenti, posto che la
2517 si sia dichiarata e definita come tale, non prevede nulla di particolare;
2518 l'invocazione è identica alle altre, con gli argomenti, sia quelli fissi che
2519 quelli opzionali, separati da virgole. Quello che però è necessario tenere
2520 presente è come verranno convertiti gli argomenti variabili.
2522 In Linux gli argomenti dello stesso tipo sono passati allo stesso modo, sia
2523 che siano fissi sia che siano opzionali (alcuni sistemi trattano diversamente
2524 gli opzionali), ma dato che il prototipo non può specificare il tipo degli
2525 argomenti opzionali, questi verranno sempre promossi, pertanto nella ricezione
2526 dei medesimi occorrerà tenerne conto (ad esempio un \ctyp{char} verrà visto da
2527 \macro{va\_arg} come \ctyp{int}).
2529 Un altro dei problemi che si devono affrontare con le funzioni con un numero
2530 variabile di argomenti è che non esiste un modo generico che permetta di
2531 stabilire quanti sono gli argomenti effettivamente passati in una chiamata.
2533 Esistono varie modalità per affrontare questo problema; una delle più
2534 immediate è quella di specificare il numero degli argomenti opzionali come uno
2535 degli argomenti fissi. Una variazione di questo metodo è l'uso di un argomento
2536 fisso per specificare anche il tipo degli argomenti variabili, come fa la
2537 stringa di formato per \func{printf} (vedi sez.~\ref{sec:file_formatted_io}).
2539 Infine una ulteriore modalità diversa, che può essere applicata solo quando il
2540 tipo degli argomenti lo rende possibile, è quella che prevede di usare un
2541 valore speciale per l'ultimo argomento, come fa ad esempio \func{execl} che
2542 usa un puntatore \val{NULL} per indicare la fine della lista degli argomenti
2543 (vedi sez.~\ref{sec:proc_exec}).
2545 \index{funzioni!\textit{variadic}|)}
2547 \subsection{Il controllo di flusso non locale}
2548 \label{sec:proc_longjmp}
2550 Il controllo del flusso di un programma in genere viene effettuato con le
2551 varie istruzioni del linguaggio C; fra queste la più bistrattata è il
2552 \instruction{goto}, che viene deprecato in favore dei costrutti della
2553 programmazione strutturata, che rendono il codice più leggibile e
2554 mantenibile. Esiste però un caso in cui l'uso di questa istruzione porta
2555 all'implementazione più efficiente e più chiara anche dal punto di vista della
2556 struttura del programma: quello dell'uscita in caso di errore.
2558 \index{salto~non-locale|(}
2560 Il C però non consente di effettuare un salto ad una etichetta definita in
2561 un'altra funzione, per cui se l'errore avviene in una funzione, e la sua
2562 gestione ordinaria è in un'altra, occorre usare quello che viene chiamato un
2563 \textsl{salto non-locale}. Il caso classico in cui si ha questa necessità,
2564 citato sia in \cite{APUE} che in \cite{GlibcMan}, è quello di un programma nel
2565 cui corpo principale vengono letti dei dati in ingresso sui quali viene
2566 eseguita, tramite una serie di funzioni di analisi, una scansione dei
2567 contenuti, da cui si ottengono le indicazioni per l'esecuzione di opportune
2570 Dato che l'analisi può risultare molto complessa, ed opportunamente suddivisa
2571 in fasi diverse, la rilevazione di un errore nei dati in ingresso può accadere
2572 all'interno di funzioni profondamente annidate l'una nell'altra. In questo
2573 caso si dovrebbe gestire, per ciascuna fase, tutta la casistica del passaggio
2574 all'indietro di tutti gli errori rilevabili dalle funzioni usate nelle fasi
2575 successive. Questo comporterebbe una notevole complessità, mentre sarebbe
2576 molto più comodo poter tornare direttamente al ciclo di lettura principale,
2577 scartando l'input come errato.\footnote{a meno che, come precisa
2578 \cite{GlibcMan}, alla chiusura di ciascuna fase non siano associate
2579 operazioni di pulizia specifiche (come deallocazioni, chiusure di file,
2580 ecc.), che non potrebbero essere eseguite con un salto non-locale.}
2582 Tutto ciò può essere realizzato proprio con un salto non-locale; questo di
2583 norma viene realizzato salvando il contesto dello \textit{stack} nel punto in
2584 cui si vuole tornare in caso di errore, e ripristinandolo, in modo da tornare
2585 quando serve nella funzione da cui si era partiti. La funzione che permette
2586 di salvare il contesto dello \textit{stack} è \funcd{setjmp}, il cui prototipo
2591 \fdecl{int setjmp(jmp\_buf env)}
2592 \fdesc{Salva il contesto dello \textit{stack}.}
2594 {La funzione ritorna $0$ quando è chiamata direttamente ed un valore diverso
2595 da zero quando ritorna da una chiamata di \func{longjmp} che usa il contesto
2596 salvato in precedenza.}
2599 Quando si esegue la funzione il contesto corrente dello \textit{stack} viene
2600 salvato nell'argomento \param{env}, una variabile di tipo
2601 \typed{jmp\_buf}\footnote{anche questo è un classico esempio di variabile di
2602 \textsl{tipo opaco}.} che deve essere stata definita in precedenza. In
2603 genere le variabili di tipo \type{jmp\_buf} vengono definite come variabili
2604 globali in modo da poter essere viste in tutte le funzioni del programma.
2606 Quando viene eseguita direttamente la funzione ritorna sempre zero, un valore
2607 diverso da zero viene restituito solo quando il ritorno è dovuto ad una
2608 chiamata di \func{longjmp} in un'altra parte del programma che ripristina lo
2609 \textit{stack} effettuando il salto non-locale. Si tenga conto che il contesto
2610 salvato in \param{env} viene invalidato se la funzione che ha chiamato
2611 \func{setjmp} ritorna, nel qual caso un successivo uso di \func{longjmp} può
2612 comportare conseguenze imprevedibili (e di norma fatali) per il processo.
2614 Come accennato per effettuare un salto non-locale ad un punto precedentemente
2615 stabilito con \func{setjmp} si usa la funzione \funcd{longjmp}; il suo
2620 \fdecl{void longjmp(jmp\_buf env, int val)}
2621 \fdesc{Ripristina il contesto dello stack.}
2623 {La funzione non ritorna.}
2626 La funzione ripristina il contesto dello \textit{stack} salvato da una
2627 chiamata a \func{setjmp} nell'argomento \param{env}. Dopo l'esecuzione della
2628 funzione il programma prosegue nel codice successivo alla chiamata della
2629 \func{setjmp} con cui si era salvato \param{env}, che restituirà il valore
2630 dell'argomento \param{val} invece di zero. Il valore
2631 dell'argomento \param{val} deve essere sempre diverso da zero, se si è
2632 specificato 0 sarà comunque restituito 1 al suo posto.
2634 In sostanza l'esecuzione di \func{longjmp} è analoga a quella di una
2635 istruzione \instr{return}, solo che invece di ritornare alla riga
2636 successiva della funzione chiamante, il programma in questo caso ritorna alla
2637 posizione della relativa \func{setjmp}. L'altra differenza fondamentale con
2638 \instr{return} è che il ritorno può essere effettuato anche attraverso
2639 diversi livelli di funzioni annidate.
2641 L'implementazione di queste funzioni comporta alcune restrizioni dato che esse
2642 interagiscono direttamente con la gestione dello \textit{stack} ed il
2643 funzionamento del compilatore stesso. In particolare \func{setjmp} è
2644 implementata con una macro, pertanto non si può cercare di ottenerne
2645 l'indirizzo, ed inoltre le chiamate a questa funzione sono sicure solo in uno
2648 \item come espressione di controllo in un comando condizionale, di selezione o
2649 di iterazione (come \instruction{if}, \instruction{switch} o
2650 \instruction{while});
2651 \item come operando per un operatore di uguaglianza o confronto in una
2652 espressione di controllo di un comando condizionale, di selezione o di
2654 \item come operando per l'operatore di negazione (\code{!}) in una espressione
2655 di controllo di un comando condizionale, di selezione o di iterazione;
2656 \item come espressione a sé stante.
2659 In generale, dato che l'unica differenza fra la chiamata diretta e quella
2660 ottenuta nell'uscita con un \func{longjmp} è costituita dal valore di ritorno
2661 di \func{setjmp}, pertanto quest'ultima viene usualmente chiamata all'interno
2662 di un una istruzione \instr{if} che permetta di distinguere i due casi.
2664 Uno dei punti critici dei salti non-locali è quello del valore delle
2665 variabili, ed in particolare quello delle variabili automatiche della funzione
2666 a cui si ritorna. In generale le variabili globali e statiche mantengono i
2667 valori che avevano al momento della chiamata di \func{longjmp}, ma quelli
2668 delle variabili automatiche (o di quelle dichiarate \dirct{register}) sono in
2669 genere indeterminati.
2671 Quello che succede infatti è che i valori delle variabili che sono tenute in
2672 memoria manterranno il valore avuto al momento della chiamata di
2673 \func{longjmp}, mentre quelli tenuti nei registri del processore (che nella
2674 chiamata ad un'altra funzione vengono salvati nel contesto nello
2675 \textit{stack}) torneranno al valore avuto al momento della chiamata di
2676 \func{setjmp}; per questo quando si vuole avere un comportamento coerente si
2677 può bloccare l'ottimizzazione che porta le variabili nei registri
2678 dichiarandole tutte come \direct{volatile}.\footnote{la direttiva
2679 \direct{volatile} informa il compilatore che la variabile che è dichiarata
2680 può essere modificata, durante l'esecuzione del nostro, da altri programmi.
2681 Per questo motivo occorre dire al compilatore che non deve essere mai
2682 utilizzata l'ottimizzazione per cui quanto opportuno essa viene mantenuta in
2683 un registro, poiché in questo modo si perderebbero le eventuali modifiche
2684 fatte dagli altri programmi (che avvengono solo in una copia posta in
2687 \index{salto~non-locale|)}
2690 \subsection{La \textit{endianness}}
2691 \label{sec:endianness}
2693 \itindbeg{endianness}
2695 Un altro dei problemi di programmazione che può dar luogo ad effetti
2696 imprevisti è quello relativo alla cosiddetta \textit{endianness}. Questa è una
2697 caratteristica generale dell'architettura hardware di un computer che dipende
2698 dal fatto che la rappresentazione di un numero binario può essere fatta in due
2699 modi, chiamati rispettivamente \textit{big endian} e \textit{little endian} a
2700 seconda di come i singoli bit vengono aggregati per formare le variabili
2701 intere (ed in genere in diretta corrispondenza a come sono poi in realtà
2702 cablati sui bus interni del computer).
2704 \begin{figure}[!htb]
2705 \centering \includegraphics[height=3cm]{img/endianness}
2706 \caption{Schema della disposizione dei dati in memoria a seconda della
2707 \textit{endianness}.}
2708 \label{fig:sock_endianness}
2711 Per capire meglio il problema si consideri un intero a 32 bit scritto in una
2712 locazione di memoria posta ad un certo indirizzo. Come illustrato in
2713 fig.~\ref{fig:sock_endianness} i singoli bit possono essere disposti in memoria
2714 in due modi: a partire dal più significativo o a partire dal meno
2715 significativo. Così nel primo caso si troverà il byte che contiene i bit più
2716 significativi all'indirizzo menzionato e il byte con i bit meno significativi
2717 nell'indirizzo successivo; questo ordinamento è detto \textit{big endian},
2718 dato che si trova per prima la parte più grande. Il caso opposto, in cui si
2719 parte dal bit meno significativo è detto per lo stesso motivo \textit{little
2722 Si può allora verificare quale tipo di \textit{endianness} usa il proprio
2723 computer con un programma elementare che si limita ad assegnare un valore ad
2724 una variabile per poi ristamparne il contenuto leggendolo un byte alla volta.
2725 Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
2726 allora se lo eseguiamo su un normale PC compatibile, che è \textit{little
2727 endian} otterremo qualcosa del tipo:
2729 [piccardi@gont sources]$ \textbf{./endtest}
2730 Using value ABCDEF01
2737 mentre su un vecchio Macintosh con PowerPC, che è \textit{big endian} avremo
2740 piccardi@anarres:~/gapil/sources$ \textbf{./endtest}
2741 Using value ABCDEF01
2749 L'attenzione alla \textit{endianness} nella programmazione è importante, perché
2750 se si fanno assunzioni relative alla propria architettura non è detto che
2751 queste restino valide su un'altra architettura. Inoltre, come vedremo ad
2752 esempio in sez.~\ref{sec:sock_addr_func}, si possono avere problemi quando ci
2753 si trova a usare valori di un formato con una infrastruttura che ne usa
2756 La \textit{endianness} di un computer dipende essenzialmente dalla architettura
2757 hardware usata; Intel e Digital usano il \textit{little endian}, Motorola,
2758 IBM, Sun (sostanzialmente tutti gli altri) usano il \textit{big endian}. Il
2759 formato dei dati contenuti nelle intestazioni dei protocolli di rete (il
2760 cosiddetto \textit{network order}) è anch'esso \textit{big endian}; altri
2761 esempi di uso di questi due diversi formati sono quello del bus PCI, che è
2762 \textit{little endian}, o quello del bus VME che è \textit{big endian}.
2764 Esistono poi anche dei processori che possono scegliere il tipo di formato
2765 all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
2766 da un tipo di ordinamento all'altro con una specifica istruzione. In ogni caso
2767 in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
2768 in genere resta sempre lo stesso,\footnote{su architettura PowerPC è possibile
2769 cambiarlo, si veda sez.~\ref{sec:process_prctl}.} anche quando il processore
2770 permetterebbe di eseguire questi cambiamenti.
2772 \begin{figure}[!htbp]
2773 \footnotesize \centering
2774 \begin{minipage}[c]{\codesamplewidth}
2775 \includecodesample{listati/endian.c}
2778 \caption{La funzione \samplefunc{endian}, usata per controllare il tipo di
2779 architettura della macchina.}
2780 \label{fig:sock_endian_code}
2783 Per controllare quale tipo di ordinamento si ha sul proprio computer si è
2784 scritta una piccola funzione di controllo, il cui codice è riportato
2785 fig.~\ref{fig:sock_endian_code}, che restituisce un valore nullo (falso) se
2786 l'architettura è \textit{big endian} ed uno non nullo (vero) se l'architettura
2787 è \textit{little endian}.
2789 Come si vede la funzione è molto semplice, e si limita, una volta assegnato
2790 (\texttt{\small 9}) un valore di test pari a \texttt{0xABCD} ad una variabile
2791 di tipo \ctyp{short} (cioè a 16 bit), a ricostruirne una copia byte a byte.
2792 Per questo prima (\texttt{\small 10}) si definisce il puntatore \var{ptr} per
2793 accedere al contenuto della prima variabile, ed infine calcola (\texttt{\small
2794 11}) il valore della seconda assumendo che il primo byte sia quello meno
2795 significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianness}, che sia
2796 \textit{little endian}). Infine la funzione restituisce (\texttt{\small 12})
2797 il valore del confronto delle due variabili.
2799 In generale non ci si deve preoccupare della \textit{endianness} all'interno
2800 di un programma fintanto che questo non deve generare o manipolare dei dati
2801 che sono scambiati con altre macchine, ad esempio tramite via rete o tramite
2802 dei file binari. Nel primo caso la scelta è già stata fatta nella
2803 standardizzazione dei protocolli, che hanno adottato il \textit{big endian}
2804 (che viene detto anche per questo \textit{network order} e vedremo in
2805 sez.~\ref{sec:sock_func_ord} le funzioni di conversione che devono essere
2808 Nel secondo caso occorre sapere quale \textit{endianness} è stata usata nei
2809 dati memorizzati sul file e tenerne conto nella rilettura e nella
2810 manipolazione e relativa modifica (e salvataggio). La gran parte dei formati
2811 binari standardizzati specificano quale \textit{endianness} viene utilizzata e
2812 basterà identificare qual'è, se se ne deve definire uno per i propri scopi
2813 basterà scegliere una volta per tutte quale usare e attenersi alla scelta.
2815 \itindend{endianness}
2818 % LocalWords: like exec kernel thread main ld linux static linker char envp Gb
2819 % LocalWords: sez POSIX exit system call cap abort shell diff errno stdlib int
2820 % LocalWords: SUCCESS FAILURE void atexit stream fclose unistd descriptor init
2821 % LocalWords: SIGCHLD wait function glibc SunOS arg argp execve fig high kb Mb
2822 % LocalWords: memory alpha swap table printf Unit MMU paging fault SIGSEGV BSS
2823 % LocalWords: multitasking text segment NULL Block Started Symbol fill black
2824 % LocalWords: heap stack calling convention size malloc calloc realloc nmemb
2825 % LocalWords: ENOMEM ptr uClib cfree error leak smartpointers hook Dmalloc brk
2826 % LocalWords: Gray Watson Electric Fence Bruce Perens sbrk longjmp SUSv BSD ap
2827 % LocalWords: ptrdiff increment locking lock copy write capabilities IPC mlock
2828 % LocalWords: capability MEMLOCK limits getpagesize RLIMIT munlock sys const
2829 % LocalWords: addr len EINVAL EPERM mlockall munlockall flags l'OR CURRENT IFS
2830 % LocalWords: argc argv parsing questofile txt getopt optstring switch optarg
2831 % LocalWords: optind opterr optopt POSIXLY CORRECT long options NdA
2832 % LocalWords: option parameter list environ PATH HOME XPG tab LOGNAME LANG PWD
2833 % LocalWords: TERM PAGER TMPDIR getenv name SVr setenv unsetenv putenv opz gcc
2834 % LocalWords: clearenv libc value overwrite string reference result argument
2835 % LocalWords: socket variadic ellipsis header stdarg execl self promoting last
2836 % LocalWords: float double short register type dest src extern setjmp jmp buf
2837 % LocalWords: env return if while Di page cdecl rectangle node anchor west PS
2838 % LocalWords: environment rounded corners dashed south width height draw east
2839 % LocalWords: exithandler handler violation inline SOURCE SVID XOPEN mincore
2840 % LocalWords: length unsigned vec EFAULT EAGAIN dell'I memalign valloc posix
2841 % LocalWords: boundary memptr alignment sizeof overrun mcheck abortfn enum big
2842 % LocalWords: mprobe DISABLED HEAD TAIL touch right emacs OSTYPE endianness IBM
2843 % LocalWords: endian little endtest Macintosh PowerPC Intel Digital Motorola
2844 % LocalWords: Sun order VME loader Windows DLL shared objects PRELOAD termios
2845 % LocalWords: is to LC SIG str mem wcs assert ctype dirent fcntl signal stdio
2846 % LocalWords: times library utmp syscall number Filesystem Hierarchy pathname
2847 % LocalWords: context assembler sysconf fork Dinamic huge segmentation program
2848 % LocalWords: break store Using
2850 %%% Local Variables:
2852 %%% TeX-master: "gapil"