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