%% process.tex
%%
-%% Copyright (C) 2000-2003 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2004 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
-%% Free Software Foundation; with the Invariant Sections being "Prefazione",
+%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
%% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
%% license is included in the section entitled "GNU Free Documentation
%% License".
In realtà nei sistemi Unix esiste un'altro modo per definire la funzione
\func{main}, che prevede la presenza di un terzo parametro, \code{char
- *envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{sec:proc_environ})
+ *envp[]}, che fornisce l'\textsl{ambiente} (vedi sez.~\ref{sec:proc_environ})
del programma; questa forma però non è prevista dallo standard POSIX.1 per cui
se si vogliono scrivere programmi portabili è meglio evitarla.
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
-\func{abort}; torneremo su questo in \secref{sec:proc_termination}.
+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
ad \func{exit} e \func{\_exit}, viene chiamato \textsl{stato di uscita} (o
Si tenga presente inoltre che non è una buona idea usare il codice di errore
restituito dalla variabile \var{errno} (per i dettagli si veda
-\secref{sec:sys_errors}) come stato di uscita. In generale infatti una shell
+sez.~\ref{sec:sys_errors}) come stato di uscita. In generale infatti una shell
non si cura del valore se non per vedere se è diverso da zero; inoltre il
valore dello stato di uscita è sempre troncato ad 8 bit, per cui si potrebbe
incorrere nel caso in cui restituendo un codice di errore 256, si otterrebbe
La funzione \func{exit} è pensata per eseguire una conclusione pulita di un
programma che usi le librerie standard del C; essa esegue tutte le funzioni
che sono state registrate con \func{atexit} e \func{on\_exit} (vedi
-\secref{sec:proc_atexit}), e chiude tutti gli stream effettuando il
+sez.~\ref{sec:proc_atexit}), e chiude tutti gli stream effettuando il
salvataggio dei dati sospesi (chiamando \func{fclose}, vedi
-\secref{sec:file_fopen}), infine passa il controllo al kernel chiamando
+sez.~\ref{sec:file_fopen}), infine passa il controllo al kernel chiamando
\func{\_exit} e restituendo il valore di \param{status} come stato di uscita.
La system call \funcd{\_exit} restituisce direttamente il controllo al kernel,
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
-\secref{cha:process_handling}), manda un segnale \const{SIGCHLD} al processo
-padre (vedi \secref{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 \secref{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}}
in un sistema Unix l'unico modo in cui un programma può essere eseguito dal
kernel è attraverso la chiamata alla system call \func{execve} (o attraverso
una delle funzioni della famiglia \func{exec} che vedremo in
-\secref{sec:proc_exec}).
+sez.~\ref{sec:proc_exec}).
Allo stesso modo l'unico modo in cui un programma può concludere
volontariamente la sua esecuzione è attraverso una chiamata alla system call
\func{exit} o il ritorno di \func{main}.
Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
-normalmente un programma è riportato in \figref{fig:proc_prog_start_stop}.
+normalmente un programma è riportato in fig.~\ref{fig:proc_prog_start_stop}.
\begin{figure}[htb]
\centering
- \includegraphics[width=12cm]{img/proc_beginend}
+ \includegraphics[width=14cm]{img/proc_beginend}
\caption{Schema dell'avvio e della conclusione di un programma.}
\label{fig:proc_prog_start_stop}
\end{figure}
Si ricordi infine che un programma può anche essere interrotto dall'esterno
attraverso l'uso di un segnale (modalità di conclusione non mostrata in
-\figref{fig:proc_prog_start_stop}); torneremo su questo aspetto in
-\capref{cha:signals}.
+fig.~\ref{fig:proc_prog_start_stop}); torneremo su questo aspetto in
+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}
puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
variabili che vanno nel segmento dati, e non è affatto vero in generale.}
- Storicamente questo segmento viene chiamato BBS (da \textit{block started by
+ Storicamente questo segmento viene chiamato BSS (da \textit{block started by
symbol}). La sua dimensione è fissa.
\item Lo \textit{heap}. Tecnicamente lo si può considerare l'estensione del
segmento dati, a cui di solito è posto giusto di seguito. È qui che avviene
l'allocazione dinamica della memoria; può essere ridimensionato allocando e
disallocando la memoria dinamica con le apposite funzioni (vedi
- \secref{sec:proc_mem_alloc}), ma il suo limite inferiore (quello adiacente
+ sez.~\ref{sec:proc_mem_alloc}), ma il suo limite inferiore (quello adiacente
al segmento dati) ha una posizione fissa.
\item Il segmento di \textit{stack}, che contiene lo \textit{stack} del
\begin{figure}[htb]
\centering
- \includegraphics[width=5cm]{img/memory_layout}
+ \includegraphics[height=12cm]{img/memory_layout}
\caption{Disposizione tipica dei segmenti di memoria di un processo.}
\label{fig:proc_mem_layout}
\end{figure}
Una disposizione tipica di questi segmenti è riportata in
-\figref{fig:proc_mem_layout}. Usando il comando \cmd{size} su un programma se
+fig.~\ref{fig:proc_mem_layout}. Usando il comando \cmd{size} su un programma se
ne può stampare le dimensioni dei segmenti di testo e di dati (inizializzati e
BSS); si tenga presente però che il BSS non è mai salvato sul file che
contiene l'eseguibile, dato che viene sempre inizializzato a zero al
\begin{itemize}
\item se la variabile è posta a zero gli errori vengono ignorati.
\item se è posta ad 1 viene stampato un avviso sullo \textit{standard error}
- (vedi \secref{sec:file_std_stream}).
+ (vedi sez.~\ref{sec:file_std_stream}).
\item se è posta a 2 viene chiamata \func{abort}, che in genere causa
l'immediata conclusione del programma.
\end{itemize}
evitare alla radice i problemi di memory leak\index{memory leak}, dato che non
serve più la deallocazione esplicita; inoltre la deallocazione automatica
funziona anche quando si usa \func{longjmp} per uscire da una subroutine con
-un salto non locale da una funzione (vedi \secref{sec:proc_longjmp}).
+un salto non locale da una funzione (vedi sez.~\ref{sec:proc_longjmp}).
Un altro vantaggio è che in Linux la funzione è molto più veloce di
\func{malloc} e non viene sprecato spazio, infatti non è necessario gestire un
chiamata, dato che all'uscita dalla funzione lo spazio allocato diventerebbe
libero, e potrebbe essere sovrascritto all'invocazione di nuove funzioni.
Questo è lo stesso problema che si può avere con le variabili automatiche, su
-cui torneremo in \secref{sec:proc_auto_var}.
+cui torneremo in sez.~\ref{sec:proc_auto_var}.
\subsection{Le funzioni \func{brk} e \func{sbrk}}
Queste due funzioni vengono utilizzate soltanto quando è necessario effettuare
direttamente la gestione della memoria associata allo spazio dati di un
processo, ad esempio qualora si debba implementare la propria versione delle
-routine di allocazione della memoria viste in \secref{sec:proc_mem_malloc}. La
-prima funzione è \funcd{brk}, ed il suo prototipo è:
+routine di allocazione della memoria viste in sez.~\ref{sec:proc_mem_malloc}.
+La prima funzione è \funcd{brk}, ed il suo prototipo è:
\begin{prototype}{unistd.h}{int brk(void *end\_data\_segment)}
Sposta la fine del segmento dei dati.
l'indirizzo finale del segmento dati di un processo all'indirizzo specificato
da \param{end\_data\_segment}. Quest'ultimo deve essere un valore ragionevole,
ed inoltre la dimensione totale del segmento non deve comunque eccedere un
-eventuale limite (si veda \secref{sec:sys_resource_limit}) imposto sulle
+eventuale limite (si veda sez.~\ref{sec:sys_resource_limit}) imposto sulle
dimensioni massime dello spazio dati del processo.
La seconda funzione per la manipolazione delle dimensioni del segmento
\subsection{Il controllo della memoria virtuale\index{memoria virtuale}}
\label{sec:proc_mem_lock}
-Come spiegato in \secref{sec:proc_mem_gen} il kernel gestisce la memoria
+Come spiegato in sez.~\ref{sec:proc_mem_gen} il kernel gestisce la memoria
virtuale in maniera trasparente ai processi, decidendo quando rimuovere pagine
dalla memoria per metterle nello swap, sulla base dell'utilizzo corrente da
parte dei vari processi.
quali pagine di memoria è opportuno che restino in memoria per un aumento
delle prestazioni. In genere queste sono esigenze particolari e richiedono
anche un aumento delle priorità in esecuzione del processo (vedi
- \secref{sec:proc_real_time}).
+ sez.~\ref{sec:proc_real_time}).
\item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro
in memoria queste possono essere portate su disco dal meccanismo della
comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
tutti i suoi \textit{memory lock}. Infine \textit{memory lock} non sono
ereditati dai processi figli.\footnote{ma siccome Linux usa il \textit{copy on
- write}\index{copy on write} (vedi \secref{sec:proc_fork}) gli indirizzi
+ write}\index{copy on write} (vedi sez.~\ref{sec:proc_fork}) gli indirizzi
virtuali del figlio sono mantenuti sullo stesso segmento di RAM del padre,
quindi fintanto che un figlio non scrive su un segmento, può usufruire del
memory lock del padre.}
Siccome la richiesta di un \textit{memory lock} da parte di un processo riduce
la memoria fisica disponibile nel sistema, questo ha un evidente impatto su
tutti gli altri processi, per cui solo un processo con i privilegi di
-amministratore (vedremo in \secref{sec:proc_perms} cosa significa) ha la
+amministratore (vedremo in sez.~\ref{sec:proc_perms} cosa significa) ha la
capacità di bloccare una pagina. Ogni processo può però sbloccare le pagine
relative alla propria memoria.
vengono lanciati. Il passaggio dei parametri è effettuato attraverso gli
argomenti \param{argc} e \param{argv} della funzione \func{main}, che vengono
passati al programma dalla shell (o dal processo che esegue la \func{exec},
-secondo le modalità che vedremo in \secref{sec:proc_exec}) quando questo viene
-messo in esecuzione.
+secondo le modalità che vedremo in sez.~\ref{sec:proc_exec}) quando questo
+viene messo in esecuzione.
Oltre al passaggio dei parametri, un'altra modalità che permette di passare
delle informazioni che modifichino il comportamento di un programma è quello
in successione il puntatore alla stringa costituente l'$n$-simo parametro; la
variabile \param{argc} viene inizializzata al numero di parametri trovati, in
questo modo il primo parametro è sempre il nome del programma; un esempio di
-questo meccanismo è mostrato in \figref{fig:proc_argv_argc}.
+questo meccanismo è mostrato in fig.~\ref{fig:proc_argv_argc}.
\subsection{La gestione delle opzioni}
un'opzione. In genere le opzioni sono costituite da una lettera singola
(preceduta dal carattere \cmd{'-'}) e possono avere o no un parametro
associato; un comando tipico può essere quello mostrato in
-\figref{fig:proc_argv_argc}. In quel caso le opzioni sono \cmd{-r} e \cmd{-m}
+fig.~\ref{fig:proc_argv_argc}. In quel caso le opzioni sono \cmd{-r} e \cmd{-m}
e la prima vuole un parametro mentre la seconda no (\cmd{questofile.txt} è un
argomento del programma, non un parametro di \cmd{-m}).
La stringa \param{optstring} indica quali sono le opzioni riconosciute ed è
costituita da tutti i caratteri usati per identificare le singole opzioni, se
l'opzione ha un parametro al carattere deve essere fatto seguire un segno di
-due punti \texttt{':'}; nel caso di \figref{fig:proc_argv_argc} ad esempio la
+due punti \texttt{':'}; nel caso di fig.~\ref{fig:proc_argv_argc} ad esempio la
stringa di opzioni avrebbe dovuto contenere \texttt{"r:m"}.
La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
\item \var{int optopt} contiene il carattere dell'opzione non riconosciuta.
\end{itemize*}
-In \figref{fig:proc_options_code} è mostrata la sezione del programma
+In fig.~\ref{fig:proc_options_code} è mostrata la sezione del programma
\file{ForkTest.c} (che useremo nel prossimo capitolo per effettuare dei test
sulla creazione dei processi) deputata alla decodifica delle opzioni a riga di
comando.
\includecodesnip{listati/env_ptr.c}
un esempio della struttura di questa lista, contenente alcune delle variabili
più comuni che normalmente sono definite dal sistema, è riportato in
-\figref{fig:proc_envirno_list}.
+fig.~\ref{fig:proc_envirno_list}.
\begin{figure}[htb]
\centering
\includegraphics[width=11cm]{img/environ_var}
Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
\textsl{\texttt{nome=valore}}. Inoltre alcune variabili, come quelle elencate
-in \figref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
+in fig.~\ref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
usare nomi espressi in caratteri maiuscoli.\footnote{la convenzione vuole che
si usino dei nomi maiuscoli per le variabili di ambiente di uso generico, i
dover ricorrere all'uso di opzioni a linea di comando o di file di
configurazione. É di norma cura della shell, quando esegue un comando, passare
queste variabili al programma messo in esecuzione attraverso un uso opportuno
-delle relative chiamate (si veda \secref{sec:proc_exec}).
+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 \secref{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ù
-comuni), come riportato in \tabref{tab:proc_env_var}. GNU/Linux le supporta
+comuni), come riportato in tab.~\ref{tab:proc_env_var}. GNU/Linux le supporta
tutte e ne definisce anche altre: per una lista più completa si può
controllare \cmd{man environ}.
& \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
C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
utilizzare per impostare e per cancellare le variabili di ambiente. Uno schema
delle funzioni previste nei vari standard e disponibili in Linux è riportato
-in \tabref{tab:proc_env_func}.
+in tab.~\ref{tab:proc_env_func}.
\begin{table}[htb]
\centering
\textbf{SVr4} & \textbf{BSD} & \textbf{Linux} \\
\hline
\hline
- \func{getenv} & $\bullet$ & $\bullet$ & $\bullet$ &
- $\bullet$ & $\bullet$ & $\bullet$ \\
- \func{setenv} & & & &
- & $\bullet$ & $\bullet$ \\
- \func{unsetenv} & & & &
- & $\bullet$ & $\bullet$ \\
- \func{putenv} & & opz. & $\bullet$ &
- & $\bullet$ & $\bullet$ \\
- \func{clearenv} & & opz. & &
- & & $\bullet$ \\
+ \func{getenv} & $\bullet$ & $\bullet$ & $\bullet$
+ & $\bullet$ & $\bullet$ & $\bullet$ \\
+ \func{setenv} & -- & -- & --
+ & -- & $\bullet$ & $\bullet$ \\
+ \func{unsetenv}& -- & -- & --
+ & -- & $\bullet$ & $\bullet$ \\
+ \func{putenv} & -- & opz. & $\bullet$
+ & -- & $\bullet$ & $\bullet$ \\
+ \func{clearenv}& -- & opz. & --
+ & -- & -- & $\bullet$ \\
\hline
\end{tabular}
\caption{Funzioni per la gestione delle variabili di ambiente.}
In Linux\footnote{in realtà nelle libc4 e libc5 sono definite solo le prime
quattro, \func{clearenv} è stata introdotta con le \acr{glibc} 2.0.} sono
-definite tutte le funzioni elencate in \tabref{tab:proc_env_func}. La prima,
+definite tutte le funzioni elencate in tab.~\ref{tab:proc_env_func}. La prima,
\func{getenv}, l'abbiamo appena esaminata; delle restanti le prime due,
\funcd{putenv} e \funcd{setenv}, servono per assegnare nuove variabili di
ambiente, i loro prototipi sono i seguenti:
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
-\secref{sec:proc_auto_var}).
+sez.~\ref{sec:proc_auto_var}).
Si tenga infine presente che se si passa a \func{putenv} solo il nome di una
variabile (cioè \param{string} è nella forma \texttt{NAME} e non contiene un
corrente sarà deallocata solo se anch'essa è risultante da un'allocazione
fatta in precedenza da un'altra \func{putenv}. Questo perché il vettore delle
variabili di ambiente iniziale, creato dalla chiamata ad \func{exec} (vedi
-\secref{sec:proc_exec}) è piazzato al di sopra dello stack, (vedi
-\figref{fig:proc_mem_layout}) e non nello heap e non può essere deallocato.
+sez.~\ref{sec:proc_exec}) è piazzato al di sopra dello stack, (vedi
+fig.~\ref{fig:proc_mem_layout}) e non nello heap e non può essere deallocato.
Inoltre la memoria associata alle variabili di ambiente eliminate non viene
liberata.
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
-\secref{sec:TCP_functions}), in cui, per permettere al kernel di restituire
+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.
abbia sempre almeno un argomento fisso; prima di effettuare la dichiarazione
deve essere incluso l'apposito header file \file{stdarg.h}; un esempio di
dichiarazione è il prototipo della funzione \func{execl} che vedremo in
-\secref{sec:proc_exec}:
+sez.~\ref{sec:proc_exec}:
\includecodesnip{listati/exec_sample.c}
in questo caso la funzione prende due parametri fissi ed un numero variabile
di altri parametri (che verranno a costituire gli elementi successivi al primo
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
salvare il contesto dello stack è \funcd{setjmp}, il cui prototipo è:
\begin{functions}
\headdecl{setjmp.h}
- \funcdecl{void setjmp(jmp\_buf env)}
+ \funcdecl{int setjmp(jmp\_buf env)}
Salva il contesto dello stack.
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
projects / gapil.git / blobdiff