\subsection{Come chiudere un programma}
\label{sec:proc_conclusion}
-Normalmente un programma finisce è quando la funzione \func{main} ritorna, una
+Normalmente un programma finisce quando la funzione \func{main} ritorna, una
modalità equivalente di chiudere il programma è quella di chiamare
direttamente la funzione \func{exit} (che viene comunque chiamata
automaticamente quando \func{main} ritorna). Una forma alternativa è quella
del chiamante (tipo il contenuto di alcuni registri della CPU). Poi la
funzione chiamata alloca qui lo spazio per le sue variabili locali: in
questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
- della funzione lo spazio è automaticamente rilasciato. Al ritorno della
- funzione lo spazio è automaticamente ripulito. La pulizia in C e C++ viene
- fatta dal chiamante.\footnote{a meno che non sia stato specificato
- l'utilizzo di una calling convention diversa da quella standard.}
+ della funzione lo spazio è automaticamente rilasciato e ``ripulito''. La
+ pulizia in C e C++ viene fatta dal chiamante.\footnote{a meno che non sia
+ stato specificato l'utilizzo di una calling convention diversa da quella
+ standard.}
La dimensione di questo segmento aumenta seguendo la crescita dello stack
del programma, ma non viene ridotta quando quest'ultimo si restringe.
dimensione di un'area di memoria precedentemente allocata, la funzione vuole
in ingresso il puntatore restituito dalla precedente chiamata ad una
\func{malloc} (se è passato un valore \macro{NULL} allora la funzione si
-comporta come \func{malloc},\footnote{questo è vero per Linux e
+comporta come \func{malloc})\footnote{questo è vero per Linux e
l'implementazione secondo lo standard ANSI C, ma non è vero per alcune
vecchie implementazioni, inoltre alcune versioni delle librerie del C
consentivano di usare \func{realloc} anche per un puntatore liberato con
\func{free} purché non ci fossero state nel frattempo altre chiamate a
funzioni di allocazione, questa funzionalità è totalmente deprecata e non è
- consentita sotto Linux.}) ad esempio quando si deve far crescere la
+ consentita sotto Linux.} ad esempio quando si deve far crescere la
dimensione di un vettore. In questo caso se è disponibile dello spazio
adiacente al precedente la funzione lo utilizza, altrimenti rialloca altrove
un blocco della dimensione voluta, copiandoci automaticamente il contenuto; lo
Il problema più comune e più difficile da risolvere che si incontra con le
routine di allocazione è quando non viene opportunamente liberata la memoria
non più utilizzata, quello che in inglese viene chiamato \textit{memory-leak},
-(cioè \textsl{perdita di memoria}).
+cioè \textsl{perdita di memoria}.
Un caso tipico che illustra il problema è quello in cui in una subroutine si
alloca della memoria per uso locale senza liberarla prima di uscire. La
memoria resta così allocata fino alla terminazione del processo. Chiamate
ripetute alla stessa subroutine continueranno ad effettuare altre allocazioni,
causando a lungo andare un esaurimento della memoria disponibile (e la
-probabile l'impossibilità di proseguire l'esecuzione programma).
+probabile impossibilità di proseguire l'esecuzione del programma).
Il problema è che l'esaurimento della memoria può avvenire in qualunque
momento, in corrispondenza ad una qualunque chiamata di \func{malloc}, che può
\item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro
in memoria queste possono essere portate su disco dal meccanismo della
paginazione. Questo rende più lungo il periodo di tempo in cui detti segreti
- sono presenti in chiaro e più complessa la loro cancellazione (ad un
- processo è possibile cancellare la memoria su cui scrive le sue variabili,
- ma non può toccare lo spazio disco su cui una pagina di memoria può essere
- stata salvata). Per questo motivo di solito i programmi di crittografia
- richiedono il blocco di alcune pagine di memoria.
+ sono presenti in chiaro e più complessa la loro cancellazione (un processo
+ può cancellare la memoria su cui scrive le sue variabili, ma non può toccare
+ lo spazio disco su cui una pagina di memoria può essere stata salvata). Per
+ questo motivo di solito i programmi di crittografia richiedono il blocco di
+ alcune pagine di memoria.
\end{itemize}
Il meccanismo che previene la paginazione di parte della memoria virtuale di
delle informazioni che modifichino il comportamento di un programma è quello
dell'uso del cosiddetto \textit{environment} (cioè l'uso delle
\textsl{variabili di ambiente}). In questa sezione esamineremo le funzioni che
-permettono di gestire parametri e opzioni, e quelle che consentono di
+permettono di gestire parametri ed opzioni, e quelle che consentono di
manipolare ed utilizzare le variabili di ambiente.
In generale un programma Unix riceve da linea di comando sia gli argomenti che
le opzioni, queste ultime sono standardizzate per essere riconosciute come
-tali: un elemento di \var{argv} che inizia con \texttt{-} e che non sia un
-singolo \texttt{-} o un \texttt{--} viene considerato un'opzione. In genere
-le opzioni sono costituite da una lettera singola (preceduta dal \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}
-ed \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}).
+tali: un elemento di \var{argv} che inizia con il carattere \texttt{'-'} e che
+non sia un singolo \texttt{'-'} o un \texttt{'--'} viene considerato
+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}
+e la prima vuole un parametro mentre la seconda no (\cmd{questofile.txt} è un
+argomento del programma, non un parametro di \cmd{-m}).
Per gestire le opzioni all'interno dei argomenti a linea di comando passati in
\var{argv} le librerie standard del C forniscono la funzione \func{getopt}
La stringa \var{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 \var{':'}; nel caso di \figref{fig:proc_argv_argc} ad esempio la
-stringa di opzioni avrebbe dovuto contenere \var{"r:m"}.
+due punti \texttt{':'}; nel caso di \figref{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
funzione all'interno di un ciclo, fintanto che essa non ritorna il valore -1
dichiarata in \var{optstring} viene ritornato il carattere \texttt{'?'}
mentre se un opzione che lo richiede non è seguita da un parametro viene
ritornato il carattere \texttt{':'}, infine se viene incontrato il valore
-\cmd{--} la scansione viene considerata conclusa, anche se vi sono altri
+\texttt{'--'} la scansione viene considerata conclusa, anche se vi sono altri
elementi di \var{argv} che cominciano con il carattere \texttt{'-'}.
\begin{figure}[htb]
sulla creazione dei processi) deputata alla decodifica delle opzioni a riga di
comando.
-Anzitutto si può notare che si è anzitutto (\texttt{\small 1}) disabilitata la
-stampa di messaggi di errore per opzioni non riconosciute, per poi passare al
-ciclo per la verifica delle opzioni (\texttt{\small 2-27}); per ciascuna delle
-opzioni possibili si è poi provveduto ad un'azione opportuna, ad esempio per
-le tre opzioni che prevedono un parametro si è effettuata la decodifica del
-medesimo (il cui indirizzo è contenuto nella variabile \var{optarg})
-avvalorando la relativa variabile (\texttt{\small 12-14}, \texttt{\small
- 15-17} e \texttt{\small 18-20}). Completato il ciclo troveremo in
-\var{optind} l'indice in \var{argv[]} del primo degli argomenti rimanenti
-nella linea di comando.
+Si può notare che si è anzitutto (\texttt{\small 1}) disabilitata la stampa di
+messaggi di errore per opzioni non riconosciute, per poi passare al ciclo per
+la verifica delle opzioni (\texttt{\small 2-27}); per ciascuna delle opzioni
+possibili si è poi provveduto ad un'azione opportuna, ad esempio per le tre
+opzioni che prevedono un parametro si è effettuata la decodifica del medesimo
+(il cui indirizzo è contenuto nella variabile \var{optarg}) avvalorando la
+relativa variabile (\texttt{\small 12-14}, \texttt{\small 15-17} e
+\texttt{\small 18-20}). Completato il ciclo troveremo in \var{optind} l'indice
+in \var{argv[]} del primo degli argomenti rimanenti nella linea di comando.
Normalmente \func{getopt} compie una permutazione degli elementi di \var{argv}
-così che alla fine della scansione gli elementi che non sono opzioni sono
+cosicché alla fine della scansione gli elementi che non sono opzioni sono
spostati in coda al vettore. Oltre a questa esistono altre due modalità di
gestire gli elementi di \var{argv}; se \var{optstring} inizia con il carattere
\texttt{'+'} (o è impostata la variabile di ambiente \macro{POSIXLY\_CORRECT})
\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
extern char ** environ;
\end{lstlisting}
-un esempio del contenuto dell'ambiente, in si è riportato un estratto delle
-variabili che normalmente sono definite dal sistema, è riportato in \nfig.
+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}.
\begin{figure}[htb]
\centering
\includegraphics[width=11cm]{img/environ_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
-\texttt{=}) allora questa viene cancellata dall'ambiente. Infine se la
-chiamata di \func{putenv} comporta la necessità di allocare una nuova versione
-del vettore \var{environ} questo sarà allocato, ma la versione 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
+carattere \texttt{'='}) allora questa viene cancellata dall'ambiente. Infine
+se la chiamata di \func{putenv} comporta la necessità di allocare una nuova
+versione del vettore \var{environ} questo sarà allocato, ma la versione
+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.
Inoltre la memoria associata alle variabili di ambiente eliminate non viene
In generale però possono esistere anche realizzazioni diverse, per questo
motivo \macro{va\_list} è definito come \textsl{tipo opaco} e non può essere
-assegnato direttamente ad un altra variabile dello stesso tipo. Per risolvere
+assegnato direttamente ad un'altra variabile dello stesso tipo. Per risolvere
questo problema lo standard ISO C99\footnote{alcuni sistemi che non hanno
questa macro provvedono al suo posto \macro{\_\_va\_copy} che era il nome
proposto in una bozza dello standard.} ha previsto una macro ulteriore che
Dato che l'analisi può risultare molto complessa, ed opportunamente suddivisa
in fasi diverse, la rilevazione di un errore nell'input può accadere
all'interno di funzioni profondamente annidate l'una nell'altra. In questo
-caso si dovrebbe per ciascuna fase dover gestire tutta la casistica del
-passaggio all'indietro di tutti gli errori rilevabili dalle funzioni usate
-nelle fasi successive, mentre sarebbe molto più comodo poter tornare
-direttamente al ciclo di lettura principale, scartando l'input come
-errato.\footnote{a meno che, come precisa \cite{glibc}, alla chiusura di
- ciascuna fase non siano associate operazioni di pulizia specifiche (come
- deallocazioni, chiusure di file, ecc.), che non potrebbero essere eseguite
- con un salto non-locale.}
+caso si dovrebbe gestire, per ciascuna fase, tutta la casistica del passaggio
+all'indietro di tutti gli errori rilevabili dalle funzioni usate nelle fasi
+successive, mentre sarebbe molto più comodo poter tornare direttamente al
+ciclo di lettura principale, scartando l'input come errato.\footnote{a meno
+ che, come precisa \cite{glibc}, alla chiusura di ciascuna fase non siano
+ associate operazioni di pulizia specifiche (come deallocazioni, chiusure di
+ file, ecc.), che non potrebbero essere eseguite con un salto non-locale.}
Tutto ciò può essere realizzato salvando il contesto dello stack nel punto in
cui si vuole tornare in caso di errore, e ripristinandolo quando l'occorrenza
projects / gapil.git / blobdiff