Correzioni
[gapil.git] / process.tex
1 %% process.tex
2 %%
3 %% Copyright (C) 2000-2018 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 I risultati della funzione vengono forniti nel vettore puntato da \param{vec},
1348 che deve essere allocato preventivamente e deve essere di dimensione
1349 sufficiente a contenere tanti byte quante sono le pagine contenute
1350 nell'intervallo di indirizzi specificato, la dimensione cioè deve essere
1351 almeno pari a \code{(length+PAGE\_SIZE-1)/PAGE\_SIZE}.  Al ritorno della
1352 funzione il bit meno significativo di ciascun byte del vettore sarà acceso se
1353 la pagina di memoria corrispondente è al momento residente in memoria, o
1354 cancellato altrimenti. Il comportamento sugli altri bit è indefinito, essendo
1355 questi al momento riservati per usi futuri. Per questo motivo in genere è
1356 comunque opportuno inizializzare a zero il contenuto del vettore, così che le
1357 pagine attualmente residenti in memoria saranno indicate da un valore non
1358 nullo del byte corrispondente.
1359
1360 Dato che lo stato della memoria di un processo può cambiare continuamente, il
1361 risultato di \func{mincore} è assolutamente provvisorio e lo stato delle
1362 pagine potrebbe essere già cambiato al ritorno stesso della funzione, a meno
1363 che, come vedremo ora, non si sia attivato il meccanismo che forza il
1364 mantenimento di una pagina sulla memoria.  
1365
1366 \itindbeg{memory~locking}
1367
1368 Il meccanismo che previene la paginazione di parte della memoria virtuale di
1369 un processo è chiamato \textit{memory locking} (o \textsl{blocco della
1370   memoria}). Il blocco è sempre associato alle pagine della memoria virtuale
1371 del processo, e non al segmento reale di RAM su cui essa viene mantenuta.  La
1372 regola è che se un segmento di RAM fa da supporto ad almeno una pagina
1373 bloccata allora esso viene escluso dal meccanismo della paginazione. I blocchi
1374 non si accumulano, se si blocca due volte la stessa pagina non è necessario
1375 sbloccarla due volte, una pagina o è bloccata oppure no.
1376
1377 Il \textit{memory lock} persiste fintanto che il processo che detiene la
1378 memoria bloccata non la sblocca. Chiaramente la terminazione del processo
1379 comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
1380 tutti i suoi \textit{memory lock}.  Inoltre i \textit{memory lock} non sono
1381 ereditati dai processi figli, ma siccome Linux usa il \textit{copy on write}
1382 (vedi sez.~\ref{sec:proc_fork}) gli indirizzi virtuali del figlio sono
1383 mantenuti sullo stesso segmento di RAM del padre, e quindi fintanto che un
1384 figlio non scrive su un segmento bloccato, può usufruire del \textit{memory
1385   lock} del padre. Infine i \textit{memory lock} vengono automaticamente
1386 rimossi se si pone in esecuzione un altro programma con \func{exec} (vedi
1387 sez.~\ref{sec:proc_exec}).
1388
1389 Il sistema pone dei limiti all'ammontare di memoria di un processo che può
1390 essere bloccata e al totale di memoria fisica che si può dedicare a questo, lo
1391 standard POSIX.1 richiede che sia definita in \headfile{unistd.h} la macro
1392 \macrod{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
1393 \textit{memory locking}.
1394
1395 Siccome la richiesta di un \textit{memory lock} da parte di un processo riduce
1396 la memoria fisica disponibile nel sistema per gli altri processi, questo ha un
1397 evidente impatto su tutti gli altri processi, per cui fino al kernel 2.6.9
1398 solo un processo dotato di privilegi amministrativi (la \textit{capability}
1399 \const{CAP\_IPC\_LOCK}, vedi sez.~\ref{sec:proc_capabilities}) aveva la
1400 capacità di bloccare una pagina di memoria.
1401
1402 A partire dal kernel 2.6.9 anche un processo normale può bloccare la propria
1403 memoria\footnote{la funzionalità è stata introdotta per non essere costretti a
1404   dare privilegi eccessivi a programmi di crittografia, che necessitano di
1405   questa funzionalità, ma che devono essere usati da utenti normali.} ma
1406 mentre un processo privilegiato non ha limiti sulla quantità di memoria che
1407 può bloccare, un processo normale è soggetto al limite della risorsa
1408 \const{RLIMIT\_MEMLOCK} (vedi sez.~\ref{sec:sys_resource_limit}). In generale
1409 poi ogni processo può sbloccare le pagine relative alla propria memoria, se
1410 però diversi processi bloccano la stessa pagina questa resterà bloccata
1411 fintanto che ci sarà almeno un processo che la blocca.
1412
1413 Le funzioni di sistema per bloccare e sbloccare la paginazione di singole
1414 sezioni di memoria sono rispettivamente \funcd{mlock} e \funcd{munlock}; i
1415 loro prototipi sono:
1416
1417 \begin{funcproto}{
1418   \fhead{sys/mman.h} 
1419   \fdecl{int mlock(const void *addr, size\_t len)}
1420   \fdesc{Blocca la paginazione su un intervallo di memoria.}
1421
1422   \fdecl{int munlock(const void *addr, size\_t len)}
1423   \fdesc{Rimuove il blocco della paginazione su un intervallo di memoria.}
1424   }
1425 {Entrambe le funzioni ritornano $0$ in caso di successo e $-1$ in caso di
1426   errore, nel qual caso \var{errno} assumerà uno dei valori:
1427   \begin{errlist}
1428   \item[\errcode{EAGAIN}] una parte o tutto l'intervallo richiesto non può
1429     essere bloccato per una mancanza temporanea di risorse.
1430   \item[\errcode{EINVAL}] \param{len} non è un valore positivo o la somma con
1431     \param{addr} causa un overflow.
1432   \item[\errcode{ENOMEM}] alcuni indirizzi dell’intervallo specificato non
1433     corrispondono allo spazio di indirizzi del processo o con \func{mlock} si
1434     è superato il limite di \const{RLIMIT\_MEMLOCK} per un processo non
1435     privilegiato (solo per kernel a partire dal 2.6.9) o si è superato il
1436     limite di regioni di memoria con attributi diversi.
1437   \item[\errcode{EPERM}] il processo non è privilegiato (per kernel precedenti
1438     il 2.6.9) o si ha un limite nullo per \const{RLIMIT\_MEMLOCK} e
1439     il processo non è privilegiato (per kernel a partire dal 2.6.9).
1440   \end{errlist}}
1441 \end{funcproto}
1442
1443 Le due funzioni permettono rispettivamente di bloccare e sbloccare la
1444 paginazione per l'intervallo di memoria iniziante all'indirizzo \param{addr} e
1445 lungo \param{len} byte.  Al ritorno di \func{mlock} tutte le pagine che
1446 contengono una parte dell'intervallo bloccato sono garantite essere in RAM e
1447 vi verranno mantenute per tutta la durata del blocco. Con kernel diversi da
1448 Linux si può ottenere un errore di \errcode{EINVAL} se \param{addr} non è un
1449 multiplo della dimensione delle pagine di memoria, pertanto se si ha a cuore
1450 la portabilità si deve avere cura di allinearne correttamente il valore. Il
1451 blocco viene rimosso chiamando \func{munlock}.
1452
1453 Altre due funzioni di sistema, \funcd{mlockall} e \funcd{munlockall},
1454 consentono di bloccare genericamente la paginazione per l'intero spazio di
1455 indirizzi di un processo.  I prototipi di queste funzioni sono:
1456
1457 \begin{funcproto}{ 
1458 \fhead{sys/mman.h} 
1459 \fdecl{int mlockall(int flags)}
1460 \fdesc{Blocca la paginazione per lo spazio di indirizzi del processo corrente.} 
1461 \fdecl{int munlockall(void)}
1462 \fdesc{Sblocca la paginazione per lo spazio di indirizzi del processo corrente.}
1463 }
1464 {Codici di ritorno ed errori sono gli stessi di \func{mlock} e \func{munlock},
1465   tranne per \errcode{EINVAL} che viene restituito solo se si è specificato
1466   con \func{mlockall} un valore sconosciuto per \param{flags}.}
1467 \end{funcproto}
1468
1469 L'argomento \param{flags} di \func{mlockall} permette di controllarne il
1470 comportamento; esso deve essere specificato come maschera binaria dei valori
1471 espressi dalle costanti riportate in tab.~\ref{tab:mlockall_flags}. 
1472
1473 \begin{table}[htb]
1474   \footnotesize
1475   \centering
1476   \begin{tabular}[c]{|l|p{8cm}|}
1477     \hline
1478     \textbf{Valore} & \textbf{Significato} \\
1479     \hline
1480     \hline
1481     \constd{MCL\_CURRENT}& blocca tutte le pagine correntemente mappate nello
1482                            spazio di indirizzi del processo.\\
1483     \constd{MCL\_FUTURE} & blocca tutte le pagine che verranno mappate nello
1484                            spazio di indirizzi del processo.\\
1485     \constd{MCL\_ONFAULT}& esegue il blocco delle pagine selezionate solo
1486                            quando vengono utilizzate (dal kernel 4.4).\\
1487    \hline
1488   \end{tabular}
1489   \caption{Valori e significato dell'argomento \param{flags} della funzione
1490     \func{mlockall}.}
1491   \label{tab:mlockall_flags}
1492 \end{table}
1493
1494 Con \func{mlockall} si possono bloccare tutte le pagine mappate nello spazio
1495 di indirizzi del processo, sia che comprendano il segmento di testo, di dati,
1496 lo \textit{stack}, lo \textit{heap} e pure le funzioni di libreria chiamate, i
1497 file mappati in memoria, i dati del kernel mappati in \textit{user space}, la
1498 memoria condivisa.  L'uso dell'argomento \param{flags} permette di selezionare
1499 con maggior finezza le pagine da bloccare, ad esempio usando
1500 \const{MCL\_FUTURE} ci si può limitare a tutte le pagine allocate a partire
1501 dalla chiamata della funzione, mentre \const{MCL\_CURRENT} blocca tutte quelle
1502 correntemente mappate. L'uso di \func{munlockall} invece sblocca sempre tutte
1503 le pagine di memoria correntemente mappate nello spazio di indirizzi del
1504 programma.
1505
1506 A partire dal kernel 4.4 alla funzione \func{mlockall} è stato aggiunto un
1507 altro flag, \const{MCL\_ONFAULT}, che può essere abbinato a entrambi gli altri
1508 due flag, e consente di modificare il comportamento della funzione per
1509 ottenere migliori prestazioni.
1510
1511 Il problema che si presenta infatti è che eseguire un \textit{memory lock} per
1512 un intervallo ampio di memoria richiede che questa venga comunque allocata in
1513 RAM, con altrettanti \textit{page fault} che ne assicurino la presenza; questo
1514 vale per tutto l'intervallo e può avere un notevole costo in termini di
1515 prestazioni, anche quando poi, nell'esecuzione del programma, venisse usata
1516 solo una piccola parte dello stesso. L'uso di \const{MCL\_ONFAULT} previene il
1517 \textit{page faulting} immediato di tutto l'intervallo, le pagine
1518 dell'intervallo verranno bloccate, ma solo quando un \textit{page fault}
1519 dovuto all'accesso ne richiede l'allocazione effettiva in RAM.
1520
1521 Questo stesso comportamento non è ottenibile con \func{mlock}, che non dispone
1522 di un argomento \param{flag} che consenta di richiederlo, per questo sempre
1523 con il kernel 4.4 è stata aggiunta una ulteriore funzione di sistema,
1524 \funcd{mlock2}, il cui prototipo è:
1525
1526 \begin{funcproto}{
1527   \fhead{sys/mman.h} 
1528   \fdecl{int mlock2(const void *addr, size\_t len, int flags)}
1529   \fdesc{Blocca la paginazione su un intervallo di memoria.}
1530 }
1531 {Le funzione ritornano $0$ in caso di successo e $-1$ in caso di errore, nel
1532   qual caso \var{errno} assume gli stessi valori di \func{mlock} con
1533   l'aggiunta id un possibile \errcode{EINVAL} anche se si è indicato un valore
1534   errato di \param{flags}.}
1535 \end{funcproto}
1536
1537 % NOTA: per mlock2, introdotta con il kernel 4.4 (vedi
1538 % http://lwn.net/Articles/650538/)
1539
1540 Indicando un valore nullo per \param{flags} il comportamento della funzione è
1541 identico a quello di \func{mlock}, l'unico altro valore possibile è
1542 \constd{MLOCK\_ONFAULT} che ha lo stesso effetto sull'allocazione delle pagine
1543 in RAM già descritto per \const{MCL\_ONFAULT}.
1544
1545 Si tenga presente che un processo \textit{real-time} che intende usare il
1546 \textit{memory locking} con \func{mlockall} per prevenire l'avvenire di un
1547 eventuale \textit{page fault} ed il conseguente rallentamento (probabilmente
1548 inaccettabile) dei tempi di esecuzione, deve comunque avere delle accortezze.
1549 In particolare si deve assicurare di aver preventivamente bloccato una
1550 quantità di spazio nello \textit{stack} sufficiente a garantire l'esecuzione
1551 di tutte le funzioni che hanno i requisiti di criticità sui tempi. Infatti,
1552 anche usando \const{MCL\_FUTURE}, in caso di allocazione di una nuova pagina
1553 nello \textit{stack} durante l'esecuzione di una funzione (precedentemente non
1554 usata e quindi non bloccata) si potrebbe avere un \textit{page fault}.
1555
1556 In genere si ovvia a questa problematica chiamando inizialmente una funzione
1557 che definisca una quantità sufficientemente ampia di variabili automatiche
1558 (che si ricordi vengono allocate nello \textit{stack}) e ci scriva, in modo da
1559 esser sicuri che le corrispondenti pagine vengano mappate nello spazio di
1560 indirizzi del processo, per poi bloccarle. La scrittura è necessaria perché il
1561 kernel usa il meccanismo di \textit{copy on write} (vedi
1562 sez.~\ref{sec:proc_fork}) e le pagine potrebbero non essere allocate
1563 immediatamente.
1564
1565 \itindend{memory~locking}
1566 \index{memoria~virtuale|)} 
1567
1568
1569 \subsection{Gestione avanzata dell'allocazione della memoria} 
1570 \label{sec:proc_memory_adv_management}
1571
1572 La trattazione delle funzioni di allocazione di sez.~\ref{sec:proc_mem_alloc}
1573 si è limitata a coprire le esigenze generiche di un programma, in cui non si
1574 hanno dei requisiti specifici e si lascia il controllo delle modalità di
1575 allocazione alle funzioni di libreria.  Tuttavia esistono una serie di casi in
1576 cui può essere necessario avere un controllo più dettagliato delle modalità
1577 con cui la memoria viene allocata; nel qual caso potranno venire in aiuto le
1578 funzioni trattate in questa sezione.
1579
1580 Le prime funzioni che tratteremo sono quelle che consentono di richiedere di
1581 allocare un blocco di memoria ``\textsl{allineato}'' ad un multiplo una certa
1582 dimensione. Questo tipo di esigenza emerge usualmente quando si devono
1583 allocare dei buffer da utilizzare per eseguire dell'I/O diretto su dispositivi
1584 a blocchi. In questo caso infatti il trasferimento di dati viene eseguito per
1585 blocchi di dimensione fissa, ed è richiesto che l'indirizzo di partenza del
1586 buffer sia un multiplo intero di questa dimensione, usualmente 512 byte. In
1587 tal caso l'uso di \func{malloc} non è sufficiente, ed occorre utilizzare una
1588 funzione specifica.
1589
1590 Tradizionalmente per rispondere a questa esigenza sono state create due
1591 funzioni diverse, \funcd{memalign} e \funcd{valloc}, oggi obsolete, cui si
1592 aggiunge \funcd{pvalloc} come estensione GNU, anch'essa obsoleta; i rispettivi
1593 prototipi sono:
1594
1595 \begin{funcproto}{ 
1596 \fhead{malloc.h} 
1597 \fdecl{void *valloc(size\_t size)}
1598 \fdesc{Alloca un blocco di memoria allineato alla dimensione di una pagina di
1599   memoria.}  
1600 \fdecl{void *memalign(size\_t boundary, size\_t size)}
1601 \fdesc{Alloca un blocco di memoria allineato ad un multiplo
1602   di \param{boundary}.} 
1603 \fdecl{void *pvalloc(size\_t size)}
1604 \fdesc{Alloca un blocco di memoria allineato alla dimensione di una pagina di
1605   memoria.}  
1606 }
1607 {Entrambe le funzioni ritornano un puntatore al blocco di memoria allocato in
1608   caso di successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
1609   assumerà uno dei valori:
1610   \begin{errlist}
1611   \item[\errcode{EINVAL}] \param{boundary} non è una potenza di due.
1612   \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione.
1613   \end{errlist}}
1614 \end{funcproto}
1615
1616 Le funzioni restituiscono il puntatore al buffer di memoria allocata di
1617 dimensioni pari a \param{size}, che per \func{memalign} sarà un multiplo di
1618 \param{boundary} mentre per \func{valloc} un multiplo della dimensione di una
1619 pagina di memoria; lo stesso vale per \func{pvalloc} che però arrotonda
1620 automaticamente la dimensione dell'allocazione al primo multiplo di una
1621 pagina. Nel caso della versione fornita dalla \acr{glibc} la memoria allocata
1622 con queste funzioni deve essere liberata con \func{free}, cosa che non è detto
1623 accada con altre implementazioni.
1624
1625 Nessuna delle due funzioni ha una chiara standardizzazione e nessuna delle due
1626 compare in POSIX.1, inoltre ci sono indicazioni discordi sui file che ne
1627 contengono la definizione;\footnote{secondo SUSv2 \func{valloc} è definita in
1628   \headfile{stdlib.h}, mentre sia la \acr{glibc} che le precedenti \acr{libc4}
1629   e \acr{libc5} la dichiarano in \headfile{malloc.h}, lo stesso vale per
1630   \func{memalign} che in alcuni sistemi è dichiarata in \headfile{stdlib.h}.}
1631 per questo motivo il loro uso è sconsigliato, essendo state sostituite dalla
1632 nuova \funcd{posix\_memalign}, che è stata standardizzata in POSIX.1d e
1633 disponibile dalla \acr{glibc} 2.1.91; il suo prototipo è:
1634
1635 \begin{funcproto}{ 
1636 \fhead{stdlib.h} 
1637 \fdecl{posix\_memalign(void **memptr, size\_t alignment, size\_t size)}
1638 \fdesc{Alloca un buffer di memoria allineato ad un multiplo
1639   di \param{alignment}.}   
1640 }
1641 {Entrambe le funzioni ritornano un puntatore al blocco di memoria allocato in
1642   caso di successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
1643   assumerà uno dei valori:
1644   \begin{errlist}
1645   \item[\errcode{EINVAL}] \param{alignment} non è potenza di due o un multiplo
1646     di \code{sizeof(void *)}.
1647   \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione.
1648   \end{errlist}}
1649 \end{funcproto}
1650
1651 La funzione restituisce il puntatore al buffer allocato di dimensioni pari
1652 a \param{size} nella variabile (di tipo \texttt{void *}) posta all'indirizzo
1653 indicato da \param{memptr}. La funzione fallisce nelle stesse condizioni delle
1654 due funzioni precedenti, ma a loro differenza restituisce direttamente come
1655 valore di ritorno il codice di errore.  Come per le precedenti la memoria
1656 allocata con \func{posix\_memalign} deve essere disallocata con \func{free},
1657 che in questo caso però è quanto richiesto dallo standard.
1658
1659 Dalla versione 2.16 della \acr{glibc} è stata aggiunta anche la funzione
1660 \funcd{aligned\_alloc}, prevista dallo standard C11 (e disponibile definendo
1661 \const{\_ISOC11\_SOURCE}), il cui prototipo è:
1662
1663 \begin{funcproto}{ 
1664 \fhead{malloc.h} 
1665 \fdecl{void *aligned\_alloc(size\_t alignment, size\_t size)}
1666 \fdesc{Alloca un blocco di memoria allineato ad un multiplo
1667   di \param{alignment}.} 
1668 }
1669 {La funzione ha gli stessi valori di ritorno e codici di errore di
1670   \func{memalign}.}
1671 \end{funcproto}
1672
1673 La funzione è identica a \func{memalign} ma richiede che \param{size} sia un
1674 multiplo di \param{alignment}.  Infine si tenga presente infine che nessuna di
1675 queste funzioni inizializza il buffer di memoria allocato, il loro
1676 comportamento cioè è analogo, allineamento a parte, a quello di \func{malloc}.
1677
1678 Un secondo caso in cui risulta estremamente utile poter avere un maggior
1679 controllo delle modalità di allocazione della memoria è quello in cui cercano
1680 errori di programmazione. Esempi di questi errori sono i \textit{double free},
1681 o i cosiddetti \itindex{buffer~overrun} \textit{buffer overrun}, cioè le
1682 scritture su un buffer oltre le dimensioni della sua
1683 allocazione,\footnote{entrambe queste operazioni causano in genere la
1684   corruzione dei dati di controllo delle funzioni di allocazione, che vengono
1685   anch'essi mantenuti nello \textit{heap} per tenere traccia delle zone di
1686   memoria allocata.} o i classici \textit{memory leak}.
1687
1688 Abbiamo visto in sez.~\ref{sec:proc_mem_lock} come una prima funzionalità di
1689 ausilio nella ricerca di questi errori sia l'uso della variabile di ambiente
1690 \envvar{MALLOC\_CHECK\_}.  Una modalità alternativa per effettuare dei
1691 controlli di consistenza sullo stato delle allocazioni di memoria eseguite con
1692 \func{malloc}, anche questa fornita come estensione specifica (e non standard)
1693 della \acr{glibc}, è quella di utilizzare la funzione \funcd{mcheck}, che deve
1694 essere chiamata prima di eseguire qualunque allocazione con \func{malloc}; il
1695 suo prototipo è:
1696
1697 \begin{funcproto}{ 
1698 \fhead{mcheck.h} 
1699 \fdecl{int mcheck(void (*abortfn) (enum mcheck\_status status))}
1700 \fdesc{Attiva i controlli di consistenza delle allocazioni di memoria.}   
1701 }
1702 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore;
1703   \var{errno} non viene impostata.} 
1704 \end{funcproto}
1705
1706 La funzione consente di registrare una funzione di emergenza che verrà
1707 eseguita tutte le volte che, in una successiva esecuzione di \func{malloc},
1708 venissero trovate delle inconsistenze, come delle operazioni di scrittura
1709 oltre i limiti dei buffer allocati. Per questo motivo la funzione deve essere
1710 chiamata prima di qualunque allocazione di memoria, altrimenti fallirà.
1711
1712 Se come primo argomento di \func{mcheck} si passa \val{NULL} verrà utilizzata
1713 una funzione predefinita che stampa un messaggio di errore ed invoca la
1714 funzione \func{abort} (vedi sez.~\ref{sec:sig_alarm_abort}), altrimenti si
1715 dovrà creare una funzione personalizzata in grado di ricevere il tipo di
1716 errore ed agire di conseguenza.
1717
1718 Nonostante la scarsa leggibilità del prototipo si tratta semplicemente di
1719 definire una funzione di tipo \code{void abortfn(enum mcheck\_status status)},
1720 che non deve restituire nulla e che deve avere un unico argomento di tipo
1721 \code{mcheck\_status}. In caso di errore la funzione verrà eseguita ricevendo
1722 un opportuno valore di \param{status} che è un tipo enumerato che può assumere
1723 soltanto i valori di tab.~\ref{tab:mcheck_status_value} che indicano la
1724 tipologia di errore riscontrata.
1725
1726 \begin{table}[htb]
1727   \centering
1728   \footnotesize
1729   \begin{tabular}[c]{|l|p{7cm}|}
1730     \hline
1731     \textbf{Valore} & \textbf{Significato} \\
1732     \hline
1733     \hline
1734     \constd{MCHECK\_OK}      & Riportato a \func{mprobe} se nessuna
1735                                inconsistenza è presente.\\
1736     \constd{MCHECK\_DISABLED}& Riportato a \func{mprobe} se si è chiamata
1737                                \func{mcheck} dopo aver già usato
1738                                \func{malloc}.\\
1739     \constd{MCHECK\_HEAD}    & I dati immediatamente precedenti il buffer sono
1740                                stati modificati, avviene in genere quando si
1741                                decrementa eccessivamente il valore di un
1742                                puntatore scrivendo poi prima dell'inizio del
1743                                buffer.\\
1744     \constd{MCHECK\_TAIL}    & I dati immediatamente seguenti il buffer sono
1745                                stati modificati, succede quando si va scrivere
1746                                oltre la dimensione corretta del buffer.\\
1747     \constd{MCHECK\_FREE}    & Il buffer è già stato disallocato.\\
1748     \hline
1749   \end{tabular}
1750   \caption{Valori dello stato dell'allocazione di memoria ottenibili dalla
1751     funzione di terminazione installata con \func{mcheck}.} 
1752   \label{tab:mcheck_status_value}
1753 \end{table}
1754
1755 Una volta che si sia chiamata \func{mcheck} con successo si può anche
1756 controllare esplicitamente lo stato delle allocazioni senza aspettare un
1757 errore nelle relative funzioni utilizzando la funzione \funcd{mprobe}, il cui
1758 prototipo è:
1759
1760 \begin{funcproto}{ 
1761 \fhead{mcheck.h} 
1762 \fdecl{enum mcheck\_status mprobe(ptr)}
1763 \fdesc{Esegue un controllo di consistenza delle allocazioni.}   
1764 }
1765 {La funzione ritorna un codice fra quelli riportati in
1766    tab.~\ref{tab:mcheck_status_value} e non ha errori.} 
1767 \end{funcproto}
1768
1769 La funzione richiede che si passi come argomento un puntatore ad un blocco di
1770 memoria precedentemente allocato con \func{malloc} o \func{realloc}, e
1771 restituisce lo stesso codice di errore che si avrebbe per la funzione di
1772 emergenza ad una successiva chiamata di una funzione di allocazione, e poi i
1773 primi due codici che indicano rispettivamente quando tutto è a posto o il
1774 controllo non è possibile per non aver chiamato \func{mcheck} in tempo.
1775
1776 % TODO: trattare le altre funzionalità avanzate di \func{malloc}, mallopt,
1777 % mtrace, muntrace, mallinfo e gli hook con le glibc 2.10 c'è pure malloc_info
1778 % a sostituire mallinfo, vedi http://udrepper.livejournal.com/20948.html
1779
1780
1781 \section{Argomenti, ambiente ed altre proprietà di un processo}
1782 \label{sec:proc_options}
1783
1784 In questa sezione esamineremo le funzioni che permettono di gestire gli
1785 argomenti e le opzioni, e quelle che consentono di manipolare ed utilizzare le
1786 variabili di ambiente. Accenneremo infine alle modalità con cui si può gestire
1787 la localizzazione di un programma modificandone il comportamento a seconda
1788 della lingua o del paese a cui si vuole faccia riferimento nelle sue
1789 operazioni. 
1790
1791 \subsection{Il formato degli argomenti}
1792 \label{sec:proc_par_format}
1793
1794 Tutti i programmi hanno la possibilità di ricevere argomenti e opzioni quando
1795 vengono lanciati e come accennato in sez.~\ref{sec:proc_main} questo viene
1796 effettuato attraverso gli argomenti \param{argc} e \param{argv} ricevuti nella
1797 funzione \code{main} all'avvio del programma. Questi argomenti vengono passati
1798 al programma dalla shell o dal processo che esegue la \func{exec} (secondo le
1799 modalità che vedremo in sez.~\ref{sec:proc_exec}) quando questo viene messo in
1800 esecuzione.
1801
1802 Nel caso più comune il passaggio di argomenti ed opzioni viene effettuato
1803 dalla shell, che si incarica di leggere la linea di comando con cui si lancia
1804 il programma e di effettuarne la scansione (il cosiddetto \textit{parsing})
1805 per individuare le parole che la compongono, ciascuna delle quali potrà essere
1806 considerata un argomento o un'opzione. 
1807
1808 Di norma per individuare le parole che andranno a costituire la lista degli
1809 argomenti viene usato come carattere di separazione lo spazio o il tabulatore,
1810 ma la cosa dipende ovviamente dalle modalità con cui si effettua la scansione
1811 e dalle convenzioni adottate dal programma che la esegue: ad esempio la shell
1812 consente di proteggere con opportuni caratteri di controllo argomenti che
1813 contengono degli spazi evitando di spezzarli in parole diverse.
1814
1815 \begin{figure}[htb]
1816   \centering
1817   \includegraphics[width=13cm]{img/argv_argc}
1818   % \begin{tikzpicture}[>=stealth]
1819   % \draw (0.5,2.5) rectangle (3.5,3);
1820   % \draw (2,2.75) node {\texttt{argc = 5}};
1821   % \draw (5,2.5) rectangle (8,3);
1822   % \draw (6.5,2.75) node {\texttt{argv[0]}};
1823   % \draw [->] (8,2.75) -- (9,2.75);
1824   % \draw (9,2.75) node [anchor=west] {\texttt{"touch"}};
1825   % \draw (5,2) rectangle (8,2.5);
1826   % \draw (6.5,2.25) node {\texttt{argv[1]}};
1827   % \draw [->] (8,2.25) -- (9,2.25);
1828   % \draw (9,2.25) node [anchor=west] {\texttt{"-r"}};
1829   % \draw (5,1.5) rectangle (8,2);
1830   % \draw (6.5,1.75) node {\texttt{argv[2]}};
1831   % \draw [->] (8,1.75) -- (9,1.75);
1832   % \draw (9,1.75) node [anchor=west] {\texttt{"riferimento.txt"}};
1833   % \draw (5,1.0) rectangle (8,1.5);
1834   % \draw (6.5,1.25) node {\texttt{argv[3]}};
1835   % \draw [->] (8,1.25) -- (9,1.25);
1836   % \draw (9,1.25) node [anchor=west] {\texttt{"-m"}};
1837   % \draw (5,0.5) rectangle (8,1.0);
1838   % \draw (6.5,0.75) node {\texttt{argv[4]}};
1839   % \draw [->] (8,0.75) -- (9,0.75);
1840   % \draw (9,0.75) node [anchor=west] {\texttt{"questofile.txt"}};
1841   % \draw (4.25,3.5) node{\texttt{"touch -r riferimento.txt -m questofile.txt"}};
1842   % \end{tikzpicture}
1843   \caption{Esempio dei valori di \param{argv} e \param{argc} generati nella 
1844     scansione di una riga di comando.}
1845   \label{fig:proc_argv_argc}
1846 \end{figure}
1847
1848 Indipendentemente da come viene eseguita, il risultato finale della scansione
1849 dovrà comunque essere la costruzione del vettore di puntatori \param{argv} in
1850 cui si devono inserire in successione i puntatori alle stringhe costituenti i
1851 vari argomenti ed opzioni da passare al programma, e della
1852 variabile \param{argc} che deve essere inizializzata al numero di stringhe
1853 contenute in \param{argv}. Nel caso della shell questo comporta ad esempio che
1854 il primo argomento sia sempre il nome del programma. Un esempio di questo
1855 meccanismo è mostrato in fig.~\ref{fig:proc_argv_argc}, che illustra il
1856 risultato della scansione di una riga di comando.
1857
1858
1859 \subsection{La gestione delle opzioni}
1860 \label{sec:proc_opt_handling}
1861
1862 In generale un programma Unix riceve da linea di comando sia gli argomenti che
1863 le opzioni, queste ultime sono standardizzate per essere riconosciute come
1864 tali: un elemento di \param{argv} successivo al primo che inizia con il
1865 carattere ``\texttt{-}'' e che non sia un singolo ``\texttt{-}'' o un
1866 ``\texttt{-{}-}'' viene considerato un'opzione.  In genere le opzioni sono
1867 costituite da una lettera singola (preceduta dal carattere ``\texttt{-}'') e
1868 possono avere o no un parametro associato.
1869
1870 Un esempio tipico può essere quello mostrato in
1871 fig.~\ref{fig:proc_argv_argc}. In quel caso le opzioni sono \cmd{-r} e
1872 \cmd{-m} e la prima vuole un parametro mentre la seconda no
1873 (\cmd{questofile.txt} è un argomento del programma, non un parametro di
1874 \cmd{-m}).
1875
1876 Per gestire le opzioni all'interno degli argomenti a linea di comando passati
1877 in \param{argv} la libreria standard del C fornisce la funzione
1878 \funcd{getopt}, che ha il seguente prototipo:
1879
1880 \begin{funcproto}{ 
1881 \fhead{unistd.h} 
1882 \fdecl{int getopt(int argc, char * const argv[], const char *optstring)}
1883 \fdesc{Esegue la scansione delle opzioni negli argomenti della funzione
1884   \code{main}.} 
1885 }
1886 {Ritorna il carattere che segue l'opzione, ``\texttt{:}'' se manca un
1887   parametro all'opzione, ``\texttt{?}'' se l'opzione è sconosciuta, e $-1$ se
1888   non esistono altre opzioni.} 
1889 \end{funcproto}
1890
1891 Questa funzione prende come argomenti le due variabili \param{argc} e
1892 \param{argv} che devono essere quelle passate come argomenti di \code{main}
1893 all'esecuzione del programma, ed una stringa \param{optstring} che indica
1894 quali sono le opzioni valide. La funzione effettua la scansione della lista
1895 degli argomenti ricercando ogni stringa che comincia con il carattere
1896 ``\texttt{-}'' e ritorna ogni volta che trova un'opzione valida.
1897
1898 La stringa \param{optstring} indica quali sono le opzioni riconosciute ed è
1899 costituita da tutti i caratteri usati per identificare le singole opzioni, se
1900 l'opzione ha un parametro al carattere deve essere fatto seguire il carattere
1901 di due punti (``\texttt{:}''); nel caso di fig.~\ref{fig:proc_argv_argc} ad
1902 esempio la stringa di opzioni avrebbe dovuto contenere \texttt{"r:m"}.
1903
1904 La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
1905 funzione all'interno di un ciclo, fintanto che essa non ritorna il valore $-1$
1906 che indica che non ci sono più opzioni. Nel caso si incontri un'opzione non
1907 dichiarata in \param{optstring} viene ritornato il carattere ``\texttt{?}''
1908 mentre se un'opzione che lo richiede non è seguita da un parametro viene
1909 ritornato il carattere ``\texttt{:}'', infine se viene incontrato il valore
1910 ``\texttt{-{}-}'' la scansione viene considerata conclusa, anche se vi sono
1911 altri elementi di \param{argv} che cominciano con il carattere ``\texttt{-}''.
1912
1913 Quando \func{getopt} trova un'opzione fra quelle indicate in \param{optstring}
1914 essa ritorna il valore numerico del carattere, in questo modo si possono
1915 eseguire azioni specifiche usando uno \instruction{switch}; la funzione
1916 inoltre inizializza alcune variabili globali:
1917 \begin{itemize*}
1918 \item \var{char *optarg} contiene il puntatore alla stringa parametro
1919   dell'opzione.
1920 \item \var{int optind} alla fine della scansione restituisce l'indice del
1921   primo elemento di \param{argv} che non è un'opzione.
1922 \item \var{int opterr} previene, se posto a zero, la stampa di un messaggio
1923   di errore in caso di riconoscimento di opzioni non definite.
1924 \item \var{int optopt} contiene il carattere dell'opzione non riconosciuta.
1925 \end{itemize*}
1926
1927 \begin{figure}[!htb]
1928   \footnotesize \centering
1929   \begin{minipage}[c]{\codesamplewidth}
1930   \includecodesample{listati/option_code.c}
1931   \end{minipage}
1932   \normalsize
1933   \caption{Esempio di codice per la gestione delle opzioni.}
1934   \label{fig:proc_options_code}
1935 \end{figure}
1936
1937 In fig.~\ref{fig:proc_options_code} si è mostrata la sezione del programma
1938 \file{fork\_test.c}, che useremo nel prossimo capitolo per effettuare dei test
1939 sulla creazione dei processi, deputata alla decodifica delle opzioni a riga di
1940 comando da esso supportate.
1941
1942 Si può notare che si è anzitutto (\texttt{\small 1}) disabilitata la stampa di
1943 messaggi di errore per opzioni non riconosciute, per poi passare al ciclo per
1944 la verifica delle opzioni (\texttt{\small 2-27}); per ciascuna delle opzioni
1945 possibili si è poi provveduto ad un'azione opportuna, ad esempio per le tre
1946 opzioni che prevedono un parametro si è effettuata la decodifica del medesimo,
1947 il cui indirizzo è contenuto nella variabile \var{optarg}), avvalorando la
1948 relativa variabile (\texttt{\small 12-14}, \texttt{\small 15-17} e
1949 \texttt{\small 18-20}). Completato il ciclo troveremo in \var{optind}
1950 l'indice in \code{argv[]} del primo degli argomenti rimanenti nella linea di
1951 comando.
1952
1953 Normalmente \func{getopt} compie una permutazione degli elementi di
1954 \param{argv} cosicché alla fine della scansione gli elementi che non sono
1955 opzioni sono spostati in coda al vettore. Oltre a questa esistono altre due
1956 modalità di gestire gli elementi di \param{argv}; se \param{optstring} inizia
1957 con il carattere ``\texttt{+}'' (o è impostata la variabile di ambiente
1958 \cmd{POSIXLY\_CORRECT}) la scansione viene fermata non appena si incontra un
1959 elemento che non è un'opzione.
1960
1961 L'ultima modalità, usata quando un programma può gestire la mescolanza fra
1962 opzioni e argomenti, ma se li aspetta in un ordine definito, si attiva
1963 quando \param{optstring} inizia con il carattere ``\texttt{-}''. In questo caso
1964 ogni elemento che non è un'opzione viene considerato comunque un'opzione e
1965 associato ad un valore di ritorno pari ad 1, questo permette di identificare
1966 gli elementi che non sono opzioni, ma non effettua il riordinamento del
1967 vettore \param{argv}.
1968
1969
1970 \subsection{Le variabili di ambiente}
1971 \label{sec:proc_environ}
1972
1973 \index{variabili!di~ambiente|(}
1974 Oltre agli argomenti passati a linea di comando esiste un'altra modalità che
1975 permette di trasferire ad un processo delle informazioni in modo da
1976 modificarne il comportamento.  Ogni processo infatti riceve dal sistema, oltre
1977 alle variabili \param{argv} e \param{argc} anche un \textsl{ambiente} (in
1978 inglese \textit{environment}); questo viene espresso nella forma di una lista
1979 (chiamata \textit{environment list}) delle cosiddette \textsl{variabili di
1980   ambiente}, i valori di queste variabili possono essere poi usati dal
1981 programma.
1982
1983 Anche in questo caso la lista delle \textsl{variabili di ambiente} deve essere
1984 costruita ed utilizzata nella chiamata alla funzione \func{exec} (torneremo su
1985 questo in sez.~\ref{sec:proc_exec}) quando questo viene lanciato. Come per la
1986 lista degli argomenti anche questa lista è un vettore di puntatori a
1987 caratteri, ciascuno dei quali punta ad una stringa, terminata da un
1988 \val{NULL}. A differenza di \code{argv[]} in questo caso non si ha una
1989 lunghezza del vettore data da un equivalente di \param{argc}, ma la lista è
1990 terminata da un puntatore nullo.
1991
1992 L'indirizzo della lista delle variabili di ambiente è passato attraverso la
1993 variabile globale \var{environ}, che viene definita automaticamente per
1994 ciascun processo, e a cui si può accedere attraverso una semplice
1995 dichiarazione del tipo:
1996 \includecodesnip{listati/env_ptr.c}
1997 un esempio della struttura di questa lista, contenente alcune delle variabili
1998 più comuni che normalmente sono definite dal sistema, è riportato in
1999 fig.~\ref{fig:proc_envirno_list}.
2000 \begin{figure}[htb]
2001   \centering
2002   \includegraphics[width=13cm]{img/environ_var}
2003   % \begin{tikzpicture}[>=stealth]
2004   % \draw (2,3.5) node {\textsf{Environment pointer}};
2005   % \draw (6,3.5) node {\textsf{Environment list}};
2006   % \draw (10.5,3.5) node {\textsf{Environment string}};
2007   % \draw (0.5,2.5) rectangle (3.5,3);
2008   % \draw (2,2.75) node {\texttt{environ}};
2009   % \draw [->] (3.5,2.75) -- (4.5,2.75);
2010   % \draw (4.5,2.5) rectangle (7.5,3);
2011   % \draw (6,2.75) node {\texttt{environ[0]}};
2012   % \draw (4.5,2) rectangle (7.5,2.5);
2013   % \draw (6,2.25) node {\texttt{environ[1]}};
2014   % \draw (4.5,1.5) rectangle (7.5,2);
2015   % \draw (4.5,1) rectangle (7.5,1.5);
2016   % \draw (4.5,0.5) rectangle (7.5,1);
2017   % \draw (4.5,0) rectangle (7.5,0.5);
2018   % \draw (6,0.25) node {\texttt{NULL}};
2019   % \draw [->] (7.5,2.75) -- (8.5,2.75);
2020   % \draw (8.5,2.75) node[right] {\texttt{HOME=/home/piccardi}};
2021   % \draw [->] (7.5,2.25) -- (8.5,2.25);
2022   % \draw (8.5,2.25) node[right] {\texttt{PATH=:/bin:/usr/bin}};
2023   % \draw [->] (7.5,1.75) -- (8.5,1.75);
2024   % \draw (8.5,1.75) node[right] {\texttt{SHELL=/bin/bash}};
2025   % \draw [->] (7.5,1.25) -- (8.5,1.25);
2026   % \draw (8.5,1.25) node[right] {\texttt{EDITOR=emacs}};
2027   % \draw [->] (7.5,0.75) -- (8.5,0.75);
2028   % \draw (8.5,0.75) node[right] {\texttt{OSTYPE=linux-gnu}};
2029   % \end{tikzpicture}
2030   \caption{Esempio di lista delle variabili di ambiente.}
2031   \label{fig:proc_envirno_list}
2032 \end{figure}
2033
2034 Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
2035 \textsl{\texttt{NOME=valore}} ed in questa forma che le funzioni di gestione
2036 che vedremo a breve se le aspettano, se pertanto si dovesse costruire
2037 manualmente un ambiente si abbia cura di rispettare questa convenzione.
2038 Inoltre alcune variabili, come quelle elencate in
2039 fig.~\ref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
2040 da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
2041 usare nomi espressi in caratteri maiuscoli.\footnote{ma si tratta solo di una
2042   convenzione, niente vieta di usare caratteri minuscoli, come avviene in vari
2043   casi.}
2044
2045 Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
2046 riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
2047 costituiscono un modo comodo per definire un comportamento specifico senza
2048 dover ricorrere all'uso di opzioni a linea di comando o di file di
2049 configurazione. É di norma cura della shell, quando esegue un comando, passare
2050 queste variabili al programma messo in esecuzione attraverso un uso opportuno
2051 delle relative chiamate (si veda sez.~\ref{sec:proc_exec}).
2052
2053 La shell ad esempio ne usa molte per il suo funzionamento, come \envvar{PATH}
2054 per indicare la lista delle directory in cui effettuare la ricerca dei comandi
2055 o \envvar{PS1} per impostare il proprio \textit{prompt}. Alcune di esse, come
2056 \envvar{HOME}, \envvar{USER}, ecc. sono invece definite al login (per i
2057 dettagli si veda sez.~\ref{sec:sess_login}), ed in genere è cura della propria
2058 distribuzione definire le opportune variabili di ambiente in uno script di
2059 avvio. Alcune servono poi come riferimento generico per molti programmi, come
2060 \envvar{EDITOR} che indica l'editor preferito da invocare in caso di
2061 necessità. Una in particolare, \envvar{LANG}, serve a controllare la
2062 localizzazione del programma 
2063 %(su cui torneremo in sez.~\ref{sec:proc_localization}) 
2064 per adattarlo alla lingua ed alle convezioni
2065 dei vari paesi.
2066
2067 Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
2068 comuni), come riportato in tab.~\ref{tab:proc_env_var}. GNU/Linux le supporta
2069 tutte e ne definisce anche altre, in particolare poi alcune funzioni di
2070 libreria prevedono la presenza di specifiche variabili di ambiente che ne
2071 modificano il comportamento, come quelle usate per indicare una localizzazione
2072 e quelle per indicare un fuso orario; una lista più completa che comprende
2073 queste ed ulteriori variabili si può ottenere con il comando \cmd{man 7
2074   environ}.
2075
2076 \begin{table}[htb]
2077   \centering
2078   \footnotesize
2079   \begin{tabular}[c]{|l|c|c|c|l|}
2080     \hline
2081     \textbf{Variabile} & \textbf{POSIX} & \textbf{XPG3} 
2082     & \textbf{Linux} & \textbf{Descrizione} \\
2083     \hline
2084     \hline
2085     \texttt{USER}   &$\bullet$&$\bullet$&$\bullet$& Nome utente.\\
2086     \texttt{LOGNAME}&$\bullet$&$\bullet$&$\bullet$& Nome di login.\\
2087     \texttt{HOME}   &$\bullet$&$\bullet$&$\bullet$& Directory base
2088                                                     dell'utente.\\
2089     \texttt{LANG}   &$\bullet$&$\bullet$&$\bullet$& Localizzazione.\\
2090     \texttt{PATH}   &$\bullet$&$\bullet$&$\bullet$& Elenco delle directory
2091                                                     dei programmi.\\
2092     \texttt{PWD}    &$\bullet$&$\bullet$&$\bullet$& Directory corrente.\\
2093     \texttt{SHELL}  &$\bullet$&$\bullet$&$\bullet$& Shell in uso.\\
2094     \texttt{TERM}   &$\bullet$&$\bullet$&$\bullet$& Tipo di terminale.\\
2095     \texttt{PAGER}  &$\bullet$&$\bullet$&$\bullet$& Programma per vedere i
2096                                                     testi.\\
2097     \texttt{EDITOR} &$\bullet$&$\bullet$&$\bullet$& Editor preferito.\\
2098     \texttt{BROWSER}&$\bullet$&$\bullet$&$\bullet$& Browser preferito.\\
2099     \texttt{TMPDIR} &$\bullet$&$\bullet$&$\bullet$& Directory dei file
2100                                                     temporanei.\\
2101     \hline
2102   \end{tabular}
2103   \caption{Esempi delle variabili di ambiente più comuni definite da vari
2104     standard.} 
2105   \label{tab:proc_env_var}
2106 \end{table}
2107
2108 Lo standard ANSI C prevede l'esistenza di un ambiente, e pur non entrando
2109 nelle specifiche di come sono strutturati i contenuti, definisce la funzione
2110 \funcd{getenv} che permette di ottenere i valori delle variabili di ambiente;
2111 il suo prototipo è:
2112
2113 \begin{funcproto}{ 
2114 \fhead{stdlib.h}
2115 \fdecl{char *getenv(const char *name)}
2116 \fdesc{Cerca una variabile di ambiente del processo.} 
2117 }
2118 {La funzione ritorna il puntatore alla stringa contenente il valore della
2119   variabile di ambiente in caso di successo e \val{NULL} per un errore.} 
2120 \end{funcproto}
2121
2122 La funzione effettua una ricerca nell'ambiente del processo cercando una
2123 variabile il cui nome corrisponda a quanto indicato con
2124 l'argomento \param{name}, ed in caso di successo ritorna il puntatore alla
2125 stringa che ne contiene il valore, nella forma ``\texttt{NOME=valore}''.
2126
2127 \begin{table}[htb]
2128   \centering
2129   \footnotesize
2130   \begin{tabular}[c]{|l|c|c|c|c|c|c|}
2131     \hline
2132     \textbf{Funzione} & \textbf{ANSI C} & \textbf{POSIX.1} & \textbf{XPG3} & 
2133     \textbf{SVr4} & \textbf{BSD} & \textbf{Linux} \\
2134     \hline
2135     \hline
2136     \func{getenv}  & $\bullet$ & $\bullet$ & $\bullet$ 
2137                    & $\bullet$ & $\bullet$ & $\bullet$ \\
2138     \func{setenv}  &    --     &    --     &   --      
2139                    &    --     & $\bullet$ & $\bullet$ \\
2140     \func{unsetenv}&    --     &    --     &   --       
2141                    &    --     & $\bullet$ & $\bullet$ \\
2142     \func{putenv}  &    --     & opz.      & $\bullet$ 
2143                    &    --     & $\bullet$ & $\bullet$ \\
2144     \func{clearenv}&    --     & opz.      &   --
2145                    &    --     &    --     & $\bullet$ \\
2146     \hline
2147   \end{tabular}
2148   \caption{Funzioni per la gestione delle variabili di ambiente.}
2149   \label{tab:proc_env_func}
2150 \end{table}
2151
2152 Oltre a questa funzione di lettura, che è l'unica definita dallo standard ANSI
2153 C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
2154 utilizzare per impostare, modificare e cancellare le variabili di
2155 ambiente. Uno schema delle funzioni previste nei vari standard e disponibili
2156 in Linux è riportato in tab.~\ref{tab:proc_env_func}. Tutte le funzioni sono
2157 state comunque inserite nello standard POSIX.1-2001, ad eccetto di
2158 \func{clearenv} che è stata rigettata.
2159
2160 In Linux sono definite tutte le funzioni elencate in
2161 tab.~\ref{tab:proc_env_func},\footnote{in realtà nelle libc4 e libc5 sono
2162   definite solo le prime quattro, \func{clearenv} è stata introdotta con la
2163   \acr{glibc} 2.0.} anche se parte delle funzionalità sono ridondanti. La
2164 prima funzione di manipolazione che prenderemo in considerazione è
2165 \funcd{putenv}, che consente di aggiungere, modificare e cancellare una
2166 variabile di ambiente; il suo prototipo è:
2167
2168 \begin{funcproto}{ 
2169 \fdecl{int putenv(char *string)}
2170 \fdesc{Inserisce, modifica o rimuove una variabile d'ambiente.} 
2171 }
2172 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, che può
2173   essere solo \errval{ENOMEM}.}
2174 \end{funcproto}
2175
2176 La funzione prende come argomento una stringa analoga a quella restituita da
2177 \func{getenv} e sempre nella forma ``\texttt{NOME=valore}''. Se la variabile
2178 specificata (nel caso \texttt{NOME}) non esiste la stringa sarà aggiunta
2179 all'ambiente, se invece esiste il suo valore sarà impostato a quello
2180 specificato dal contenuto di \param{string} (nel caso \texttt{valore}).  Se
2181 invece si passa come argomento solo il nome di una variabile di ambiente
2182 (cioè \param{string} è nella forma ``\texttt{NOME}'' e non contiene il
2183 carattere ``\texttt{=}'') allora questa, se presente nell'ambiente, verrà
2184 cancellata.
2185
2186 Si tenga presente che, seguendo lo standard SUSv2, le \acr{glibc} successive
2187 alla versione 2.1.2 aggiungono direttamente \param{string} nella lista delle
2188 variabili di ambiente illustrata in fig.~\ref{fig:proc_envirno_list}
2189 sostituendo il relativo puntatore;\footnote{il comportamento è lo stesso delle
2190   vecchie \acr{libc4} e \acr{libc5}; nella \acr{glibc}, dalla versione 2.0
2191   alla 2.1.1, veniva invece fatta una copia, seguendo il comportamento di
2192   BSD4.4; dato che questo può dar luogo a perdite di memoria e non rispetta lo
2193   standard il comportamento è stato modificato a partire dalla 2.1.2,
2194   eliminando anche, sempre in conformità a SUSv2, l'attributo \direct{const}
2195   dal prototipo.}  pertanto ogni cambiamento alla stringa in questione si
2196 riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
2197 questa funzione una variabile automatica (per evitare i problemi esposti in
2198 sez.~\ref{sec:proc_var_passing}). Benché non sia richiesto dallo standard,
2199 nelle versioni della \acr{glibc} a partire dalla 2.1 la funzione è rientrante
2200 (vedi sez.~\ref{sec:proc_reentrant}).
2201
2202 Infine quando una chiamata a \func{putenv} comporta la necessità di creare una
2203 nuova versione del vettore \var{environ} questo sarà allocato automaticamente,
2204 ma la versione corrente sarà deallocata solo se anch'essa è risultante da
2205 un'allocazione fatta in precedenza da un'altra \func{putenv}. Questo avviene
2206 perché il vettore delle variabili di ambiente iniziale, creato dalla chiamata
2207 ad \func{exec} (vedi sez.~\ref{sec:proc_exec}) è piazzato nella memoria al di
2208 sopra dello \textit{stack}, (vedi fig.~\ref{fig:proc_mem_layout}) e non nello
2209 \textit{heap} e quindi non può essere deallocato.  Inoltre la memoria
2210 associata alle variabili di ambiente eliminate non viene liberata.
2211
2212 Come alternativa a \func{putenv} si può usare la funzione \funcd{setenv} che
2213 però consente solo di aggiungere o modificare una variabile di ambiente; il
2214 suo prototipo è:
2215
2216 \begin{funcproto}{ 
2217 \fhead{stdlib.h}
2218 \fdecl{int setenv(const char *name, const char *value, int overwrite)}
2219 \fdesc{Inserisce o modifica una variabile di ambiente.} 
2220 }
2221 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
2222   nel qual caso \var{errno} assumerà uno dei valori:
2223   \begin{errlist}
2224   \item[\errcode{EINVAL}] \param{name} è \val{NULL} o una stringa di lunghezza
2225   nulla o che contiene il carattere ``\texttt{=}''.
2226   \item[\errcode{ENOMEM}] non c'è memoria sufficiente per aggiungere una nuova
2227     variabile all'ambiente.
2228 \end{errlist}}
2229 \end{funcproto}
2230
2231 La funzione consente di specificare separatamente nome e valore della
2232 variabile di ambiente da aggiungere negli argomenti \param{name}
2233 e \param{value}. Se la variabile è già presente nell'ambiente
2234 l'argomento \param{overwrite} specifica il comportamento della funzione, se
2235 diverso da zero sarà sovrascritta, se uguale a zero sarà lasciata immutata.  A
2236 differenza di \func{putenv} la funzione esegue delle copie del contenuto degli
2237 argomenti \param{name} e \param{value} e non è necessario preoccuparsi di
2238 allocarli in maniera permanente.
2239
2240 La cancellazione di una variabile di ambiente viene invece gestita
2241 esplicitamente con \funcd{unsetenv}, il cui prototipo è:
2242
2243 \begin{funcproto}{ 
2244 \fhead{stdlib.h}
2245 \fdecl{int unsetenv(const char *name)}
2246 \fdesc{Rimuove una variabile di ambiente.} 
2247 }
2248 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
2249   nel qual caso \var{errno} assumerà uno dei valori:
2250   \begin{errlist}
2251   \item[\errcode{EINVAL}] \param{name} è \val{NULL} o una stringa di lunghezza
2252   nulla o che contiene il carattere ``\texttt{=}''.
2253 \end{errlist}}
2254 \end{funcproto}
2255
2256 La funzione richiede soltanto il nome della variabile di ambiente
2257 nell'argomento \param{name}, se la variabile non esiste la funzione ritorna
2258 comunque con un valore di successo.\footnote{questo con le versioni della
2259   \acr{glibc} successive la 2.2.2, per le precedenti \func{unsetenv} era
2260   definita come \texttt{void} e non restituiva nessuna informazione.}
2261
2262 L'ultima funzione per la gestione dell'ambiente è
2263 \funcd{clearenv},\footnote{che come accennato è l'unica non presente nello
2264   standard POSIX.1-2000, ed è disponibili solo per versioni della \acr{glibc}
2265   a partire dalla 2.0; per poterla utilizzare occorre aver definito le macro
2266   \macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE}.} che viene usata per
2267 cancellare completamente tutto l'ambiente; il suo prototipo è:
2268
2269 \begin{funcproto}{ 
2270 \fhead{stdlib.h}
2271 \fdecl{int clearenv(void)}
2272 \fdesc{Cancella tutto l'ambiente.} 
2273 }
2274 {La funzione ritorna $0$ in caso di successo e un valore diverso da zero per
2275   un errore.}
2276 \end{funcproto}
2277
2278 In genere si usa questa funzione in maniera precauzionale per evitare i
2279 problemi di sicurezza connessi nel trasmettere ai programmi che si invocano un
2280 ambiente che può contenere dei dati non controllati, le cui variabili possono
2281 causare effetti indesiderati. Con l'uso della funzione si provvede alla
2282 cancellazione di tutto l'ambiente originale in modo da poterne costruirne una
2283 versione ``\textsl{sicura}'' da zero.
2284
2285 \index{variabili!di~ambiente|)}
2286
2287
2288 % \subsection{La localizzazione}
2289 % \label{sec:proc_localization}
2290
2291 % Abbiamo accennato in sez.~\ref{sec:proc_environ} come la variabile di ambiente
2292 % \envvar{LANG} sia usata per indicare ai processi il valore della cosiddetta
2293 % \textsl{localizzazione}. Si tratta di una funzionalità fornita dalle librerie
2294 % di sistema\footnote{prenderemo in esame soltanto il caso della \acr{glibc}.}
2295 % che consente di gestire in maniera automatica sia la lingua in cui vengono
2296 % stampati i vari messaggi (come i messaggi associati agli errori che vedremo in
2297 % sez.~\ref{sec:sys_strerror}) che le convenzioni usate nei vari paesi per una
2298 % serie di aspetti come il formato dell'ora, quello delle date, gli ordinamenti
2299 % alfabetici, le espressioni della valute, ecc.
2300
2301 % Da finire.
2302
2303 % La localizzazione di un programma si può selezionare con la 
2304
2305 % In realtà perché un programma sia effettivamente localizzato non è sufficiente 
2306
2307 % TODO trattare, quando ci sarà tempo, setlocale ed il resto
2308
2309
2310 %\subsection{Opzioni in formato esteso}
2311 %\label{sec:proc_opt_extended}
2312
2313 %Oltre alla modalità ordinaria di gestione delle opzioni trattata in
2314 %sez.~\ref{sec:proc_opt_handling} la \acr{glibc} fornisce una modalità
2315 %alternativa costituita dalle cosiddette \textit{long-options}, che consente di
2316 %esprimere le opzioni in una forma più descrittiva che nel caso più generale è
2317 %qualcosa del tipo di ``\texttt{-{}-option-name=parameter}''.
2318
2319 %(NdA: questa parte verrà inserita in seguito).
2320
2321 % TODO opzioni in formato esteso
2322
2323 % TODO trattare il vettore ausiliario e getauxval (vedi
2324 % http://lwn.net/Articles/519085/)
2325
2326
2327 \section{Problematiche di programmazione generica}
2328 \label{sec:proc_gen_prog}
2329
2330 Benché questo non sia un libro sul linguaggio C, è opportuno affrontare alcune
2331 delle problematiche generali che possono emergere nella programmazione con
2332 questo linguaggio e di quali precauzioni o accorgimenti occorre prendere per
2333 risolverle. Queste problematiche non sono specifiche di sistemi unix-like o
2334 \textit{multitasking}, ma avendo trattato in questo capitolo il comportamento
2335 dei processi visti come entità a sé stanti, le riportiamo qui.
2336
2337
2338 \subsection{Il passaggio di variabili e valori di ritorno nelle funzioni}
2339 \label{sec:proc_var_passing}
2340
2341 Una delle caratteristiche standard del C è che le variabili vengono passate
2342 alle funzioni che si invocano in un programma attraverso un meccanismo che
2343 viene chiamato \textit{by value}, diverso ad esempio da quanto avviene con il
2344 Fortran, dove le variabili sono passate, come suol dirsi, \textit{by
2345   reference}, o dal C++ dove la modalità del passaggio può essere controllata
2346 con l'operatore \cmd{\&}.
2347
2348 Il passaggio di una variabile \textit{by value} significa che in realtà quello
2349 che viene passato alla funzione è una copia del valore attuale di quella
2350 variabile, copia che la funzione potrà modificare a piacere, senza che il
2351 valore originale nella funzione chiamante venga toccato. In questo modo non
2352 occorre preoccuparsi di eventuali effetti delle operazioni svolte nella
2353 funzione stessa sulla variabile passata come argomento.
2354
2355 Questo però va inteso nella maniera corretta. Il passaggio \textit{by value}
2356 vale per qualunque variabile, puntatori compresi; quando però in una funzione
2357 si usano dei puntatori (ad esempio per scrivere in un buffer) in realtà si va
2358 a modificare la zona di memoria a cui essi puntano, per cui anche se i
2359 puntatori sono copie, i dati a cui essi puntano saranno sempre gli stessi, e
2360 le eventuali modifiche avranno effetto e saranno visibili anche nella funzione
2361 chiamante.
2362
2363 Nella maggior parte delle funzioni di libreria e delle \textit{system call} i
2364 puntatori vengono usati per scambiare dati (attraverso i buffer o le strutture
2365 a cui fanno riferimento) e le variabili normali vengono usate per specificare
2366 argomenti; in genere le informazioni a riguardo dei risultati vengono passate
2367 alla funzione chiamante attraverso il valore di ritorno.  È buona norma
2368 seguire questa pratica anche nella programmazione normale.
2369
2370 \itindbeg{value~result~argument}
2371
2372 Talvolta però è necessario che la funzione possa restituire indietro alla
2373 funzione chiamante un valore relativo ad uno dei suoi argomenti usato anche in
2374 ingresso.  Per far questo si usa il cosiddetto \textit{value result argument},
2375 si passa cioè, invece di una normale variabile, un puntatore alla stessa. Gli
2376 esempi di questa modalità di passaggio sono moltissimi, ad esempio essa viene
2377 usata nelle funzioni che gestiscono i socket (in
2378 sez.~\ref{sec:TCP_functions}), in cui, per permettere al kernel di restituire
2379 informazioni sulle dimensioni delle strutture degli indirizzi utilizzate,
2380 viene usato proprio questo meccanismo.
2381
2382 Occorre tenere ben presente questa differenza, perché le variabili passate in
2383 maniera ordinaria, che vengono inserite nello \textit{stack}, cessano di
2384 esistere al ritorno di una funzione, ed ogni loro eventuale modifica
2385 all'interno della stessa sparisce con la conclusione della stessa, per poter
2386 passare delle informazioni occorre quindi usare un puntatore che faccia
2387 riferimento ad un indirizzo accessibile alla funzione chiamante.
2388
2389 \itindend{value~result~argument}
2390
2391 Questo requisito di accessibilità è fondamentale, infatti dei possibili
2392 problemi che si possono avere con il passaggio dei dati è quello di restituire
2393 alla funzione chiamante dei dati che sono contenuti in una variabile
2394 automatica.  Ovviamente quando la funzione ritorna la sezione dello
2395 \textit{stack} che conteneva la variabile automatica (si ricordi quanto detto
2396 in sez.~\ref{sec:proc_mem_alloc}) verrà liberata automaticamente e potrà
2397 essere riutilizzata all'invocazione di un'altra funzione, con le immaginabili
2398 conseguenze, quasi invariabilmente catastrofiche, di sovrapposizione e
2399 sovrascrittura dei dati.
2400
2401 Per questo una delle regole fondamentali della programmazione in C è che
2402 all'uscita di una funzione non deve restare nessun riferimento alle sue
2403 variabili locali. Qualora sia necessario utilizzare delle variabili che devono
2404 essere viste anche dalla funzione chiamante queste devono essere allocate
2405 esplicitamente, o in maniera statica usando variabili globali o dichiarate
2406 come \direct{extern},\footnote{la direttiva \direct{extern} informa il
2407   compilatore che la variabile che si è dichiarata in una funzione non è da
2408   considerarsi locale, ma globale, e per questo allocata staticamente e
2409   visibile da tutte le funzioni dello stesso programma.} o dinamicamente con
2410 una delle funzioni della famiglia \func{malloc}, passando opportunamente il
2411 relativo puntatore fra le funzioni.
2412
2413
2414 \subsection{Il passaggio di un numero variabile di argomenti}
2415 \label{sec:proc_variadic}
2416
2417 \index{funzioni!\textit{variadic}|(}
2418
2419 Come vedremo nei capitoli successivi, non sempre è possibile specificare un
2420 numero fisso di argomenti per una funzione.  Lo standard ISO C prevede nella
2421 sua sintassi la possibilità di definire delle \textit{variadic function} che
2422 abbiano un numero variabile di argomenti, attraverso l'uso nella dichiarazione
2423 della funzione dello speciale costrutto ``\texttt{...}'', che viene chiamato
2424 \textit{ellipsis}.
2425
2426 Lo standard però non provvede a livello di linguaggio alcun meccanismo con cui
2427 dette funzioni possono accedere ai loro argomenti.  L'accesso viene pertanto
2428 realizzato a livello della libreria standard del C che fornisce gli strumenti
2429 adeguati.  L'uso di una \textit{variadic function} prevede quindi tre punti:
2430 \begin{itemize*}
2431 \item \textsl{dichiarare} la funzione come \textit{variadic} usando un
2432   prototipo che contenga una \textit{ellipsis};
2433 \item \textsl{definire} la funzione come \textit{variadic} usando la stessa
2434   \textit{ellipsis}, ed utilizzare le apposite macro che consentono la
2435   gestione di un numero variabile di argomenti;
2436 \item \textsl{invocare} la funzione specificando prima gli argomenti fissi, ed
2437   a seguire quelli addizionali.
2438 \end{itemize*}
2439
2440 Lo standard ISO C prevede che una \textit{variadic function} abbia sempre
2441 almeno un argomento fisso. Prima di effettuare la dichiarazione deve essere
2442 incluso l'apposito \textit{header file} \headfile{stdarg.h}; un esempio di
2443 dichiarazione è il prototipo della funzione \func{execl} che vedremo in
2444 sez.~\ref{sec:proc_exec}:
2445 \includecodesnip{listati/exec_sample.c}
2446 in questo caso la funzione prende due argomenti fissi ed un numero variabile
2447 di altri argomenti, che andranno a costituire gli elementi successivi al primo
2448 del vettore \param{argv} passato al nuovo processo. Lo standard ISO C richiede
2449 inoltre che l'ultimo degli argomenti fissi sia di tipo
2450 \textit{self-promoting}\footnote{il linguaggio C prevede che quando si
2451   mescolano vari tipi di dati, alcuni di essi possano essere \textsl{promossi}
2452   per compatibilità; ad esempio i tipi \ctyp{float} vengono convertiti
2453   automaticamente a \ctyp{double} ed i \ctyp{char} e gli \ctyp{short} ad
2454   \ctyp{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
2455   a sé stesso.} il che esclude vettori, puntatori a funzioni e interi di tipo
2456 \ctyp{char} o \ctyp{short} (con segno o meno). Una restrizione ulteriore di
2457 alcuni compilatori è di non dichiarare l'ultimo argomento fisso come variabile
2458 di tipo \direct{register}.\footnote{la direttiva \direct{register} del
2459   compilatore chiede che la variabile dichiarata tale sia mantenuta, nei
2460   limiti del possibile, all'interno di un registro del processore; questa
2461   direttiva è originaria dell'epoca dai primi compilatori, quando stava al
2462   programmatore scrivere codice ottimizzato, riservando esplicitamente alle
2463   variabili più usate l'uso dei registri del processore, oggi questa direttiva
2464   è in disuso pressoché completo dato che tutti i compilatori sono normalmente
2465   in grado di valutare con maggior efficacia degli stessi programmatori quando
2466   sia il caso di eseguire questa ottimizzazione.}
2467
2468 Una volta dichiarata la funzione il secondo passo è accedere ai vari argomenti
2469 quando la si va a definire. Gli argomenti fissi infatti hanno un loro nome, ma
2470 quelli variabili vengono indicati in maniera generica dalla
2471 \textit{ellipsis}. L'unica modalità in cui essi possono essere recuperati è
2472 pertanto quella sequenziale, in cui vengono estratti dallo \textit{stack}
2473 secondo l'ordine in cui sono stati scritti nel prototipo della funzione.
2474
2475 \macrobeg{va\_start}
2476
2477 Per fare questo in \headfile{stdarg.h} sono definite delle macro specifiche,
2478 previste dallo standard ISO C89, che consentono di eseguire questa operazione.
2479 La prima di queste macro è \macro{va\_start}, che inizializza opportunamente
2480 una lista degli argomenti, la sua definizione è:
2481
2482 {\centering
2483 \begin{funcbox}{ 
2484 \fhead{stdarg.h}
2485 \fdecl{void va\_start(va\_list ap, last)}
2486 \fdesc{Inizializza una lista degli argomenti di una funzione
2487   \textit{variadic}.} 
2488 }
2489 \end{funcbox}}
2490
2491 La macro inizializza il puntatore alla lista di argomenti \param{ap} che deve
2492 essere una apposita variabile di tipo \type{va\_list}; il
2493 parametro \param{last} deve indicare il nome dell'ultimo degli argomenti fissi
2494 dichiarati nel prototipo della funzione \textit{variadic}.
2495
2496 \macrobeg{va\_arg}
2497
2498 La seconda macro di gestione delle liste di argomenti di una funzione
2499 \textit{variadic} è \macro{va\_arg}, che restituisce in successione un
2500 argomento della lista; la sua definizione è:
2501
2502 {\centering
2503 \begin{funcbox}{ 
2504 \fhead{stdarg.h}
2505 \fdecl{type va\_arg(va\_list ap, type)}
2506 \fdesc{Restituisce il valore del successivo argomento opzionale.} 
2507 }
2508 \end{funcbox}}
2509  
2510 La macro restituisce il valore di un argomento, modificando opportunamente la
2511 lista \param{ap} perché una chiamata successiva restituisca l'argomento
2512 seguente. La macro richiede che si specifichi il tipo dell'argomento che si
2513 andrà ad estrarre attraverso il parametro \param{type} che sarà anche il tipo
2514 del valore da essa restituito. Si ricordi che il tipo deve essere
2515 \textit{self-promoting}.
2516
2517 In generale è perfettamente legittimo richiedere meno argomenti di quelli che
2518 potrebbero essere stati effettivamente forniti, per cui nella esecuzione delle
2519 \macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
2520 saranno ignorati. Se invece si richiedono più argomenti di quelli
2521 effettivamente forniti si otterranno dei valori indefiniti. Si avranno
2522 risultati indefiniti anche quando si chiama \macro{va\_arg} specificando un
2523 tipo che non corrisponde a quello usato per il corrispondente argomento.
2524
2525 \macrobeg{va\_end}
2526
2527 Infine una volta completata l'estrazione occorre indicare che si sono concluse
2528 le operazioni con la macro \macrod{va\_end}, la cui definizione è:
2529
2530 {\centering
2531 \begin{funcbox}{ 
2532 \fhead{stdarg.h}
2533 \fdecl{void va\_end(va\_list ap)}
2534 \fdesc{Conclude l'estrazione degli argomenti di una funzione
2535   \textit{variadic}.} 
2536 }
2537 \end{funcbox}}
2538  
2539 Dopo l'uso di \macro{va\_end} la variabile \param{ap} diventa indefinita e
2540 successive chiamate a \macro{va\_arg} non funzioneranno.  Nel caso del
2541 \cmd{gcc} l'uso di \macro{va\_end} può risultare inutile, ma è comunque
2542 necessario usarla per chiarezza del codice, per compatibilità con diverse
2543 implementazioni e per eventuali modifiche future a questo comportamento.
2544
2545 Riassumendo la procedura da seguire per effettuare l'estrazione degli
2546 argomenti di una funzione \textit{variadic} è la seguente:
2547 \begin{enumerate*}
2548 \item inizializzare una lista degli argomenti attraverso la macro
2549   \macro{va\_start};
2550 \item accedere agli argomenti con chiamate successive alla macro
2551   \macro{va\_arg}: la prima chiamata restituirà il primo argomento, la seconda
2552   il secondo e così via;
2553 \item dichiarare la conclusione dell'estrazione degli argomenti invocando la
2554   macro \macro{va\_end}.
2555 \end{enumerate*}
2556
2557 Si tenga presente che si possono usare anche più liste degli argomenti,
2558 ciascuna di esse andrà inizializzata con \macro{va\_start} e letta con
2559 \macro{va\_arg}, e ciascuna potrà essere usata per scandire la lista degli
2560 argomenti in modo indipendente. Infine ciascuna scansione dovrà essere
2561 terminata con \macro{va\_end}.
2562
2563 Un limite di queste macro è che i passi 1) e 3) devono essere eseguiti nel
2564 corpo principale della funzione, il passo 2) invece può essere eseguito anche
2565 in un'altra funzione, passandole lista degli argomenti \param{ap}. In questo
2566 caso però al ritorno della funzione \macro{va\_arg} non può più essere usata
2567 (anche se non si era completata l'estrazione) dato che il valore di \param{ap}
2568 risulterebbe indefinito.
2569
2570 \macroend{va\_start}
2571 \macroend{va\_arg}
2572 \macroend{va\_end}
2573
2574 Esistono dei casi in cui è necessario eseguire più volte la scansione degli
2575 argomenti e poter memorizzare una posizione durante la stessa. In questo caso
2576 sembrerebbe naturale copiarsi la lista degli argomenti \param{ap} con una
2577 semplice assegnazione ad un'altra variabile dello stesso tipo. Dato che una
2578 delle realizzazioni più comuni di \type{va\_list} è quella di un puntatore
2579 nello \textit{stack} all'indirizzo dove sono stati salvati gli argomenti, è
2580 assolutamente normale pensare di poter effettuare questa operazione.
2581
2582 \index{tipo!opaco|(}
2583
2584 In generale però possono esistere anche realizzazioni diverse, ed è per questo
2585 motivo che invece che un semplice puntatore, \typed{va\_list} è quello che
2586 viene chiamato un \textsl{tipo opaco}. Si chiamano così quei tipi di dati, in
2587 genere usati da una libreria, la cui struttura interna non deve essere vista
2588 dal programma chiamante (da cui deriva il nome opaco) che li devono utilizzare
2589 solo attraverso dalle opportune funzioni di gestione.
2590
2591 \index{tipo!opaco|)}
2592
2593 Per questo motivo una variabile di tipo \typed{va\_list} non può essere
2594 assegnata direttamente ad un'altra variabile dello stesso tipo, ma lo standard
2595 ISO C99\footnote{alcuni sistemi che non hanno questa macro provvedono al suo
2596   posto \macrod{\_\_va\_copy} che era il nome proposto in una bozza dello
2597   standard.}  ha previsto una macro ulteriore che permette di eseguire la
2598 copia di una lista degli argomenti:
2599
2600 {\centering
2601 \begin{funcbox}{ 
2602 \fhead{stdarg.h}
2603 \fdecl{void va\_copy(va\_list dest, va\_list src)}
2604 \fdesc{Copia la lista degli argomenti di una funzione \textit{variadic}.} 
2605 }
2606 \end{funcbox}}
2607
2608 La macro copia l'attuale della lista degli argomenti \param{src} su una nuova
2609 lista \param{dest}. Anche in questo caso è buona norma chiudere ogni
2610 esecuzione di una \macrod{va\_copy} con una corrispondente \macro{va\_end} sul
2611 nuovo puntatore alla lista degli argomenti.
2612
2613 La chiamata di una funzione con un numero variabile di argomenti, posto che la
2614 si sia dichiarata e definita come tale, non prevede nulla di particolare;
2615 l'invocazione è identica alle altre, con gli argomenti, sia quelli fissi che
2616 quelli opzionali, separati da virgole. Quello che però è necessario tenere
2617 presente è come verranno convertiti gli argomenti variabili.
2618
2619 In Linux gli argomenti dello stesso tipo sono passati allo stesso modo, sia
2620 che siano fissi sia che siano opzionali (alcuni sistemi trattano diversamente
2621 gli opzionali), ma dato che il prototipo non può specificare il tipo degli
2622 argomenti opzionali, questi verranno sempre promossi, pertanto nella ricezione
2623 dei medesimi occorrerà tenerne conto (ad esempio un \ctyp{char} verrà visto da
2624 \macro{va\_arg} come \ctyp{int}).
2625
2626 Un altro dei problemi che si devono affrontare con le funzioni con un numero
2627 variabile di argomenti è che non esiste un modo generico che permetta di
2628 stabilire quanti sono gli argomenti effettivamente passati in una chiamata.
2629
2630 Esistono varie modalità per affrontare questo problema; una delle più
2631 immediate è quella di specificare il numero degli argomenti opzionali come uno
2632 degli argomenti fissi. Una variazione di questo metodo è l'uso di un argomento
2633 fisso per specificare anche il tipo degli argomenti variabili, come fa la
2634 stringa di formato per \func{printf} (vedi sez.~\ref{sec:file_formatted_io}).
2635
2636 Infine una ulteriore modalità diversa, che può essere applicata solo quando il
2637 tipo degli argomenti lo rende possibile, è quella che prevede di usare un
2638 valore speciale per l'ultimo argomento, come fa ad esempio \func{execl} che
2639 usa un puntatore \val{NULL} per indicare la fine della lista degli argomenti
2640 (vedi sez.~\ref{sec:proc_exec}).
2641
2642 \index{funzioni!\textit{variadic}|)}
2643
2644 \subsection{Il controllo di flusso non locale}
2645 \label{sec:proc_longjmp}
2646
2647 Il controllo del flusso di un programma in genere viene effettuato con le
2648 varie istruzioni del linguaggio C; fra queste la più bistrattata è il
2649 \instruction{goto}, che viene deprecato in favore dei costrutti della
2650 programmazione strutturata, che rendono il codice più leggibile e
2651 mantenibile. Esiste però un caso in cui l'uso di questa istruzione porta
2652 all'implementazione più efficiente e più chiara anche dal punto di vista della
2653 struttura del programma: quello dell'uscita in caso di errore.
2654
2655 \index{salto~non-locale|(} 
2656
2657 Il C però non consente di effettuare un salto ad una etichetta definita in
2658 un'altra funzione, per cui se l'errore avviene in una funzione, e la sua
2659 gestione ordinaria è in un'altra, occorre usare quello che viene chiamato un
2660 \textsl{salto non-locale}.  Il caso classico in cui si ha questa necessità,
2661 citato sia in \cite{APUE} che in \cite{GlibcMan}, è quello di un programma nel
2662 cui corpo principale vengono letti dei dati in ingresso sui quali viene
2663 eseguita, tramite una serie di funzioni di analisi, una scansione dei
2664 contenuti, da cui si ottengono le indicazioni per l'esecuzione di opportune
2665 operazioni.
2666
2667 Dato che l'analisi può risultare molto complessa, ed opportunamente suddivisa
2668 in fasi diverse, la rilevazione di un errore nei dati in ingresso può accadere
2669 all'interno di funzioni profondamente annidate l'una nell'altra. In questo
2670 caso si dovrebbe gestire, per ciascuna fase, tutta la casistica del passaggio
2671 all'indietro di tutti gli errori rilevabili dalle funzioni usate nelle fasi
2672 successive.  Questo comporterebbe una notevole complessità, mentre sarebbe
2673 molto più comodo poter tornare direttamente al ciclo di lettura principale,
2674 scartando l'input come errato.\footnote{a meno che, come precisa
2675   \cite{GlibcMan}, alla chiusura di ciascuna fase non siano associate
2676   operazioni di pulizia specifiche (come deallocazioni, chiusure di file,
2677   ecc.), che non potrebbero essere eseguite con un salto non-locale.}
2678
2679 Tutto ciò può essere realizzato proprio con un salto non-locale; questo di
2680 norma viene realizzato salvando il contesto dello \textit{stack} nel punto in
2681 cui si vuole tornare in caso di errore, e ripristinandolo, in modo da tornare
2682 quando serve nella funzione da cui si era partiti.  La funzione che permette
2683 di salvare il contesto dello \textit{stack} è \funcd{setjmp}, il cui prototipo
2684 è:
2685
2686 \begin{funcproto}{ 
2687 \fhead{setjmp.h}
2688 \fdecl{int setjmp(jmp\_buf env)}
2689 \fdesc{Salva il contesto dello \textit{stack}.} 
2690 }
2691 {La funzione ritorna $0$ quando è chiamata direttamente ed un valore diverso
2692   da zero quando ritorna da una chiamata di \func{longjmp} che usa il contesto
2693   salvato in precedenza.}
2694 \end{funcproto}
2695   
2696 Quando si esegue la funzione il contesto corrente dello \textit{stack} viene
2697 salvato nell'argomento \param{env}, una variabile di tipo
2698 \typed{jmp\_buf}\footnote{anche questo è un classico esempio di variabile di
2699   \textsl{tipo opaco}.}  che deve essere stata definita in precedenza. In
2700 genere le variabili di tipo \type{jmp\_buf} vengono definite come variabili
2701 globali in modo da poter essere viste in tutte le funzioni del programma.
2702
2703 Quando viene eseguita direttamente la funzione ritorna sempre zero, un valore
2704 diverso da zero viene restituito solo quando il ritorno è dovuto ad una
2705 chiamata di \func{longjmp} in un'altra parte del programma che ripristina lo
2706 \textit{stack} effettuando il salto non-locale. Si tenga conto che il contesto
2707 salvato in \param{env} viene invalidato se la funzione che ha chiamato
2708 \func{setjmp} ritorna, nel qual caso un successivo uso di \func{longjmp} può
2709 comportare conseguenze imprevedibili (e di norma fatali) per il processo.
2710   
2711 Come accennato per effettuare un salto non-locale ad un punto precedentemente
2712 stabilito con \func{setjmp} si usa la funzione \funcd{longjmp}; il suo
2713 prototipo è:
2714
2715 \begin{funcproto}{ 
2716 \fhead{setjmp.h}
2717 \fdecl{void longjmp(jmp\_buf env, int val)}
2718 \fdesc{Ripristina il contesto dello stack.} 
2719 }
2720 {La funzione non ritorna.}   
2721 \end{funcproto}
2722
2723 La funzione ripristina il contesto dello \textit{stack} salvato da una
2724 chiamata a \func{setjmp} nell'argomento \param{env}. Dopo l'esecuzione della
2725 funzione il programma prosegue nel codice successivo alla chiamata della
2726 \func{setjmp} con cui si era salvato \param{env}, che restituirà il valore
2727 dell'argomento \param{val} invece di zero.  Il valore
2728 dell'argomento \param{val} deve essere sempre diverso da zero, se si è
2729 specificato 0 sarà comunque restituito 1 al suo posto.
2730
2731 In sostanza l'esecuzione di \func{longjmp} è analoga a quella di una
2732 istruzione \instr{return}, solo che invece di ritornare alla riga
2733 successiva della funzione chiamante, il programma in questo caso ritorna alla
2734 posizione della relativa \func{setjmp}. L'altra differenza fondamentale con
2735 \instr{return} è che il ritorno può essere effettuato anche attraverso
2736 diversi livelli di funzioni annidate.
2737
2738 L'implementazione di queste funzioni comporta alcune restrizioni dato che esse
2739 interagiscono direttamente con la gestione dello \textit{stack} ed il
2740 funzionamento del compilatore stesso. In particolare \func{setjmp} è
2741 implementata con una macro, pertanto non si può cercare di ottenerne
2742 l'indirizzo, ed inoltre le chiamate a questa funzione sono sicure solo in uno
2743 dei seguenti casi:
2744 \begin{itemize*}
2745 \item come espressione di controllo in un comando condizionale, di selezione o
2746   di iterazione (come \instruction{if}, \instruction{switch} o
2747   \instruction{while});
2748 \item come operando per un operatore di uguaglianza o confronto in una
2749   espressione di controllo di un comando condizionale, di selezione o di
2750   iterazione;
2751 \item come operando per l'operatore di negazione (\code{!}) in una espressione
2752   di controllo di un comando condizionale, di selezione o di iterazione;
2753 \item come espressione a sé stante.
2754 \end{itemize*}
2755
2756 In generale, dato che l'unica differenza fra il risultato di una chiamata
2757 diretta di \func{setjmp} e quello ottenuto nell'uscita con un \func{longjmp} è
2758 costituita dal valore di ritorno della funzione, quest'ultima viene usualmente
2759 chiamata all'interno di un una istruzione \instr{if} che permetta di
2760 distinguere i due casi.
2761
2762 Uno dei punti critici dei salti non-locali è quello del valore delle
2763 variabili, ed in particolare quello delle variabili automatiche della funzione
2764 a cui si ritorna. In generale le variabili globali e statiche mantengono i
2765 valori che avevano al momento della chiamata di \func{longjmp}, ma quelli
2766 delle variabili automatiche (o di quelle dichiarate \dirct{register}) sono in
2767 genere indeterminati.
2768
2769 Quello che succede infatti è che i valori delle variabili che sono tenute in
2770 memoria manterranno il valore avuto al momento della chiamata di
2771 \func{longjmp}, mentre quelli tenuti nei registri del processore (che nella
2772 chiamata ad un'altra funzione vengono salvati nel contesto nello
2773 \textit{stack}) torneranno al valore avuto al momento della chiamata di
2774 \func{setjmp}; per questo quando si vuole avere un comportamento coerente si
2775 può bloccare l'ottimizzazione che porta le variabili nei registri
2776 dichiarandole tutte come \direct{volatile}.\footnote{la direttiva
2777   \direct{volatile} informa il compilatore che la variabile che è dichiarata
2778   può essere modificata, durante l'esecuzione del nostro, da altri programmi.
2779   Per questo motivo occorre dire al compilatore che non deve essere mai
2780   utilizzata l'ottimizzazione per cui quanto opportuno essa viene mantenuta in
2781   un registro, poiché in questo modo si perderebbero le eventuali modifiche
2782   fatte dagli altri programmi (che avvengono solo in una copia posta in
2783   memoria).}
2784
2785 \index{salto~non-locale|)}
2786
2787
2788 % TODO trattare qui le restartable sequences (vedi
2789 % https://lwn.net/Articles/664645/ e https://lwn.net/Articles/650333/) se e
2790 % quando saranno introdotte
2791
2792 \subsection{La \textit{endianness}}
2793 \label{sec:endianness}
2794
2795 \itindbeg{endianness} 
2796
2797 Un altro dei problemi di programmazione che può dar luogo ad effetti
2798 imprevisti è quello relativo alla cosiddetta \textit{endianness}.  Questa è
2799 una caratteristica generale dell'architettura hardware di un computer che
2800 dipende dal fatto che la rappresentazione di un numero binario può essere
2801 fatta in due modi, chiamati rispettivamente \textit{big endian} e
2802 \textit{little endian}, a seconda di come i singoli bit vengono aggregati per
2803 formare le variabili intere (ed in genere in diretta corrispondenza a come
2804 sono poi in realtà cablati sui bus interni del computer).
2805
2806 \begin{figure}[!htb]
2807   \centering \includegraphics[height=3cm]{img/endianness}
2808   \caption{Schema della disposizione dei dati in memoria a seconda della
2809     \textit{endianness}.}
2810   \label{fig:sock_endianness}
2811 \end{figure}
2812
2813 Per capire meglio il problema si consideri un intero a 32 bit scritto in una
2814 locazione di memoria posta ad un certo indirizzo. Come illustrato in
2815 fig.~\ref{fig:sock_endianness} i singoli bit possono essere disposti in memoria
2816 in due modi: a partire dal più significativo o a partire dal meno
2817 significativo.  Così nel primo caso si troverà il byte che contiene i bit più
2818 significativi all'indirizzo menzionato e il byte con i bit meno significativi
2819 nell'indirizzo successivo; questo ordinamento è detto \textit{big endian},
2820 dato che si trova per prima la parte più grande. Il caso opposto, in cui si
2821 parte dal bit meno significativo è detto per lo stesso motivo \textit{little
2822   endian}.
2823
2824 Si può allora verificare quale tipo di \textit{endianness} usa il proprio
2825 computer con un programma elementare che si limita ad assegnare un valore ad
2826 una variabile per poi ristamparne il contenuto leggendolo un byte alla volta.
2827 Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
2828 allora se lo eseguiamo su un normale PC compatibile, che è \textit{little
2829   endian} otterremo qualcosa del tipo:
2830 \begin{Console}
2831 [piccardi@gont sources]$ \textbf{./endtest}
2832 Using value ABCDEF01
2833 val[0]= 1
2834 val[1]=EF
2835 val[2]=CD
2836 val[3]=AB
2837 \end{Console}
2838 %$
2839 mentre su un vecchio Macintosh con PowerPC, che è \textit{big endian} avremo
2840 qualcosa del tipo:
2841 \begin{Console}
2842 piccardi@anarres:~/gapil/sources$ \textbf{./endtest}
2843 Using value ABCDEF01
2844 val[0]=AB
2845 val[1]=CD
2846 val[2]=EF
2847 val[3]= 1
2848 \end{Console}
2849 %$
2850
2851 L'attenzione alla \textit{endianness} nella programmazione è importante, perché
2852 se si fanno assunzioni relative alla propria architettura non è detto che
2853 queste restino valide su un'altra architettura. Inoltre, come vedremo ad
2854 esempio in sez.~\ref{sec:sock_addr_func}, si possono avere problemi quando ci
2855 si trova a usare valori di un formato con una infrastruttura che ne usa
2856 un altro. 
2857
2858 La \textit{endianness} di un computer dipende essenzialmente dalla architettura
2859 hardware usata; Intel e Digital usano il \textit{little endian}, Motorola,
2860 IBM, Sun (sostanzialmente tutti gli altri) usano il \textit{big endian}. Il
2861 formato dei dati contenuti nelle intestazioni dei protocolli di rete (il
2862 cosiddetto \textit{network order}) è anch'esso \textit{big endian}; altri
2863 esempi di uso di questi due diversi formati sono quello del bus PCI, che è
2864 \textit{little endian}, o quello del bus VME che è \textit{big endian}.
2865
2866 Esistono poi anche dei processori che possono scegliere il tipo di formato
2867 all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
2868 da un tipo di ordinamento all'altro con una specifica istruzione. In ogni caso
2869 in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
2870 in genere resta sempre lo stesso,\footnote{su architettura PowerPC è possibile
2871   cambiarlo, si veda sez.~\ref{sec:process_prctl}.} anche quando il processore
2872 permetterebbe di eseguire questi cambiamenti.
2873
2874 \begin{figure}[!htbp]
2875   \footnotesize \centering
2876   \begin{minipage}[c]{\codesamplewidth}
2877     \includecodesample{listati/endian.c}
2878   \end{minipage} 
2879   \normalsize
2880   \caption{La funzione \samplefunc{endian}, usata per controllare il tipo di
2881     architettura della macchina.}
2882   \label{fig:sock_endian_code}
2883 \end{figure}
2884
2885 Per controllare quale tipo di ordinamento si ha sul proprio computer si è
2886 scritta una piccola funzione di controllo, il cui codice è riportato
2887 fig.~\ref{fig:sock_endian_code}, che restituisce un valore nullo (falso) se
2888 l'architettura è \textit{big endian} ed uno non nullo (vero) se l'architettura
2889 è \textit{little endian}.
2890
2891 Come si vede la funzione è molto semplice, e si limita, una volta assegnato
2892 (\texttt{\small 9}) un valore di test pari a \texttt{0xABCD} ad una variabile
2893 di tipo \ctyp{short} (cioè a 16 bit), a ricostruirne una copia byte a byte.
2894 Per questo prima (\texttt{\small 10}) si definisce il puntatore \var{ptr} per
2895 accedere al contenuto della prima variabile, ed infine calcola (\texttt{\small
2896   11}) il valore della seconda assumendo che il primo byte sia quello meno
2897 significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianness}, che sia
2898 \textit{little endian}). Infine la funzione restituisce (\texttt{\small 12})
2899 il valore del confronto delle due variabili. 
2900
2901 In generale non ci si deve preoccupare della \textit{endianness} all'interno
2902 di un programma fintanto che questo non deve generare o manipolare dei dati
2903 che sono scambiati con altre macchine, ad esempio via rete o tramite dei file
2904 binari. Nel primo caso la scelta è già stata fatta nella standardizzazione dei
2905 protocolli, che hanno adottato il \textit{big endian} (che viene detto anche
2906 per questo \textit{network order}); vedremo in sez.~\ref{sec:sock_func_ord} le
2907 funzioni di conversione che devono essere usate.
2908
2909 Nel secondo caso occorre sapere quale \textit{endianness} è stata usata nei
2910 dati memorizzati sul file e tenerne conto nella rilettura e nella
2911 manipolazione e relativa modifica (e salvataggio). La gran parte dei formati
2912 binari standardizzati specificano quale \textit{endianness} viene utilizzata e
2913 basterà identificare qual'è, se se ne deve definire uno per i propri scopi
2914 basterà scegliere una volta per tutte quale usare e attenersi alla scelta.
2915
2916 \itindend{endianness}
2917
2918
2919 % LocalWords:  like exec kernel thread main ld linux static linker char envp Gb
2920 % LocalWords:  sez POSIX exit system call cap abort shell diff errno stdlib int
2921 % LocalWords:  SUCCESS FAILURE void atexit stream fclose unistd descriptor init
2922 % LocalWords:  SIGCHLD wait function glibc SunOS arg argp execve fig high kb Mb
2923 % LocalWords:  memory alpha swap table printf Unit MMU paging fault SIGSEGV BSS
2924 % LocalWords:  multitasking text segment NULL Block Started Symbol fill black
2925 % LocalWords:  heap stack calling convention size malloc calloc realloc nmemb
2926 % LocalWords:  ENOMEM ptr uClib cfree error leak smartpointers hook Dmalloc brk
2927 % LocalWords:  Gray Watson Electric Fence Bruce Perens sbrk longjmp SUSv BSD ap
2928 % LocalWords:  ptrdiff increment locking lock copy write capabilities IPC mlock
2929 % LocalWords:  capability MEMLOCK limits getpagesize RLIMIT munlock sys const
2930 % LocalWords:  addr len EINVAL EPERM mlockall munlockall flags l'OR CURRENT IFS
2931 % LocalWords:  argc argv parsing questofile txt getopt optstring switch optarg
2932 % LocalWords:  optind opterr optopt POSIXLY CORRECT long options NdA group
2933 % LocalWords:  option parameter list environ PATH HOME XPG tab LOGNAME LANG PWD
2934 % LocalWords:  TERM PAGER TMPDIR getenv name SVr setenv unsetenv putenv opz gcc
2935 % LocalWords:  clearenv libc value overwrite string reference result argument
2936 % LocalWords:  socket variadic ellipsis header stdarg execl self promoting last
2937 % LocalWords:  float double short register type dest src extern setjmp jmp buf
2938 % LocalWords:  env return if while Di page cdecl  rectangle node anchor west PS
2939 % LocalWords:  environment rounded corners dashed south width height draw east
2940 % LocalWords:  exithandler handler violation inline SOURCE SVID XOPEN mincore
2941 % LocalWords:  length unsigned vec EFAULT EAGAIN dell'I memalign valloc posix
2942 % LocalWords:  boundary memptr alignment sizeof overrun mcheck abortfn enum big
2943 % LocalWords:  mprobe DISABLED HEAD TAIL touch right emacs OSTYPE endianness IBM
2944 % LocalWords:  endian little endtest Macintosh PowerPC Intel Digital Motorola
2945 % LocalWords:  Sun order VME  loader Windows DLL shared objects PRELOAD termios
2946 % LocalWords:  is to LC SIG str mem wcs assert ctype dirent fcntl signal stdio
2947 % LocalWords:  times library utmp syscall number Filesystem Hierarchy pathname
2948 % LocalWords:  context assembler sysconf fork Dinamic huge segmentation program
2949 % LocalWords:  break store using intptr ssize overflow ONFAULT faulting alloc
2950 %  LocalWords:  scheduler pvalloc aligned ISOC ABCDEF
2951
2952 %%% Local Variables: 
2953 %%% mode: latex
2954 %%% TeX-master: "gapil"
2955 %%% End: