Oltre alla conclusione ``\textsl{normale}'' esiste anche la possibilità di una
conclusione ``\textsl{anomala}'' del programma a causa della ricezione di un
-segnale (si veda \capref{cha:signals}) o della chiamata alla funzione
+segnale (si veda cap.~\ref{cha:signals}) o della chiamata alla funzione
\func{abort}; torneremo su questo in sez.~\ref{sec:proc_termination}.
Il valore di ritorno della funzione \func{main}, o quello usato nelle chiamate
La funzione chiude tutti i file descriptor appartenenti al processo (si tenga
presente che questo non comporta il salvataggio dei dati bufferizzati degli
stream), fa sì che ogni figlio del processo sia ereditato da \cmd{init} (vedi
-sez.~\ref{cha:process_handling}), manda un segnale \const{SIGCHLD} al processo
-padre (vedi sez.~\ref{sec:sig_job_control}) ed infine ritorna lo stato di uscita
-specificato in \param{status} che può essere raccolto usando la funzione
-\func{wait} (vedi sez.~\ref{sec:proc_wait}).
+cap.~\ref{cha:process_handling}), manda un segnale \const{SIGCHLD} al processo
+padre (vedi sez.~\ref{sec:sig_job_control}) ed infine ritorna lo stato di
+uscita specificato in \param{status} che può essere raccolto usando la
+funzione \func{wait} (vedi sez.~\ref{sec:proc_wait}).
\subsection{Le funzioni \func{atexit} e \func{on\_exit}}
Si ricordi infine che un programma può anche essere interrotto dall'esterno
attraverso l'uso di un segnale (modalità di conclusione non mostrata in
fig.~\ref{fig:proc_prog_start_stop}); torneremo su questo aspetto in
-\capref{cha:signals}.
+cap.~\ref{cha:signals}.
2Gb. Con il kernel 2.4 ed il supporto per la \textit{high-memory} il limite
è stato esteso.}
-Come accennato in \capref{cha:intro_unix} questo spazio di indirizzi è
+Come accennato in cap.~\ref{cha:intro_unix} questo spazio di indirizzi è
virtuale e non corrisponde all'effettiva posizione dei dati nella RAM del
computer; in genere detto spazio non è neppure continuo (cioè non tutti gli
indirizzi possibili sono utilizzabili, e quelli usabili non sono
in genere il sistema è molto efficiente in questo lavoro; quando però ci siano
esigenze specifiche di prestazioni è possibile usare delle funzioni che
permettono di bloccare il meccanismo della paginazione\index{paginazione} e
-mantenere fisse delle pagine in memoria (vedi \ref{sec:proc_mem_lock}).
+mantenere fisse delle pagine in memoria (vedi sez.~\ref{sec:proc_mem_lock}).
\subsection{La struttura della memoria di un processo}
queste variabili al programma messo in esecuzione attraverso un uso opportuno
delle relative chiamate (si veda sez.~\ref{sec:proc_exec}).
-La shell ad esempio ne usa molte per il suo funzionamento (come \var{PATH} per
-la ricerca dei comandi, o \cmd{IFS} per la scansione degli argomenti), e
-alcune di esse (come \var{HOME}, \var{USER}, etc.) sono definite al login (per
-i dettagli si veda sez.~\ref{sec:sess_login}). In genere è cura
+La shell ad esempio ne usa molte per il suo funzionamento (come \texttt{PATH}
+per la ricerca dei comandi, o \texttt{IFS} per la scansione degli argomenti),
+e alcune di esse (come \texttt{HOME}, \texttt{USER}, etc.) sono definite al
+login (per i dettagli si veda sez.~\ref{sec:sess_login}). In genere è cura
dell'amministratore definire le opportune variabili di ambiente in uno script
di avvio. Alcune servono poi come riferimento generico per molti programmi
-(come \var{EDITOR} che indica l'editor preferito da invocare in caso di
+(come \texttt{EDITOR} che indica l'editor preferito da invocare in caso di
necessità).
Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
& \textbf{Linux} & \textbf{Descrizione} \\
\hline
\hline
- \val{USER} & $\bullet$ & $\bullet$ & $\bullet$ & Nome utente\\
- \val{LOGNAME} & $\bullet$ & $\bullet$ & $\bullet$ & Nome di login\\
- \val{HOME} & $\bullet$ & $\bullet$ & $\bullet$ &
- Directory base dell'utente\\
- \val{LANG} & $\bullet$ & $\bullet$ & $\bullet$ & Localizzazione\\
- \val{PATH} & $\bullet$ & $\bullet$ & $\bullet$ & Elenco delle directory
- dei programmi\\
- \val{PWD} & $\bullet$ & $\bullet$ & $\bullet$ & Directory corrente\\
- \val{SHELL} & $\bullet$ & $\bullet$ & $\bullet$ & Shell in uso\\
- \val{TERM} & $\bullet$ & $\bullet$ & $\bullet$ & Tipo di terminale\\
- \val{PAGER} & $\bullet$ & $\bullet$ & $\bullet$ & Programma per vedere i
- testi\\
- \val{EDITOR} & $\bullet$ & $\bullet$ & $\bullet$ & Editor preferito\\
- \val{BROWSER} & $\bullet$ & $\bullet$ & $\bullet$ & Browser preferito\\
- \val{TMPDIR} & $\bullet$ & $\bullet$ & $\bullet$ & Directory dei file
- temporanei\\
+ \texttt{USER} &$\bullet$&$\bullet$&$\bullet$& Nome utente\\
+ \texttt{LOGNAME}&$\bullet$&$\bullet$&$\bullet$& Nome di login\\
+ \texttt{HOME} &$\bullet$&$\bullet$&$\bullet$& Directory base
+ dell'utente\\
+ \texttt{LANG} &$\bullet$&$\bullet$&$\bullet$& Localizzazione\\
+ \texttt{PATH} &$\bullet$&$\bullet$&$\bullet$& Elenco delle directory
+ dei programmi\\
+ \texttt{PWD} &$\bullet$&$\bullet$&$\bullet$& Directory corrente\\
+ \texttt{SHELL} &$\bullet$&$\bullet$&$\bullet$& Shell in uso\\
+ \texttt{TERM} &$\bullet$&$\bullet$&$\bullet$& Tipo di terminale\\
+ \texttt{PAGER} &$\bullet$&$\bullet$&$\bullet$& Programma per vedere i
+ testi\\
+ \texttt{EDITOR} &$\bullet$&$\bullet$&$\bullet$& Editor preferito\\
+ \texttt{BROWSER}&$\bullet$&$\bullet$&$\bullet$& Browser preferito\\
+ \texttt{TMPDIR} &$\bullet$&$\bullet$&$\bullet$& Directory dei file
+ temporanei\\
\hline
\end{tabular}
\caption{Esempi delle variabili di ambiente più comuni definite da vari
seguendo il comportamento di BSD4.4; dato che questo può dar luogo a perdite
di memoria e non rispetta lo standard. Il comportamento è stato modificato a
partire dalle 2.1.2, eliminando anche, sempre in conformità a SUSv2,
- l'attributo \ctyp{const} dal prototipo.} \param{string} alla lista delle
+ l'attributo \direct{const} dal prototipo.} \param{string} alla lista delle
variabili di ambiente; pertanto ogni cambiamento alla stringa in questione si
riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
questa funzione una variabile automatica (per evitare i problemi esposti in
Talvolta però è necessario che la funzione possa restituire indietro alla
funzione chiamante un valore relativo ad uno dei suoi parametri. Per far
-questo si usa il cosiddetto \textit{value result argument}, si passa cioè,
-invece di una normale variabile, un puntatore alla stessa; vedremo alcuni
-esempi di questa modalità nelle funzioni che gestiscono i socket (in
+questo si usa il cosiddetto
+\index{\textit{value~result~argument}}\textit{value result argument}, si passa
+cioè, invece di una normale variabile, un puntatore alla stessa; vedremo
+alcuni esempi di questa modalità nelle funzioni che gestiscono i socket (in
sez.~\ref{sec:TCP_functions}), in cui, per permettere al kernel di restituire
informazioni sulle dimensioni delle strutture degli indirizzi utilizzate,
viene usato questo meccanismo.
a sé stesso.} il che esclude vettori, puntatori a funzioni e interi di tipo
\ctyp{char} o \ctyp{short} (con segno o meno). Una restrizione ulteriore di
alcuni compilatori è di non dichiarare l'ultimo parametro fisso come
-\ctyp{register}.
+\direct{register}.
Una volta dichiarata la funzione il secondo passo è accedere ai vari parametri
quando la si va a definire. I parametri fissi infatti hanno un loro nome, ma
torneranno al valore avuto al momento della chiamata di \func{setjmp}; per
questo quando si vuole avere un comportamento coerente si può bloccare
l'ottimizzazione che porta le variabili nei registri dichiarandole tutte come
-\direct{volatile}\footnote{la direttiva \ctyp{volatile} informa il compilatore
- che la variabile che è dichiarata può essere modificata, durante
+\direct{volatile}\footnote{la direttiva \direct{volatile} informa il
+ compilatore che la variabile che è dichiarata può essere modificata, durante
l'esecuzione del nostro, da altri programmi. Per questo motivo occorre dire
al compilatore che non deve essere mai utilizzata l'ottimizzazione per cui
quanto opportuno essa viene mantenuta in un registro, poiché in questo modo