%% process.tex
%%
-%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2018 by 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 "Un preambolo",
tutte le parti uguali siano condivise), avrà un suo spazio di indirizzi,
variabili proprie e sarà eseguito in maniera completamente indipendente da
tutti gli altri. Questo non è del tutto vero nel caso di un programma
-\textit{multi-thread}, ma la gestione dei \itindex{thread} \textit{thread} in
-Linux sarà trattata a parte in cap.~\ref{cha:threads}.
+\textit{multi-thread}, ma la gestione dei \textit{thread} in Linux sarà
+trattata a parte in cap.~\ref{cha:threads}.
\subsection{L'avvio e l'esecuzione di un programma}
\label{sec:proc_main}
\itindbeg{link-loader}
-
+\itindbeg{shared~objects}
Quando un programma viene messo in esecuzione cosa che può essere fatta solo
con una funzione della famiglia \func{exec} (vedi sez.~\ref{sec:proc_exec}) il
kernel esegue un opportuno codice di avvio, il cosiddetto
compilazione, tutti i programmi in Linux sono compilati facendo riferimento a
librerie condivise, in modo da evitare di duplicare lo stesso codice nei
relativi eseguibili e consentire un uso più efficiente della memoria, dato che
-il codice di uno \itindex{shared~objects} \textit{shared objects} viene
-caricato in memoria dal kernel una sola volta per tutti i programmi che lo
-usano.
+il codice di uno \textit{shared objects} viene caricato in memoria dal kernel
+una sola volta per tutti i programmi che lo usano.
+\itindend{shared~objects}
Questo significa però che normalmente il codice di un programma è incompleto,
contenendo solo i riferimenti alle funzioni di libreria che vuole utilizzare e
& ANSI C& POSIX& \\
\hline
\hline
- \headfile{assert.h}&$\bullet$& -- & Verifica le asserzioni fatte in un
- programma.\\
- \headfile{ctype.h} &$\bullet$& -- & Tipi standard.\\
- \headfile{dirent.h}& -- &$\bullet$& Manipolazione delle directory.\\
- \headfile{errno.h} & -- &$\bullet$& Errori di sistema.\\
- \headfile{fcntl.h} & -- &$\bullet$& Controllo sulle opzioni dei file.\\
- \headfile{limits.h}& -- &$\bullet$& Limiti e parametri del sistema.\\
- \headfile{malloc.h}&$\bullet$& -- & Allocazione della memoria.\\
- \headfile{setjmp.h}&$\bullet$& -- & Salti non locali.\\
- \headfile{signal.h}& -- &$\bullet$& Gestione dei segnali.\\
- \headfile{stdarg.h}&$\bullet$& -- & Gestione di funzioni a argomenti
+ \headfiled{assert.h}&$\bullet$& -- & Verifica le asserzioni fatte in un
+ programma.\\
+ \headfiled{ctype.h} &$\bullet$& -- & Tipi standard.\\
+ \headfiled{dirent.h}& -- &$\bullet$& Manipolazione delle directory.\\
+ \headfiled{errno.h} & -- &$\bullet$& Errori di sistema.\\
+ \headfiled{fcntl.h} & -- &$\bullet$& Controllo sulle opzioni dei
+ file.\\
+ \headfiled{limits.h}& -- &$\bullet$& Limiti e parametri del sistema.\\
+ \headfiled{malloc.h}&$\bullet$& -- & Allocazione della memoria.\\
+ \headfiled{setjmp.h}&$\bullet$& -- & Salti non locali.\\
+ \headfiled{signal.h}& -- &$\bullet$& Gestione dei segnali.\\
+ \headfiled{stdarg.h}&$\bullet$& -- & Gestione di funzioni a argomenti
variabili.\\
- \headfile{stdio.h} &$\bullet$& -- & I/O bufferizzato in standard ANSI
- C.\\
- \headfile{stdlib.h}&$\bullet$& -- & Definizioni della libreria
- standard.\\
- \headfile{string.h}&$\bullet$& -- & Manipolazione delle stringhe.\\
- \headfile{time.h} & -- &$\bullet$& Gestione dei tempi.\\
- \headfile{times.h} &$\bullet$& -- & Gestione dei tempi.\\
- \headfile{unistd.h}& -- &$\bullet$& Unix standard library.\\
- \headfile{utmp.h} & -- &$\bullet$& Registro connessioni utenti.\\
+ \headfiled{stdio.h} &$\bullet$& -- & I/O bufferizzato in standard ANSI
+ C.\\
+ \headfiled{stdlib.h}&$\bullet$& -- & Definizioni della libreria
+ standard.\\
+ \headfiled{string.h}&$\bullet$& -- & Manipolazione delle stringhe.\\
+ \headfiled{time.h} & -- &$\bullet$& Gestione dei tempi.\\
+ \headfiled{times.h} &$\bullet$& -- & Gestione dei tempi.\\
+ \headfiled{unistd.h}& -- &$\bullet$& Unix standard library.\\
+ \headfiled{utmp.h} & -- &$\bullet$& Registro connessioni utenti.\\
\hline
\end{tabular}
\caption{Elenco dei principali \textit{header file} definiti dagli standard
esempio, è il seguente, e si noti come gli \textit{header file} possano essere
referenziati con il nome fra parentesi angolari, nel qual caso si indica l'uso
di quelli installati con il sistema,\footnote{in un sistema GNU/Linux che
- segue le specifiche del \itindex{Filesystem~Hierarchy~Standard~(FHS)}
- \textit{Filesystem Hierarchy Standard} (per maggiori informazioni si
- consulti sez.~1.2.3 di \cite{AGL}) si trovano sotto \texttt{/usr/include}.}
-o fra virgolette, nel qual caso si fa riferimento ad una versione locale, da
-indicare con un \itindsub{pathname}{relativo} \textit{pathname} relativo:
+ segue le specifiche del \textit{Filesystem Hierarchy Standard} (per maggiori
+ informazioni si consulti sez.~1.2.3 di \cite{AGL}) si trovano sotto
+ \texttt{/usr/include}.} o fra virgolette, nel qual caso si fa riferimento
+ad una versione locale, da indicare con un \textit{pathname} relativo:
\includecodesnip{listati/main_include.c}
Si tenga presente che oltre ai nomi riservati a livello generale di cui si è
``\texttt{TC}'' e con ``\texttt{B}'' seguito da un numero,
\item in \headfile{grp.h} vengono riservati i nomi che iniziano con
``\texttt{gr\_}'',
-\item in \headfile{pwd.h}vengono riservati i nomi che iniziano con
+\item in \headfile{pwd.h} vengono riservati i nomi che iniziano con
``\texttt{pw\_}'',
\end{itemize*}
% http://davisdoesdownunder.blogspot.com/2011/02/linux-syscall-vsyscall-and-vdso-oh-my.html
% http://www.win.tue.nl/~aeb/linux/lk/lk-4.html
%
+% Altro materiale al riguardo http://lwn.net/Articles/615809/
+% http://man7.org/linux/man-pages/man7/vdso.7.html
Inoltre alcune \textit{system call} sono state modificate nel corso degli anni
con lo sviluppo del kernel per aggiungere ad esempio funzionalità in forma di
ciascuna \textit{system call} viene in genere identificata da una costante
nella forma \texttt{SYS\_*} dove al prefisso viene aggiunto il nome che spesso
corrisponde anche alla omonima funzione di libreria. Queste costanti sono
-definite nel file \headfile{sys/syscall.h}, ma si possono anche usare
+definite nel file \headfiled{sys/syscall.h}, ma si possono anche usare
direttamente valori numerici.
verrebbe interpretato come un successo.
Per questo motivo in \headfile{stdlib.h} sono definite, seguendo lo standard
-POSIX, le due costanti \const{EXIT\_SUCCESS} e \const{EXIT\_FAILURE}, da usare
-sempre per specificare lo stato di uscita di un processo. Su Linux, ed in
-generale in qualunque sistema POSIX, ad esse sono assegnati rispettivamente i
-valori 0 e 1.
+POSIX, le due costanti \constd{EXIT\_SUCCESS} e \constd{EXIT\_FAILURE}, da
+usare sempre per specificare lo stato di uscita di un processo. Su Linux, ed
+in generale in qualunque sistema POSIX, ad esse sono assegnati rispettivamente
+i valori 0 e 1.
\itindend{exit~status}
programma. A questo scopo lo standard ANSI C prevede la possibilità di
registrare un certo numero di funzioni che verranno eseguite all'uscita dal
programma,\footnote{nel caso di \func{atexit} lo standard POSIX.1-2001
- richiede che siano registrabili almeno \const{ATEXIT\_MAX} funzioni (il
+ richiede che siano registrabili almeno \constd{ATEXIT\_MAX} funzioni (il
valore può essere ottenuto con \func{sysconf}, vedi
sez.~\ref{sec:sys_limits}).} sia per la chiamata ad \func{exit} che per il
ritorno di \code{main}. La prima funzione che si può utilizzare a tal fine è
\subsection{I concetti generali}
\label{sec:proc_mem_gen}
+\index{memoria~virtuale|(}
+
Ci sono vari modi in cui i sistemi operativi organizzano la memoria, ed i
dettagli di basso livello dipendono spesso in maniera diretta
dall'architettura dell'hardware, ma quello più tipico, usato dai sistemi
-unix-like come Linux è la cosiddetta \index{memoria~virtuale} \textsl{memoria
- virtuale} che consiste nell'assegnare ad ogni processo uno spazio virtuale
-di indirizzamento lineare, in cui gli indirizzi vanno da zero ad un qualche
-valore massimo.\footnote{nel caso di Linux fino al kernel 2.2 detto massimo
- era, per macchine a 32bit, di 2Gb. Con il kernel 2.4 ed il supporto per la
- \textit{high-memory} il limite è stato esteso anche per macchine a 32 bit.}
-
-
-Come accennato nel cap.~\ref{cha:intro_unix} questo spazio di indirizzi è
-virtuale e non corrisponde all'effettiva posizione dei dati nella RAM del
-computer. In generale detto spazio non è neppure continuo, cioè non tutti gli
-indirizzi possibili sono utilizzabili, e quelli usabili non sono
-necessariamente adiacenti.
+unix-like come Linux è la cosiddetta \textsl{memoria virtuale} che consiste
+nell'assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare,
+in cui gli indirizzi vanno da zero ad un qualche valore massimo.\footnote{nel
+ caso di Linux fino al kernel 2.2 detto massimo era, per macchine a 32bit, di
+ 2Gb. Con il kernel 2.4 ed il supporto per la \textit{high-memory} il limite
+ è stato esteso anche per macchine a 32 bit.} Come accennato nel
+cap.~\ref{cha:intro_unix} questo spazio di indirizzi è virtuale e non
+corrisponde all'effettiva posizione dei dati nella RAM del computer. In
+generale detto spazio non è neppure continuo, cioè non tutti gli indirizzi
+possibili sono utilizzabili, e quelli usabili non sono necessariamente
+adiacenti.
+
+\itindbeg{huge~page}
Per la gestione da parte del kernel la memoria viene divisa in pagine di
dimensione fissa. Inizialmente queste pagine erano di 4kb sulle macchine a 32
anche utilizzare pagine di dimensioni maggiori (di 4Mb, dette \textit{huge
page}), per sistemi con grandi quantitativi di memoria in cui l'uso di
pagine troppo piccole comporta una perdita di prestazioni. In alcuni sistemi
-la costante \const{PAGE\_SIZE}, definita in \headfile{limits.h}, indica la
+la costante \constd{PAGE\_SIZE}, definita in \headfile{limits.h}, indica la
dimensione di una pagina in byte, con Linux questo non avviene e per ottenere
questa dimensione si deve ricorrere alla funzione \func{getpagesize} (vedi
sez.~\ref{sec:sys_memory_res}).
+\itindend{huge~page}
+\itindbeg{page~table}
+
Ciascuna pagina di memoria nello spazio di indirizzi virtuale è associata ad
un supporto che può essere una pagina di memoria reale o ad un dispositivo di
stoccaggio secondario (come lo spazio disco riservato alla \textit{swap}, o i
file che contengono il codice). Per ciascun processo il kernel si cura di
-mantenere un mappa di queste corrispondenze nella cosiddetta
-\itindex{page~table} \textit{page table}.\footnote{questa è una
- semplificazione brutale, il meccanismo è molto più complesso; una buona
- trattazione di come Linux gestisce la memoria virtuale si trova su
- \cite{LinVM}.}
+mantenere un mappa di queste corrispondenze nella cosiddetta \textit{page
+ table}.\footnote{questa è una semplificazione brutale, il meccanismo è molto
+ più complesso; una buona trattazione di come Linux gestisce la memoria
+ virtuale si trova su \cite{LinVM}.}
+
+\itindend{page~table}
Una stessa pagina di memoria reale può fare da supporto a diverse pagine di
memoria virtuale appartenenti a processi diversi, come accade in genere per le
farà da supporto a tutte le pagine di memoria virtuale di tutti i processi che
hanno detta funzione nel loro codice.
-La corrispondenza fra le pagine della \index{memoria~virtuale} memoria
-virtuale di un processo e quelle della memoria fisica della macchina viene
-gestita in maniera trasparente dal kernel.\footnote{in genere con l'ausilio
- dell'hardware di gestione della memoria (la \textit{Memory Management Unit}
- del processore), con i kernel della serie 2.6 è comunque diventato possibile
- utilizzare Linux anche su architetture che non dispongono di una MMU.}
-Poiché in genere la memoria fisica è solo una piccola frazione della memoria
-virtuale, è necessario un meccanismo che permetta di trasferire le pagine che
-servono dal supporto su cui si trovano in memoria, eliminando quelle che non
-servono. Questo meccanismo è detto \index{paginazione} \textsl{paginazione}
-(o \textit{paging}), ed è uno dei compiti principali del kernel.
+\index{paginazione|(}
+
+La corrispondenza fra le pagine della memoria virtuale di un processo e quelle
+della memoria fisica della macchina viene gestita in maniera trasparente dal
+kernel.\footnote{in genere con l'ausilio dell'hardware di gestione della
+ memoria (la \textit{Memory Management Unit} del processore), con i kernel
+ della serie 2.6 è comunque diventato possibile utilizzare Linux anche su
+ architetture che non dispongono di una MMU.} Poiché in genere la memoria
+fisica è solo una piccola frazione della memoria virtuale, è necessario un
+meccanismo che permetta di trasferire le pagine che servono dal supporto su
+cui si trovano in memoria, eliminando quelle che non servono. Questo
+meccanismo è detto \textsl{paginazione} (o \textit{paging}), ed è uno dei
+compiti principali del kernel.
+
+\itindbeg{page~fault}
Quando un processo cerca di accedere ad una pagina che non è nella memoria
-reale, avviene quello che viene chiamato un \itindex{page~fault} \textit{page
- fault}; la gestione della memoria genera un'interruzione e passa il
-controllo al kernel il quale sospende il processo e si incarica di mettere in
-RAM la pagina richiesta, effettuando tutte le operazioni necessarie per
-reperire lo spazio necessario, per poi restituire il controllo al processo.
+reale, avviene quello che viene chiamato un \textit{page fault}; la gestione
+della memoria genera un'interruzione e passa il controllo al kernel il quale
+sospende il processo e si incarica di mettere in RAM la pagina richiesta,
+effettuando tutte le operazioni necessarie per reperire lo spazio necessario,
+per poi restituire il controllo al processo.
Dal punto di vista di un processo questo meccanismo è completamente
trasparente, e tutto avviene come se tutte le pagine fossero sempre
dovuti all'intervento del kernel, qualora sia necessario reperire pagine
riposte nella \textit{swap}.
+\itindend{page~fault}
+
Normalmente questo è il prezzo da pagare per avere un multitasking reale, ed
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 \index{paginazione} paginazione e
-mantenere fisse delle pagine in memoria (vedi sez.~\ref{sec:proc_mem_lock}).
+permettono di bloccare il meccanismo della paginazione e mantenere fisse delle
+pagine in memoria (vedi sez.~\ref{sec:proc_mem_lock}).
+
+\index{paginazione|)}
+\index{memoria~virtuale|)}
\subsection{La struttura della memoria di un processo}
\label{sec:proc_mem_layout}
+\itindbeg{segment~violation}
+
Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
commette quando si è manipolato male un puntatore e genera quella che viene
-chiamata una \itindex{segment~violation} \textit{segment violation}. Se si
-tenta cioè di leggere o scrivere con un indirizzo per il quale non esiste
-un'associazione nella memoria virtuale, il kernel risponde al relativo
-\itindex{page~fault} \textit{page fault} mandando un segnale \signal{SIGSEGV}
-al processo, che normalmente ne causa la terminazione immediata.
-
-È pertanto importante capire come viene strutturata \index{memoria~virtuale}
-la memoria virtuale di un processo. Essa viene divisa in \textsl{segmenti},
-cioè un insieme contiguo di indirizzi virtuali ai quali il processo può
-accedere. Solitamente un programma C viene suddiviso nei seguenti segmenti:
-\begin{enumerate*}
-\item Il \index{segmento!testo} segmento di testo o \textit{text segment}.
- Contiene il codice del programma, delle funzioni di librerie da esso
- utilizzate, e le costanti. Normalmente viene condiviso fra tutti i processi
- che eseguono lo stesso programma e nel caso delle librerie anche da processi
- che eseguono altri programmi.
+chiamata una \textit{segment violation}. Se si tenta cioè di leggere o
+scrivere con un indirizzo per il quale non esiste un'associazione nella
+memoria virtuale, il kernel risponde al relativo \textit{page fault} mandando
+un segnale \signal{SIGSEGV} al processo, che normalmente ne causa la
+terminazione immediata.
+
+\itindend{segment~violation}
+
+È pertanto importante capire come viene strutturata la memoria virtuale di un
+processo. Essa viene divisa in \textsl{segmenti}, cioè un insieme contiguo di
+indirizzi virtuali ai quali il processo può accedere. Solitamente un
+programma C viene suddiviso nei seguenti segmenti:
+\index{segmento!testo|(}
+\index{segmento!dati|(}
+\itindbeg{heap}
+\itindbeg{stack}
+\begin{enumerate}
+\item Il \textsl{segmento di testo} o \textit{text segment}. Contiene il
+ codice del programma, delle funzioni di librerie da esso utilizzate, e le
+ costanti. Normalmente viene condiviso fra tutti i processi che eseguono lo
+ stesso programma e nel caso delle librerie anche da processi che eseguono
+ altri programmi.
Quando l'architettura hardware lo supporta viene marcato in sola lettura per
evitare sovrascritture accidentali (o maliziose) che ne modifichino le
istruzioni. Viene allocato da \func{execve} all'avvio del programma e resta
invariato per tutto il tempo dell'esecuzione.
-
-\item Il \index{segmento!dati} segmento dei dati o \textit{data
- segment}. Contiene tutti i dati del programma, come le
- \index{variabili!globali} variabili globali, cioè quelle definite al di
- fuori di tutte le funzioni che compongono il programma, e le
- \index{variabili!statiche} variabili statiche, cioè quelle dichiarate con
- l'attributo \direct{static},\footnote{la direttiva \direct{static} indica al
- compilatore C che una variabile così dichiarata all'interno di una
- funzione deve essere mantenuta staticamente in memoria (nel
- \index{segmento!dati} segmento dati appunto); questo significa che la
- variabile verrà inizializzata una sola volta alla prima invocazione della
- funzione e che il suo valore sarà mantenuto fra diverse esecuzioni della
- funzione stessa, la differenza con una \index{variabili!globali} variabile
+\index{variabili!globali|(}
+\index{variabili!statiche|(}
+\item Il \textsl{segmento dei dati} o \textit{data segment}. Contiene tutti i
+ dati del programma, come le \textsl{variabili globali}, cioè quelle definite
+ al di fuori di tutte le funzioni che compongono il programma, e le
+ \textsl{variabili statiche}, cioè quelle dichiarate con l'attributo
+ \direct{static},\footnote{la direttiva \direct{static} indica al compilatore
+ C che una variabile così dichiarata all'interno di una funzione deve
+ essere mantenuta staticamente in memoria (nel segmento dati appunto);
+ questo significa che la variabile verrà inizializzata una sola volta alla
+ prima invocazione della funzione e che il suo valore sarà mantenuto fra
+ diverse esecuzioni della funzione stessa, la differenza con una variabile
globale è che essa può essere vista solo all'interno della funzione in cui
è dichiarata.} e la memoria allocata dinamicamente. Di norma è diviso in
tre parti:
-
- \begin{itemize*}
+ \begin{itemize}
\item Il segmento dei dati inizializzati, che contiene le variabili il cui
valore è stato assegnato esplicitamente. Ad esempio se si definisce:
\includecodesnip{listati/pi.c}
questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
allocato all'avvio, e tutte le variabili vengono inizializzate a zero (ed
i puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
- variabili che vanno nel \index{segmento!dati} segmento dati, e non è
- affatto vero in generale.} Storicamente questa seconda parte del
- \index{segmento!dati} segmento dati viene chiamata BSS (da \textit{Block
+ variabili che vanno nel segmento dati, e non è affatto vero in
+ generale.} Storicamente questa seconda parte del segmento dati viene
+ chiamata \itindex{Block~Started~by~Symbol~(BSS)} BSS (da \textit{Block
Started by Symbol}). La sua dimensione è fissa.
- \item Lo \itindex{heap} \textit{heap}, detto anche \textit{free
- store}. Tecnicamente lo si può considerare l'estensione del segmento dei
- dati non inizializzati, a cui di solito è posto giusto di seguito. Questo
- è il segmento che viene utilizzato per l'allocazione dinamica della
- memoria. Lo \textit{heap} può essere ridimensionato allargandolo e
- restringendolo per allocare e disallocare la memoria dinamica con le
- apposite funzioni (vedi sez.~\ref{sec:proc_mem_alloc}), ma il suo limite
- inferiore, quello adiacente al segmento dei dati non inizializzati, ha una
- posizione fissa.
- \end{itemize*}
-
-\item Il segmento di \itindex{stack} \textit{stack}, che contiene quello che
- viene chiamato \textit{stack} del programma. Tutte le volte che si effettua
- una chiamata ad una funzione è qui che viene salvato l'indirizzo di ritorno
- e le informazioni dello stato del chiamante (come il contenuto di alcuni
- registri della CPU), poi la funzione chiamata alloca qui lo spazio per le
- sue variabili locali. Tutti questi dati vengono \textit{impilati} (da questo
- viene il nome \itindex{stack} \textit{stack}) in sequenza uno sull'altro; in
- questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
- della funzione lo spazio è automaticamente rilasciato e
- ``\textsl{ripulito}''.\footnote{il compilatore si incarica di generare
- automaticamente il codice necessario, seguendo quella che viene chiamata
- una \textit{calling convention}; quella standard usata con il C ed il C++
- è detta \textit{cdecl} e prevede che gli argomenti siano caricati nello
- \textit{stack} dal chiamante da destra a sinistra, e che sia il chiamante
- stesso ad eseguire la ripulitura dello \textit{stack} al ritorno della
- funzione, se ne possono però utilizzare di alternative (ad esempio nel
- Pascal gli argomenti sono inseriti da sinistra a destra ed è compito del
- chiamato ripulire lo \textit{stack}), in genere non ci si deve preoccupare
- di questo fintanto che non si mescolano funzioni scritte con linguaggi
- diversi.}
+ \index{variabili!globali|)} \index{variabili!statiche|)}
+ \item Lo \textit{heap}, detto anche \textit{free store}. Tecnicamente lo si
+ può considerare l'estensione del segmento dei dati non inizializzati, a
+ cui di solito è posto giusto di seguito. Questo è il segmento che viene
+ utilizzato per l'allocazione dinamica della memoria. Lo \textit{heap} può
+ essere ridimensionato allargandolo e restringendolo per allocare e
+ disallocare la memoria dinamica con le apposite funzioni (vedi
+ sez.~\ref{sec:proc_mem_alloc}), ma il suo limite inferiore, quello
+ adiacente al segmento dei dati non inizializzati, ha una posizione fissa.
+ \end{itemize}
+\item Il segmento di \textit{stack}, che contiene quello che viene chiamato lo
+ ``\textit{stack}'' del programma. Tutte le volte che si effettua una
+ chiamata ad una funzione è qui che viene salvato l'indirizzo di ritorno e le
+ informazioni dello stato del chiamante (come il contenuto di alcuni registri
+ della CPU), poi la funzione chiamata alloca qui lo spazio per le sue
+ variabili locali. Tutti questi dati vengono \textit{impilati} (da questo
+ viene il nome \textit{stack}) in sequenza uno sull'altro; in questo modo le
+ funzioni possono essere chiamate ricorsivamente. Al ritorno della funzione
+ lo spazio è automaticamente rilasciato e ``\textsl{ripulito}''.\footnote{il
+ compilatore si incarica di generare automaticamente il codice necessario,
+ seguendo quella che viene chiamata una \textit{calling convention}; quella
+ standard usata con il C ed il C++ è detta \textit{cdecl} e prevede che gli
+ argomenti siano caricati nello \textit{stack} dal chiamante da destra a
+ sinistra, e che sia il chiamante stesso ad eseguire la ripulitura dello
+ \textit{stack} al ritorno della funzione, se ne possono però utilizzare di
+ alternative (ad esempio nel Pascal gli argomenti sono inseriti da sinistra
+ a destra ed è compito del chiamato ripulire lo \textit{stack}), in genere
+ non ci si deve preoccupare di questo fintanto che non si mescolano
+ funzioni scritte con linguaggi diversi.}
La dimensione di questo segmento aumenta seguendo la crescita dello
- \itindex{stack} \textit{stack} del programma, ma non viene ridotta quando
- quest'ultimo si restringe.
-\end{enumerate*}
+ \textit{stack} del programma, ma non viene ridotta quando quest'ultimo si
+ restringe.
+\end{enumerate}
\begin{figure}[htb]
\centering
\end{figure}
Una disposizione tipica dei vari segmenti (testo, dati inizializzati e non
-inizializzati, \itindex{heap} \textit{heap}, \itindex{stack} \textit{stack},
-ecc.) è riportata in fig.~\ref{fig:proc_mem_layout}. Si noti come in figura
-sia indicata una ulteriore regione, marcata \textit{environment}, che è quella
-che contiene i dati relativi alle variabili di ambiente passate al programma
-al suo avvio (torneremo su questo argomento in sez.~\ref{sec:proc_environ}).
+inizializzati, \textit{heap}, \textit{stack}, ecc.) è riportata in
+fig.~\ref{fig:proc_mem_layout}. Si noti come in figura sia indicata una
+ulteriore regione, marcata \textit{environment}, che è quella che contiene i
+dati relativi alle variabili di ambiente passate al programma al suo avvio
+(torneremo su questo argomento in sez.~\ref{sec:proc_environ}).
Usando il comando \cmd{size} su un programma se ne può stampare le dimensioni
-dei \index{segmento!testo} segmenti di testo e \index{segmento!dati} di dati
-(solo però per i dati inizializzati ed il BSS, dato che lo \itindex{heap}
-\textit{heap} ha una dimensione dinamica). Si tenga presente comunque che il
-BSS, contrariamente al segmento dei dati inizializzati, non è mai salvato sul
-file che contiene l'eseguibile, dato che viene sempre inizializzato a zero al
-caricamento del programma.
+dei segmenti di testo e di dati (solo però per i dati inizializzati ed il BSS,
+dato che lo \textit{heap} ha una dimensione dinamica). Si tenga presente
+comunque che il BSS, contrariamente al segmento dei dati inizializzati, non è
+mai salvato sul file che contiene l'eseguibile, dato che viene sempre
+inizializzato a zero al caricamento del programma.
+
+\index{segmento!testo|)}
+\index{segmento!dati|)}
+\itindend{heap}
+\itindend{stack}
\subsection{Allocazione della memoria per i programmi C}
modalità di allocazione della memoria: l'\textsl{allocazione statica} e
l'\textsl{allocazione automatica}.
-L'\textsl{allocazione statica} è quella con cui sono memorizzate le
-\index{variabili!globali} variabili globali e le \index{variabili!statiche}
-variabili statiche, cioè le variabili il cui valore deve essere mantenuto per
-tutta la durata del programma. Come accennato queste variabili vengono
-allocate nel \index{segmento!dati} segmento dei dati all'avvio del programma
-come parte delle operazioni svolte da \func{exec}, e lo spazio da loro
-occupato non viene liberato fino alla sua conclusione.
+L'\textsl{allocazione statica} è quella con cui sono memorizzate le variabili
+globali e le variabili statiche, cioè le variabili il cui valore deve essere
+mantenuto per tutta la durata del programma. Come accennato queste variabili
+vengono allocate nel segmento dei dati all'avvio del programma come parte
+delle operazioni svolte da \func{exec}, e lo spazio da loro occupato non viene
+liberato fino alla sua conclusione.
+
+\index{variabili!automatiche|(}
L'\textsl{allocazione automatica} è quella che avviene per gli argomenti di
una funzione e per le sue variabili locali, quelle che vengono definite
-all'interno della funzione che esistono solo per la durata della sua esecuzione
-e che per questo vengono anche dette \index{variabili!automatiche}
-\textsl{variabili automatiche}. Lo spazio per queste variabili viene allocato
-nello \itindex{stack} \textit{stack} quando viene eseguita la funzione e
-liberato quando si esce dalla medesima.
+all'interno della funzione che esistono solo per la durata della sua
+esecuzione e che per questo vengono anche dette \textsl{variabili
+ automatiche}. Lo spazio per queste variabili viene allocato nello
+\textit{stack} quando viene eseguita la funzione e liberato quando si esce
+dalla medesima.
+
+\index{variabili!automatiche|)}
Esiste però un terzo tipo di allocazione, l'\textsl{allocazione dinamica}
della memoria, che non è prevista direttamente all'interno del linguaggio C,
essere modificate durante l'esecuzione del programma. Per questo la libreria
standard del C fornisce una opportuna serie di funzioni per eseguire
l'allocazione dinamica di memoria, che come accennato avviene nello
-\itindex{heap} \textit{heap}.
+\textit{heap}.
Le variabili il cui contenuto è allocato in questo modo non potranno essere
-usate direttamente come le altre (quelle nello \itindex{stack}
-\textit{stack}), ma l'accesso sarà possibile solo in maniera indiretta,
-attraverso i puntatori alla memoria loro riservata che si sono ottenuti dalle
-funzioni di allocazione.
+usate direttamente come le altre (quelle nello \textit{stack}), ma l'accesso
+sarà possibile solo in maniera indiretta, attraverso i puntatori alla memoria
+loro riservata che si sono ottenuti dalle funzioni di allocazione.
Le funzioni previste dallo standard ANSI C per la gestione della memoria sono
quattro: \func{malloc}, \func{calloc}, \func{realloc} e \func{free}. Le prime
esempio un \textit{segmentation fault} in una successiva chiamata di una di
queste funzioni.
-Dato che questo errore, chiamato in gergo \itindex{double~free} \textit{double
- free}, è abbastanza frequente, specie quando si manipolano vettori di
-puntatori, e dato che le conseguenze possono essere pesanti ed inaspettate, si
-suggerisce come soluzione precauzionale di assegnare sempre a \val{NULL} ogni
-puntatore su cui sia stata eseguita \func{free} immediatamente dopo
-l'esecuzione della funzione. In questo modo, dato che con un puntatore nullo
-\func{free} non esegue nessuna operazione, si evitano i problemi del
-\itindex{double~free} \textit{double free}.
+\itindbeg{double~free}
+
+Dato che questo errore, chiamato in gergo \textit{double free}, è abbastanza
+frequente, specie quando si manipolano vettori di puntatori, e dato che le
+conseguenze possono essere pesanti ed inaspettate, si suggerisce come
+soluzione precauzionale di assegnare sempre a \val{NULL} ogni puntatore su cui
+sia stata eseguita \func{free} immediatamente dopo l'esecuzione della
+funzione. In questo modo, dato che con un puntatore nullo \func{free} non
+esegue nessuna operazione, si evitano i problemi del \textit{double free}.
+
+\itindend{double~free}
Infine la funzione \funcd{realloc} consente di modificare, in genere di
aumentare, la dimensione di un'area di memoria precedentemente allocata; il
questo tipo di errori usando la variabile di ambiente \envvar{MALLOC\_CHECK\_}
che quando viene definita mette in uso una versione meno efficiente delle
funzioni suddette, che però è più tollerante nei confronti di piccoli errori
-come quello dei \itindex{double~free} \textit{double~free} o i
-\itindex{buffer~overrun} \textit{buffer overrun} di un byte.\footnote{uno
- degli errori più comuni, causato ad esempio dalla scrittura di una stringa
- di dimensione pari a quella del buffer, in cui ci si dimentica dello zero di
- terminazione finale.} In particolare:
+come quello dei \textit{double free} o i \textit{buffer overrun} di un
+byte.\footnote{uno degli errori più comuni, causato ad esempio dalla scrittura
+ di una stringa di dimensione pari a quella del buffer, in cui ci si
+ dimentica dello zero di terminazione finale.} In particolare:
\begin{itemize*}
\item se la variabile è posta a $0$ gli errori vengono ignorati;
\item se la variabile è posta a $1$ viene stampato un avviso sullo
\func{abort}.
\end{itemize*}
+\itindbeg{memory~leak}
+
L'errore di programmazione più comune e più difficile da risolvere che si
incontra con le funzioni di allocazione è quando non viene opportunamente
liberata la memoria non più utilizzata, quello che in inglese viene chiamato
-\itindex{memory~leak} \textit{memory leak}, cioè una \textsl{perdita di
- memoria}.
+\textit{memory leak}, cioè una \textsl{perdita di memoria}.
Un caso tipico che illustra il problema è quello in cui in una propria
funzione si alloca della memoria per uso locale senza liberarla prima di
momento, in corrispondenza ad una qualunque chiamata di \func{malloc} che può
essere in una sezione del codice che non ha alcuna relazione con la funzione
che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
-\itindex{memory~leak} \textit{memory leak}.
-
-In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
-programmazione ad oggetti, il problema dei \itindex{memory~leak}
-\textit{memory leak} si può notevolmente ridimensionare attraverso l'uso
-accurato di appositi oggetti come gli \textit{smartpointers}. Questo però in
-genere va a scapito delle prestazioni dell'applicazione in esecuzione.
-
-% TODO decidere cosa fare di questo che segue
-% In altri linguaggi come il java e recentemente il C\# il problema non si pone
-% nemmeno perché la gestione della memoria viene fatta totalmente in maniera
-% automatica, ovvero il programmatore non deve minimamente preoccuparsi di
-% liberare la memoria allocata precedentemente quando non serve più, poiché
-% l'infrastruttura del linguaggio gestisce automaticamente la cosiddetta
-% \index{\textit{garbage~collection}} \textit{garbage collection}. In tal caso,
-% attraverso meccanismi simili a quelli del \textit{reference counting}, quando
-% una zona di memoria precedentemente allocata non è più riferita da nessuna
-% parte del codice in esecuzione, può essere deallocata automaticamente in
-% qualunque momento dall'infrastruttura.
+\textit{memory leak}. In C e C++ il problema è particolarmente sentito. In
+C++, per mezzo della programmazione ad oggetti, il problema dei \textit{memory
+ leak} si può notevolmente ridimensionare attraverso l'uso accurato di
+appositi oggetti come gli \textit{smartpointers}. Questo però in genere va a
+scapito delle prestazioni dell'applicazione in esecuzione.
+
+% TODO decidere cosa fare di questo che segue In altri linguaggi come il java
+% e recentemente il C\# il problema non si pone nemmeno perché la gestione
+% della memoria viene fatta totalmente in maniera automatica, ovvero il
+% programmatore non deve minimamente preoccuparsi di liberare la memoria
+% allocata precedentemente quando non serve più, poiché l'infrastruttura del
+% linguaggio gestisce automaticamente la cosiddetta
+% \itindex{garbage~collection} \textit{garbage collection}. In tal caso,
+% attraverso meccanismi simili a quelli del \textit{reference counting},
+% quando una zona di memoria precedentemente allocata non è più riferita da
+% nessuna parte del codice in esecuzione, può essere deallocata
+% automaticamente in qualunque momento dall'infrastruttura.
% Anche questo va a scapito delle prestazioni dell'applicazione in esecuzione
% (inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
l'allocazione della memoria. Vedremo alcune delle funzionalità di ausilio
presenti nella \acr{glibc} in sez.~\ref{sec:proc_memory_adv_management}.
+\itindend{memory~leak}
+
Una possibile alternativa all'uso di \func{malloc}, per evitare di soffrire
-dei problemi di \itindex{memory~leak} \textit{memory leak} descritti in
-precedenza, è di allocare la memoria nel segmento di \itindex{stack}
-\textit{stack} della funzione corrente invece che nello \itindex{heap}
-\textit{heap}. Per farlo si può usare la funzione \funcd{alloca}, la cui
+dei problemi di \textit{memory leak} descritti in precedenza, è di allocare la
+memoria nel segmento di \textit{stack} della funzione corrente invece che
+nello \textit{heap}. Per farlo si può usare la funzione \funcd{alloca}, la cui
sintassi è identica a quella di \func{malloc}; il suo prototipo è:
\begin{funcproto}{
\end{funcproto}
La funzione alloca la quantità di memoria (non inizializzata) richiesta
-dall'argomento \param{size} nel segmento di \itindex{stack} \textit{stack}
-della funzione chiamante. Con questa funzione non è più necessario liberare
-la memoria allocata, e quindi non esiste un analogo della \func{free}, in
-quanto essa viene rilasciata automaticamente al ritorno della funzione.
+dall'argomento \param{size} nel segmento di \textit{stack} della funzione
+chiamante. Con questa funzione non è più necessario liberare la memoria
+allocata, e quindi non esiste un analogo della \func{free}, in quanto essa
+viene rilasciata automaticamente al ritorno della funzione.
Come è evidente questa funzione ha alcuni vantaggi interessanti, anzitutto
-permette di evitare alla radice i problemi di \itindex{memory~leak}
-\textit{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 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 pool di memoria da riservare e si
-evitano così anche i problemi di frammentazione di quest'ultimo, che
-comportano inefficienze sia nell'allocazione della memoria che nell'esecuzione
-dell'allocazione.
+permette di evitare alla radice i problemi di \textit{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 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 pool di
+memoria da riservare e si evitano così anche i problemi di frammentazione di
+quest'ultimo, che comportano inefficienze sia nell'allocazione della memoria
+che nell'esecuzione dell'allocazione.
Gli svantaggi sono che questa funzione non è disponibile su tutti gli Unix, e
non è inserita né nello standard POSIX né in SUSv3 (ma è presente in BSD), il
suo utilizzo quindi limita la portabilità dei programmi. Inoltre la funzione
non può essere usata nella lista degli argomenti di una funzione, perché lo
-spazio verrebbe allocato nel mezzo degli stessi. Inoltre non è chiaramente
+spazio verrebbe allocato nel mezzo degli stessi. Inoltre non è chiaramente
possibile usare \func{alloca} per allocare memoria che deve poi essere usata
anche al di fuori della funzione in cui essa viene 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 \index{variabili!automatiche} variabili
-automatiche, su cui torneremo in sez.~\ref{sec:proc_var_passing}.
+problema che si può avere con le variabili automatiche, su cui torneremo in
+sez.~\ref{sec:proc_var_passing}.
Infine non esiste un modo di sapere se l'allocazione ha avuto successo, la
funzione infatti viene realizzata inserendo del codice \textit{inline} nel
programma\footnote{questo comporta anche il fatto che non è possibile
sostituirla con una propria versione o modificarne il comportamento
collegando il proprio programma con un'altra libreria.} che si limita a
-modificare il puntatore nello \itindex{stack} \textit{stack} e non c'è modo di
-sapere se se ne sono superate le dimensioni, per cui in caso di fallimento
-nell'allocazione il comportamento del programma può risultare indefinito,
-dando luogo ad una \itindex{segment~violation} \textit{segment violation} la
-prima volta che cercherà di accedere alla memoria non effettivamente
-disponibile.
-
+modificare il puntatore nello \textit{stack} e non c'è modo di sapere se se ne
+sono superate le dimensioni, per cui in caso di fallimento nell'allocazione il
+comportamento del programma può risultare indefinito, dando luogo ad una
+\textit{segment violation} la prima volta che cercherà di accedere alla
+memoria non effettivamente disponibile.
\index{segmento!dati|(}
-
-Le due funzioni seguenti\footnote{le due funzioni sono state definite con BSD
- 4.3, sono marcate obsolete in SUSv2 e non fanno parte delle librerie
- standard del C e mentre sono state esplicitamente rimosse dallo standard
- POSIX.1-2001.} vengono utilizzate soltanto quando è necessario effettuare
-direttamente la gestione della memoria associata allo spazio dati di un
-processo, per poterle utilizzare è necessario definire una della macro di
-funzionalità (vedi sez.~\ref{sec:intro_gcc_glibc_std}) fra
-\macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE} (ad un
-valore maggiore o uguale di 500). La prima funzione è \funcd{brk}, ed il suo
-prototipo è:
+\itindbeg{heap}
+
+Le due funzioni seguenti vengono utilizzate soltanto quando è necessario
+effettuare direttamente la gestione della memoria associata allo spazio dati
+di un processo,\footnote{le due funzioni sono state definite con BSD 4.3, sono
+ marcate obsolete in SUSv2 e non fanno parte delle librerie standard del C e
+ mentre sono state esplicitamente rimosse dallo standard POSIX.1-2001.} per
+poterle utilizzare è necessario definire una della macro di funzionalità (vedi
+sez.~\ref{sec:intro_gcc_glibc_std}) fra \macro{\_BSD\_SOURCE},
+\macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE} (ad un valore maggiore o
+uguale di 500). La prima funzione è \funcd{brk}, ed il suo prototipo è:
\begin{funcproto}{
\fhead{unistd.h}
La funzione è un'interfaccia all'omonima \textit{system call} ed imposta
l'indirizzo finale del segmento dati di un processo (più precisamente dello
-\itindex{heap} \textit{heap}) all'indirizzo specificato
-da \param{addr}. Quest'ultimo deve essere un valore ragionevole, e la
-dimensione totale non deve comunque eccedere un eventuale limite (vedi
-sez.~\ref{sec:sys_resource_limit}) imposto sulle dimensioni massime del
-segmento dati del processo.
+\textit{heap}) all'indirizzo specificato da \param{addr}. Quest'ultimo deve
+essere un valore ragionevole e la dimensione totale non deve comunque eccedere
+un eventuale limite (vedi sez.~\ref{sec:sys_resource_limit}) sulle dimensioni
+massime del segmento dati del processo.
Il valore di ritorno della funzione fa riferimento alla versione fornita dalla
\acr{glibc}, in realtà in Linux la \textit{system call} corrispondente
caso \var{errno} assumerà il valore \errcode{ENOMEM}.}
\end{funcproto}
-La funzione incrementa la dimensione dello \itindex{heap} \textit{heap} di un
-programma del valore indicato dall'argomento \param{increment}, restituendo il
-nuovo indirizzo finale dello stesso. L'argomento è definito come di tipo
-\type{intptr\_t}, ma a seconda della versione delle librerie e del sistema può
-essere indicato con una serie di tipi equivalenti come \type{ptrdiff\_t},
+La funzione incrementa la dimensione dello \textit{heap} di un programma del
+valore indicato dall'argomento \param{increment}, restituendo il nuovo
+indirizzo finale dello stesso. L'argomento è definito come di tipo
+\typed{intptr\_t}, ma a seconda della versione delle librerie e del sistema
+può essere indicato con una serie di tipi equivalenti come \type{ptrdiff\_t},
\type{ssize\_t}, \ctyp{int}. Se invocata con un valore nullo la funzione
permette di ottenere l'attuale posizione della fine del segmento dati.
allocazione standard descritte in precedenza, a meno di non voler realizzare
per proprio conto un diverso meccanismo di gestione della memoria del segmento
dati.
-
+\itindend{heap}
\index{segmento!dati|)}
dell'utilizzo corrente da parte dei vari processi.
Nell'uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il
-meccanismo della \index{paginazione} paginazione riporta in RAM, ed in maniera
-trasparente, tutte le pagine che gli occorrono; esistono però esigenze
-particolari in cui non si vuole che questo meccanismo si attivi. In generale i
-motivi per cui si possono avere di queste necessità sono due:
+meccanismo della paginazione riporta in RAM, ed in maniera trasparente, tutte
+le pagine che gli occorrono; esistono però esigenze particolari in cui non si
+vuole che questo meccanismo si attivi. In generale i motivi per cui si possono
+avere di queste necessità sono due:
\begin{itemize*}
-\item \textsl{La velocità}. Il processo della \index{paginazione} paginazione
- è trasparente solo se il programma in esecuzione non è sensibile al tempo
- che occorre a riportare la pagina in memoria; per questo motivo processi
- critici che hanno esigenze di tempo reale o tolleranze critiche nelle
- risposte (ad esempio processi che trattano campionamenti sonori) possono non
- essere in grado di sopportare le variazioni della velocità di accesso dovuta
- alla paginazione.
+\item \textsl{La velocità}. Il processo della paginazione è trasparente solo
+ se il programma in esecuzione non è sensibile al tempo che occorre a
+ riportare la pagina in memoria; per questo motivo processi critici che hanno
+ esigenze di tempo reale o tolleranze critiche nelle risposte (ad esempio
+ processi che trattano campionamenti sonori) possono non essere in grado di
+ sopportare le variazioni della velocità di accesso dovuta alla paginazione.
In certi casi poi un programmatore può conoscere meglio dell'algoritmo di
allocazione delle pagine le esigenze specifiche del suo programma e decidere
\item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro
in memoria queste possono essere portate su disco dal meccanismo della
- \index{paginazione} paginazione. Questo rende più lungo il periodo di tempo
- in cui detti segreti sono presenti in chiaro e più complessa la loro
- cancellazione: un processo infatti 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.
+ paginazione. Questo rende più lungo il periodo di tempo in cui detti segreti
+ sono presenti in chiaro e più complessa la loro cancellazione: un processo
+ infatti 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*}
Per ottenere informazioni sulle modalità in cui un programma sta usando la
che, come vedremo ora, non si sia attivato il meccanismo che forza il
mantenimento di una pagina sulla memoria.
-\itindbeg{memory~locking}
+\itindbeg{memory~locking}
-Il meccanismo che previene la \index{paginazione} paginazione di parte della
-memoria virtuale di un processo è chiamato \textit{memory locking} (o
-\textsl{blocco della memoria}). Il blocco è sempre associato alle pagine della
-memoria virtuale del processo, e non al segmento reale di RAM su cui essa
-viene mantenuta. La regola è che se un segmento di RAM fa da supporto ad
-almeno una pagina bloccata allora esso viene escluso dal meccanismo della
-\index{paginazione} paginazione. I blocchi non si accumulano, se si blocca due
-volte la stessa pagina non è necessario sbloccarla due volte, una pagina o è
-bloccata oppure no.
+Il meccanismo che previene la paginazione di parte della memoria virtuale di
+un processo è chiamato \textit{memory locking} (o \textsl{blocco della
+ memoria}). Il blocco è sempre associato alle pagine della memoria virtuale
+del processo, e non al segmento reale di RAM su cui essa viene mantenuta. La
+regola è che se un segmento di RAM fa da supporto ad almeno una pagina
+bloccata allora esso viene escluso dal meccanismo della paginazione. I blocchi
+non si accumulano, se si blocca due volte la stessa pagina non è necessario
+sbloccarla due volte, una pagina o è bloccata oppure no.
Il \textit{memory lock} persiste fintanto che il processo che detiene la
memoria bloccata non la sblocca. Chiaramente la terminazione del processo
comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
tutti i suoi \textit{memory lock}. Inoltre i \textit{memory lock} non sono
-ereditati dai processi figli, ma siccome Linux usa il \itindex{copy~on~write}
-\textit{copy on write} (vedi sez.~\ref{sec:proc_fork}) gli indirizzi virtuali
-del figlio sono mantenuti sullo stesso segmento di RAM del padre, e quindi
-fintanto che un figlio non scrive su un segmento bloccato, può usufruire del
-\textit{memory lock} del padre. Infine i \textit{memory lock} vengono
-automaticamente rimossi se si pone in esecuzione un altro programma con
-\func{exec} (vedi sez.~\ref{sec:proc_exec}).
+ereditati dai processi figli, ma siccome Linux usa il \textit{copy on write}
+(vedi sez.~\ref{sec:proc_fork}) gli indirizzi virtuali del figlio sono
+mantenuti sullo stesso segmento di RAM del padre, e quindi fintanto che un
+figlio non scrive su un segmento bloccato, può usufruire del \textit{memory
+ lock} del padre. Infine i \textit{memory lock} vengono automaticamente
+rimossi se si pone in esecuzione un altro programma con \func{exec} (vedi
+sez.~\ref{sec:proc_exec}).
Il sistema pone dei limiti all'ammontare di memoria di un processo che può
essere bloccata e al totale di memoria fisica che si può dedicare a questo, lo
standard POSIX.1 richiede che sia definita in \headfile{unistd.h} la macro
-\macro{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
+\macrod{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
\textit{memory locking}.
Siccome la richiesta di un \textit{memory lock} da parte di un processo riduce
la memoria fisica disponibile nel sistema per gli altri processi, questo ha un
evidente impatto su tutti gli altri processi, per cui fino al kernel 2.6.9
-solo un processo dotato di privilegi amministrativi (la \itindex{capabilities}
-\textit{capability} \const{CAP\_IPC\_LOCK}, vedi
-sez.~\ref{sec:proc_capabilities}) aveva la capacità di bloccare una pagina di
-memoria.
+solo un processo dotato di privilegi amministrativi (la \textit{capability}
+\const{CAP\_IPC\_LOCK}, vedi sez.~\ref{sec:proc_capabilities}) aveva la
+capacità di bloccare una pagina di memoria.
A partire dal kernel 2.6.9 anche un processo normale può bloccare la propria
memoria\footnote{la funzionalità è stata introdotta per non essere costretti a
però diversi processi bloccano la stessa pagina questa resterà bloccata
fintanto che ci sarà almeno un processo che la blocca.
-Le funzioni di sistema per bloccare e sbloccare la \index{paginazione}
-paginazione di singole sezioni di memoria sono rispettivamente \funcd{mlock} e
-\funcd{munlock}; i loro prototipi sono:
+Le funzioni di sistema per bloccare e sbloccare la paginazione di singole
+sezioni di memoria sono rispettivamente \funcd{mlock} e \funcd{munlock}; i
+loro prototipi sono:
\begin{funcproto}{
\fhead{sys/mman.h}
\end{funcproto}
Le due funzioni permettono rispettivamente di bloccare e sbloccare la
-\index{paginazione} paginazione per l'intervallo di memoria iniziante
-all'indirizzo \param{addr} e lungo \param{len} byte. Tutte le pagine che
-contengono una parte dell'intervallo bloccato sono mantenute in RAM per tutta
-la durata del blocco. Con kernel diversi da Linux si può ottenere un errore di
+paginazione per l'intervallo di memoria iniziante all'indirizzo \param{addr} e
+lungo \param{len} byte. Tutte le pagine che contengono una parte
+dell'intervallo bloccato sono mantenute in RAM per tutta la durata del
+blocco. Con kernel diversi da Linux si può ottenere un errore di
\errcode{EINVAL} se \param{addr} non è un multiplo della dimensione delle
pagine di memoria, pertanto se si ha a cuore la portabilità si deve avere cura
di allinearne correttamente il valore.
+% TODO trattare mlock2, introdotta con il kernel 4.4 (vedi
+% http://lwn.net/Articles/650538/)
+
Altre due funzioni di sistema, \funcd{mlockall} e \funcd{munlockall},
-consentono di bloccare genericamente la \index{paginazione} paginazione per
-l'intero spazio di indirizzi di un processo. I prototipi di queste funzioni
-sono:
+consentono di bloccare genericamente la paginazione per l'intero spazio di
+indirizzi di un processo. I prototipi di queste funzioni sono:
\begin{funcproto}{
\fhead{sys/mman.h}
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{MCL\_CURRENT}& blocca tutte le pagine correntemente mappate nello
- spazio di indirizzi del processo.\\
- \const{MCL\_FUTURE} & blocca tutte le pagine che verranno mappate nello
- spazio di indirizzi del processo.\\
+ \constd{MCL\_CURRENT}& blocca tutte le pagine correntemente mappate nello
+ spazio di indirizzi del processo.\\
+ \constd{MCL\_FUTURE} & blocca tutte le pagine che verranno mappate nello
+ spazio di indirizzi del processo.\\
\hline
\end{tabular}
\caption{Valori e significato dell'argomento \param{flags} della funzione
\end{table}
Con \func{mlockall} si possono bloccare tutte le pagine mappate nello spazio
-di indirizzi del processo, sia che comprendano il \index{segmento!dati}
-\index{segmento!testo} segmento di testo, di dati, lo \itindex{stack}
-\textit{stack}, lo \itindex{heap} \textit{heap} e pure le funzioni di libreria
-chiamate, i file mappati in memoria, i dati del kernel mappati in user space,
-la memoria condivisa. L'uso dell'argomento \param{flags} permette di
-selezionare con maggior finezza le pagine da bloccare, ad esempio usando
-\const{MCL\_FUTURE} ci si può limitare a tutte le pagine allocate a partire
-dalla chiamata della funzione.
-
-In ogni caso un processo real-time che deve entrare in una
-\index{sezione~critica} sezione critica deve provvedere a riservare memoria
-sufficiente prima dell'ingresso, per scongiurare l'occorrenza di un eventuale
-\itindex{page~fault} \textit{page fault} causato dal meccanismo di
-\itindex{copy~on~write} \textit{copy on write}. Infatti se nella
-\index{sezione~critica} sezione critica si va ad utilizzare memoria che non è
-ancora stata riportata in RAM si potrebbe avere un \itindex{page~fault}
-\textit{page fault} durante l'esecuzione della stessa, con conseguente
-rallentamento (probabilmente inaccettabile) dei tempi di esecuzione.
+di indirizzi del processo, sia che comprendano il segmento di testo, di dati,
+lo \textit{stack}, lo \textit{heap} e pure le funzioni di libreria chiamate, i
+file mappati in memoria, i dati del kernel mappati in user space, la memoria
+condivisa. L'uso dell'argomento \param{flags} permette di selezionare con
+maggior finezza le pagine da bloccare, ad esempio usando \const{MCL\_FUTURE}
+ci si può limitare a tutte le pagine allocate a partire dalla chiamata della
+funzione.
+
+In ogni caso un processo \textit{real-time} che deve entrare in una sezione
+critica (vedi sez.~\ref{sec:proc_race_cond}) deve provvedere a riservare
+memoria sufficiente prima dell'ingresso, per scongiurare l'occorrenza di un
+eventuale \textit{page fault} causato dal meccanismo di \textit{copy on
+ write}. Infatti se nella sezione critica si va ad utilizzare memoria che
+non è ancora stata riportata in RAM si potrebbe avere un \textit{page fault}
+durante l'esecuzione della stessa, con conseguente rallentamento
+(probabilmente inaccettabile) dei tempi di esecuzione.
In genere si ovvia a questa problematica chiamando una funzione che ha
-allocato una quantità sufficientemente ampia di \index{variabili!automatiche}
-variabili automatiche, in modo che esse vengano mappate in RAM dallo
-\itindex{stack} \textit{stack}, dopo di che, per essere sicuri che esse siano
-state effettivamente portate in memoria, ci si scrive sopra.
+allocato una quantità sufficientemente ampia di variabili automatiche, in modo
+che esse vengano mappate in RAM dallo \textit{stack}, dopo di che, per essere
+sicuri che esse siano state effettivamente portate in memoria, ci si scrive
+sopra.
\itindend{memory~locking}
-
\index{memoria~virtuale|)}
Un secondo caso in cui risulta estremamente utile poter avere un maggior
controllo delle modalità di allocazione della memoria è quello in cui cercano
-errori di programmazione. Esempi di questi errori sono i \itindex{double~free}
-\textit{double free}, o i cosiddetti \itindex{buffer~overrun} \textit{buffer
- overrun}, cioè le scritture su un buffer oltre le dimensioni della sua
+errori di programmazione. Esempi di questi errori sono i \textit{double free},
+o i cosiddetti \itindex{buffer~overrun} \textit{buffer overrun}, cioè le
+scritture su un buffer oltre le dimensioni della sua
allocazione,\footnote{entrambe queste operazioni causano in genere la
corruzione dei dati di controllo delle funzioni di allocazione, che vengono
- anch'essi mantenuti nello \itindex{heap} \textit{heap} per tenere traccia
- delle zone di memoria allocata.} o i classici \itindex{memory~leak}
-\textit{memory leak}.
+ anch'essi mantenuti nello \textit{heap} per tenere traccia delle zone di
+ memoria allocata.} o i classici \textit{memory leak}.
Abbiamo visto in sez.~\ref{sec:proc_mem_lock} come una prima funzionalità di
ausilio nella ricerca di questi errori sia l'uso della variabile di ambiente
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{MCHECK\_OK} & Riportato a \func{mprobe} se nessuna
- inconsistenza è presente.\\
- \const{MCHECK\_DISABLED}& Riportato a \func{mprobe} se si è chiamata
- \func{mcheck} dopo aver già usato
- \func{malloc}.\\
- \const{MCHECK\_HEAD} & I dati immediatamente precedenti il buffer sono
- stati modificati, avviene in genere quando si
- decrementa eccessivamente il valore di un
- puntatore scrivendo poi prima dell'inizio del
- buffer.\\
- \const{MCHECK\_TAIL} & I dati immediatamente seguenti il buffer sono
- stati modificati, succede quando si va scrivere
- oltre la dimensione corretta del buffer.\\
- \const{MCHECK\_FREE} & Il buffer è già stato disallocato.\\
+ \constd{MCHECK\_OK} & Riportato a \func{mprobe} se nessuna
+ inconsistenza è presente.\\
+ \constd{MCHECK\_DISABLED}& Riportato a \func{mprobe} se si è chiamata
+ \func{mcheck} dopo aver già usato
+ \func{malloc}.\\
+ \constd{MCHECK\_HEAD} & I dati immediatamente precedenti il buffer sono
+ stati modificati, avviene in genere quando si
+ decrementa eccessivamente il valore di un
+ puntatore scrivendo poi prima dell'inizio del
+ buffer.\\
+ \constd{MCHECK\_TAIL} & I dati immediatamente seguenti il buffer sono
+ stati modificati, succede quando si va scrivere
+ oltre la dimensione corretta del buffer.\\
+ \constd{MCHECK\_FREE} & Il buffer è già stato disallocato.\\
\hline
\end{tabular}
\caption{Valori dello stato dell'allocazione di memoria ottenibili dalla
Quando \func{getopt} trova un'opzione fra quelle indicate in \param{optstring}
essa ritorna il valore numerico del carattere, in questo modo si possono
eseguire azioni specifiche usando uno \instruction{switch}; la funzione
-inoltre inizializza alcune \index{variabili!globali} variabili globali:
+inoltre inizializza alcune variabili globali:
\begin{itemize*}
\item \var{char *optarg} contiene il puntatore alla stringa parametro
dell'opzione.
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 \code{argv[]} del primo degli argomenti rimanenti nella linea di comando.
+\texttt{\small 18-20}). Completato il ciclo troveremo in \var{optind}
+l'indice in \code{argv[]} del primo degli argomenti rimanenti nella linea di
+comando.
Normalmente \func{getopt} compie una permutazione degli elementi di
\param{argv} 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 \param{argv}; se \param{optstring} inizia
con il carattere ``\texttt{+}'' (o è impostata la variabile di ambiente
-\macro{POSIXLY\_CORRECT}) la scansione viene fermata non appena si incontra un
+\cmd{POSIXLY\_CORRECT}) la scansione viene fermata non appena si incontra un
elemento che non è un'opzione.
L'ultima modalità, usata quando un programma può gestire la mescolanza fra
terminata da un puntatore nullo.
L'indirizzo della lista delle variabili di ambiente è passato attraverso la
-\index{variabili!globali} variabile globale \var{environ}, che viene definita
-automaticamente per ciascun processo, e a cui si può accedere attraverso una
-semplice dichiarazione del tipo:
+variabile globale \var{environ}, che viene definita automaticamente per
+ciascun processo, e a cui si può accedere attraverso una semplice
+dichiarazione del tipo:
\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
& \textbf{Linux} & \textbf{Descrizione} \\
\hline
\hline
- \texttt{USER} &$\bullet$&$\bullet$&$\bullet$& Nome utente\\
- \texttt{LOGNAME}&$\bullet$&$\bullet$&$\bullet$& Nome di login\\
+ \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\\
+ 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\\
+ 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\\
+ testi.\\
+ \texttt{EDITOR} &$\bullet$&$\bullet$&$\bullet$& Editor preferito.\\
+ \texttt{BROWSER}&$\bullet$&$\bullet$&$\bullet$& Browser preferito.\\
\texttt{TMPDIR} &$\bullet$&$\bullet$&$\bullet$& Directory dei file
- temporanei\\
+ temporanei.\\
\hline
\end{tabular}
\caption{Esempi delle variabili di ambiente più comuni definite da vari
eliminando anche, sempre in conformità a SUSv2, l'attributo \direct{const}
dal prototipo.} pertanto ogni cambiamento alla stringa in questione si
riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
-questa funzione una \index{variabili!automatiche} variabile automatica (per
-evitare i problemi esposti in sez.~\ref{sec:proc_var_passing}). Benché non sia
-richiesto dallo standard nelle versioni della \acr{glibc} a partire dalla 2.1
-la funzione è rientrante (vedi sez.~\ref{sec:proc_reentrant}).
+questa funzione una variabile automatica (per evitare i problemi esposti in
+sez.~\ref{sec:proc_var_passing}). Benché non sia richiesto dallo standard
+nelle versioni della \acr{glibc} a partire dalla 2.1 la funzione è rientrante
+(vedi sez.~\ref{sec:proc_reentrant}).
Infine quando una chiamata a \func{putenv} comporta la necessità di creare una
nuova versione del vettore \var{environ} questo sarà allocato automaticamente,
un'allocazione fatta in precedenza da un'altra \func{putenv}. Questo avviene
perché il vettore delle variabili di ambiente iniziale, creato dalla chiamata
ad \func{exec} (vedi sez.~\ref{sec:proc_exec}) è piazzato nella memoria al di
-sopra dello \itindex{stack} \textit{stack}, (vedi
-fig.~\ref{fig:proc_mem_layout}) e non nello \itindex{heap} \textit{heap} e
-quindi non può essere deallocato. Inoltre la memoria associata alle variabili
-di ambiente eliminate non viene liberata.
+sopra dello \textit{stack}, (vedi fig.~\ref{fig:proc_mem_layout}) e non nello
+\textit{heap} e quindi non può essere deallocato. Inoltre la memoria
+associata alle variabili di ambiente eliminate non viene liberata.
Come alternativa a \func{putenv} si può usare la funzione \funcd{setenv} che
però consente solo di aggiungere o modificare una variabile di ambiente; il
% TODO opzioni in formato esteso
+% TODO trattare il vettore ausiliario e getauxval (vedi
+% http://lwn.net/Articles/519085/)
+
+
\section{Problematiche di programmazione generica}
\label{sec:proc_gen_prog}
alla funzione chiamante attraverso il valore di ritorno. È buona norma
seguire questa pratica anche nella programmazione normale.
+\itindbeg{value~result~argument}
+
Talvolta però è necessario che la funzione possa restituire indietro alla
funzione chiamante un valore relativo ad uno dei suoi argomenti usato anche in
-ingresso. Per far questo si usa il cosiddetto \itindex{value~result~argument}
-\textit{value result argument}, si passa cioè, invece di una normale
-variabile, un puntatore alla stessa. Gli esempi di questa modalità di
-passaggio sono moltissimi, ad esempio essa viene usata 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 proprio questo meccanismo.
+ingresso. Per far questo si usa il cosiddetto \textit{value result argument},
+si passa cioè, invece di una normale variabile, un puntatore alla stessa. Gli
+esempi di questa modalità di passaggio sono moltissimi, ad esempio essa viene
+usata 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 proprio questo meccanismo.
Occorre tenere ben presente questa differenza, perché le variabili passate in
maniera ordinaria, che vengono inserite nello \textit{stack}, cessano di
passare delle informazioni occorre quindi usare un puntatore che faccia
riferimento ad un indirizzo accessibile alla funzione chiamante.
+\itindend{value~result~argument}
+
Questo requisito di accessibilità è fondamentale, infatti dei possibili
problemi che si possono avere con il passaggio dei dati è quello di restituire
-alla funzione chiamante dei dati che sono contenuti in una
-\index{variabili!automatiche} variabile automatica. Ovviamente quando la
-funzione ritorna la sezione dello \itindex{stack} \textit{stack} che conteneva
-la \index{variabili!automatiche} variabile automatica (si ricordi quanto detto
+alla funzione chiamante dei dati che sono contenuti in una variabile
+automatica. Ovviamente quando la funzione ritorna la sezione dello
+\textit{stack} che conteneva la variabile automatica (si ricordi quanto detto
in sez.~\ref{sec:proc_mem_alloc}) verrà liberata automaticamente e potrà
essere riutilizzata all'invocazione di un'altra funzione, con le immaginabili
conseguenze, quasi invariabilmente catastrofiche, di sovrapposizione e
Per questo una delle regole fondamentali della programmazione in C è che
all'uscita di una funzione non deve restare nessun riferimento alle sue
-\index{variabili!automatiche} variabili locali. Qualora sia necessario
-utilizzare delle variabili che devono essere viste anche dalla funzione
-chiamante queste devono essere allocate esplicitamente, o in maniera statica
-usando variabili globali o dichiarate come \direct{extern},\footnote{la
- direttiva \direct{extern} informa il compilatore che la variabile che si è
- dichiarata in una funzione non è da considerarsi locale, ma globale, e per
- questo allocata staticamente e visibile da tutte le funzioni dello stesso
- programma.} o dinamicamente con una delle funzioni della famiglia
-\func{malloc}, passando opportunamente il relativo puntatore fra le funzioni.
+variabili locali. Qualora sia necessario utilizzare delle variabili che devono
+essere viste anche dalla funzione chiamante queste devono essere allocate
+esplicitamente, o in maniera statica usando variabili globali o dichiarate
+come \direct{extern},\footnote{la direttiva \direct{extern} informa il
+ compilatore che la variabile che si è dichiarata in una funzione non è da
+ considerarsi locale, ma globale, e per questo allocata staticamente e
+ visibile da tutte le funzioni dello stesso programma.} o dinamicamente con
+una delle funzioni della famiglia \func{malloc}, passando opportunamente il
+relativo puntatore fra le funzioni.
\subsection{Il passaggio di un numero variabile di argomenti}
\label{sec:proc_variadic}
-\index{funzioni!variadic|(}
+\index{funzioni!\textit{variadic}|(}
Come vedremo nei capitoli successivi, non sempre è possibile specificare un
numero fisso di argomenti per una funzione. Lo standard ISO C prevede nella
quando la si va a definire. Gli argomenti fissi infatti hanno un loro nome, ma
quelli variabili vengono indicati in maniera generica dalla
\textit{ellipsis}. L'unica modalità in cui essi possono essere recuperati è
-pertanto quella sequenziale, in cui vengono estratti dallo \itindex{stack}
-\textit{stack} secondo l'ordine in cui sono stati scritti nel prototipo della
-funzione.
+pertanto quella sequenziale, in cui vengono estratti dallo \textit{stack}
+secondo l'ordine in cui sono stati scritti nel prototipo della funzione.
+
+\macrobeg{va\_start}
Per fare questo in \headfile{stdarg.h} sono definite delle macro specifiche,
previste dallo standard ISO C89, che consentono di eseguire questa operazione.
}
\end{funcbox}}
-La macro inizializza il puntatore alla lista di argomenti \param{ap} che
-deve essere una apposita variabile di tipo \type{va\_list}; il
+La macro inizializza il puntatore alla lista di argomenti \param{ap} che deve
+essere una apposita variabile di tipo \type{va\_list}; il
parametro \param{last} deve indicare il nome dell'ultimo degli argomenti fissi
-dichiarati nel prototipo della funzione \textit{variadic}.
+dichiarati nel prototipo della funzione \textit{variadic}.
+
+\macrobeg{va\_arg}
La seconda macro di gestione delle liste di argomenti di una funzione
\textit{variadic} è \macro{va\_arg}, che restituisce in successione un
risultati indefiniti anche quando si chiama \macro{va\_arg} specificando un
tipo che non corrisponde a quello usato per il corrispondente argomento.
+\macrobeg{va\_end}
+
Infine una volta completata l'estrazione occorre indicare che si sono concluse
-le operazioni con la macro \macro{va\_end}, la cui definizione è:
+le operazioni con la macro \macrod{va\_end}, la cui definizione è:
{\centering
\begin{funcbox}{
(anche se non si era completata l'estrazione) dato che il valore di \param{ap}
risulterebbe indefinito.
+\macroend{va\_start}
+\macroend{va\_arg}
+\macroend{va\_end}
+
Esistono dei casi in cui è necessario eseguire più volte la scansione degli
argomenti e poter memorizzare una posizione durante la stessa. In questo caso
sembrerebbe naturale copiarsi la lista degli argomenti \param{ap} con una
semplice assegnazione ad un'altra variabile dello stesso tipo. Dato che una
delle realizzazioni più comuni di \type{va\_list} è quella di un puntatore
-nello \itindex{stack} \textit{stack} all'indirizzo dove sono stati salvati gli
-argomenti, è assolutamente normale pensare di poter effettuare questa
-operazione.
+nello \textit{stack} all'indirizzo dove sono stati salvati gli argomenti, è
+assolutamente normale pensare di poter effettuare questa operazione.
+
+\index{tipo!opaco|(}
In generale però possono esistere anche realizzazioni diverse, ed è per questo
-motivo che invece che di un semplice puntatore viene \type{va\_list} è quello
-che viene chiamato un \index{tipo!opaco} \textsl{tipo opaco}. Si chiamano così
-quei tipi di dati, in genere usati da una libreria, la cui struttura interna
-non deve essere vista dal programma chiamante (da cui deriva il nome opaco)
-che li devono utilizzare solo attraverso dalle opportune funzioni di
-gestione.
-
-Per questo motivo una variabile di tipo \type{va\_list} non può essere
+motivo che invece che un semplice puntatore, \typed{va\_list} è quello che
+viene chiamato un \textsl{tipo opaco}. Si chiamano così quei tipi di dati, in
+genere usati da una libreria, la cui struttura interna non deve essere vista
+dal programma chiamante (da cui deriva il nome opaco) che li devono utilizzare
+solo attraverso dalle opportune funzioni di gestione.
+
+\index{tipo!opaco|)}
+
+Per questo motivo una variabile di tipo \typed{va\_list} non può essere
assegnata direttamente ad un'altra variabile dello stesso tipo, ma 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
+ posto \macrod{\_\_va\_copy} che era il nome proposto in una bozza dello
standard.} ha previsto una macro ulteriore che permette di eseguire la
copia di una lista degli argomenti:
La macro copia l'attuale della lista degli argomenti \param{src} su una nuova
lista \param{dest}. Anche in questo caso è buona norma chiudere ogni
-esecuzione di una \macro{va\_copy} con una corrispondente \macro{va\_end} sul
+esecuzione di una \macrod{va\_copy} con una corrispondente \macro{va\_end} sul
nuovo puntatore alla lista degli argomenti.
La chiamata di una funzione con un numero variabile di argomenti, posto che la
usa un puntatore \val{NULL} per indicare la fine della lista degli argomenti
(vedi sez.~\ref{sec:proc_exec}).
-\index{funzioni!variadic|)}
+\index{funzioni!\textit{variadic}|)}
\subsection{Il controllo di flusso non locale}
\label{sec:proc_longjmp}
ecc.), che non potrebbero essere eseguite con un salto non-locale.}
Tutto ciò può essere realizzato proprio con un salto non-locale; questo di
-norma viene realizzato salvando il contesto dello \itindex{stack}
-\textit{stack} nel punto in cui si vuole tornare in caso di errore, e
-ripristinandolo, in modo da tornare quando serve nella funzione da cui si era
-partiti. La funzione che permette di salvare il contesto dello
-\itindex{stack} \textit{stack} è \funcd{setjmp}, il cui prototipo è:
+norma viene realizzato salvando il contesto dello \textit{stack} nel punto in
+cui si vuole tornare in caso di errore, e ripristinandolo, in modo da tornare
+quando serve nella funzione da cui si era partiti. La funzione che permette
+di salvare il contesto dello \textit{stack} è \funcd{setjmp}, il cui prototipo
+è:
\begin{funcproto}{
\fhead{setjmp.h}
salvato in precedenza.}
\end{funcproto}
-Quando si esegue la funzione il contesto corrente dello \itindex{stack}
-\textit{stack} viene salvato nell'argomento \param{env}, una variabile di tipo
-\type{jmp\_buf}\footnote{anche questo è un classico esempio di variabile di
- \index{tipo!opaco} \textsl{tipo opaco}.} che deve essere stata definita in
-precedenza. In genere le variabili di tipo \type{jmp\_buf} vengono definite
-come \index{variabili!globali} variabili globali in modo da poter essere viste
-in tutte le funzioni del programma.
+Quando si esegue la funzione il contesto corrente dello \textit{stack} viene
+salvato nell'argomento \param{env}, una variabile di tipo
+\typed{jmp\_buf}\footnote{anche questo è un classico esempio di variabile di
+ \textsl{tipo opaco}.} che deve essere stata definita in precedenza. In
+genere le variabili di tipo \type{jmp\_buf} vengono definite come variabili
+globali in modo da poter essere viste in tutte le funzioni del programma.
Quando viene eseguita direttamente la funzione ritorna sempre zero, un valore
diverso da zero viene restituito solo quando il ritorno è dovuto ad una
chiamata di \func{longjmp} in un'altra parte del programma che ripristina lo
-\itindex{stack} \textit{stack} effettuando il salto non-locale. Si tenga conto
-che il contesto salvato in \param{env} viene invalidato se la funzione che ha
-chiamato \func{setjmp} ritorna, nel qual caso un successivo uso di
-\func{longjmp} può comportare conseguenze imprevedibili (e di norma fatali)
-per il processo.
+\textit{stack} effettuando il salto non-locale. Si tenga conto che il contesto
+salvato in \param{env} viene invalidato se la funzione che ha chiamato
+\func{setjmp} ritorna, nel qual caso un successivo uso di \func{longjmp} può
+comportare conseguenze imprevedibili (e di norma fatali) per il processo.
Come accennato per effettuare un salto non-locale ad un punto precedentemente
stabilito con \func{setjmp} si usa la funzione \funcd{longjmp}; il suo
{La funzione non ritorna.}
\end{funcproto}
-La funzione ripristina il contesto dello \itindex{stack} \textit{stack}
-salvato da una chiamata a \func{setjmp} nell'argomento \param{env}. Dopo
-l'esecuzione della funzione il programma prosegue nel codice successivo alla
-chiamata della \func{setjmp} con cui si era salvato \param{env}, che
-restituirà il valore dell'argomento \param{val} invece di zero. Il valore
+La funzione ripristina il contesto dello \textit{stack} salvato da una
+chiamata a \func{setjmp} nell'argomento \param{env}. Dopo l'esecuzione della
+funzione il programma prosegue nel codice successivo alla chiamata della
+\func{setjmp} con cui si era salvato \param{env}, che restituirà il valore
+dell'argomento \param{val} invece di zero. Il valore
dell'argomento \param{val} deve essere sempre diverso da zero, se si è
specificato 0 sarà comunque restituito 1 al suo posto.
In sostanza l'esecuzione di \func{longjmp} è analoga a quella di una
-istruzione \instruction{return}, solo che invece di ritornare alla riga
+istruzione \instr{return}, solo che invece di ritornare alla riga
successiva della funzione chiamante, il programma in questo caso ritorna alla
posizione della relativa \func{setjmp}. L'altra differenza fondamentale con
-\instruction{return} è che il ritorno può essere effettuato anche attraverso
+\instr{return} è che il ritorno può essere effettuato anche attraverso
diversi livelli di funzioni annidate.
L'implementazione di queste funzioni comporta alcune restrizioni dato che esse
-interagiscono direttamente con la gestione dello \itindex{stack}
-\textit{stack} ed il funzionamento del compilatore stesso. In particolare
-\func{setjmp} è implementata con una macro, pertanto non si può cercare di
-ottenerne l'indirizzo, ed inoltre le chiamate a questa funzione sono sicure
-solo in uno dei seguenti casi:
+interagiscono direttamente con la gestione dello \textit{stack} ed il
+funzionamento del compilatore stesso. In particolare \func{setjmp} è
+implementata con una macro, pertanto non si può cercare di ottenerne
+l'indirizzo, ed inoltre le chiamate a questa funzione sono sicure solo in uno
+dei seguenti casi:
\begin{itemize*}
\item come espressione di controllo in un comando condizionale, di selezione o
di iterazione (come \instruction{if}, \instruction{switch} o
In generale, dato che l'unica differenza fra la chiamata diretta e quella
ottenuta nell'uscita con un \func{longjmp} è costituita dal valore di ritorno
di \func{setjmp}, pertanto quest'ultima viene usualmente chiamata all'interno
-di un una istruzione \instruction{if} che permetta di distinguere i due casi.
+di un una istruzione \instr{if} che permetta di distinguere i due casi.
Uno dei punti critici dei salti non-locali è quello del valore delle
-variabili, ed in particolare quello delle \index{variabili!automatiche}
-variabili automatiche della funzione a cui si ritorna. In generale le
-\index{variabili!globali} variabili globali e \index{variabili!statiche}
-statiche mantengono i valori che avevano al momento della chiamata di
-\func{longjmp}, ma quelli delle \index{variabili!automatiche} variabili
-automatiche (o di quelle dichiarate \direct{register}) sono in genere
-indeterminati.
+variabili, ed in particolare quello delle variabili automatiche della funzione
+a cui si ritorna. In generale le variabili globali e statiche mantengono i
+valori che avevano al momento della chiamata di \func{longjmp}, ma quelli
+delle variabili automatiche (o di quelle dichiarate \dirct{register}) sono in
+genere indeterminati.
Quello che succede infatti è che i valori delle variabili che sono tenute in
memoria manterranno il valore avuto al momento della chiamata di
\func{longjmp}, mentre quelli tenuti nei registri del processore (che nella
chiamata ad un'altra funzione vengono salvati nel contesto nello
-\itindex{stack} \textit{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
+\textit{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
\direct{volatile} informa il compilatore che la variabile che è dichiarata
può essere modificata, durante l'esecuzione del nostro, da altri programmi.
\index{salto~non-locale|)}
+% TODO trattare qui le restartable sequences (vedi
+% https://lwn.net/Articles/664645/ e https://lwn.net/Articles/650333/) se e
+% quando saranno introdotte
+
\subsection{La \textit{endianness}}
-\label{sec:sock_endianness}
+\label{sec:endianness}
\itindbeg{endianness}
Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
allora se lo eseguiamo su un normale PC compatibile, che è \textit{little
endian} otterremo qualcosa del tipo:
-\begin{Command}
-[piccardi@gont sources]$ ./endtest
-\end{Command}
-%$
-\begin{Terminal}
+\begin{Console}
+[piccardi@gont sources]$ \textbf{./endtest}
Using value ABCDEF01
val[0]= 1
val[1]=EF
val[2]=CD
val[3]=AB
-\end{Terminal}
+\end{Console}
+%$
mentre su un vecchio Macintosh con PowerPC, che è \textit{big endian} avremo
qualcosa del tipo:
-\begin{Command}
-piccardi@anarres:~/gapil/sources$ ./endtest
-\end{Command}
-%$
-\begin{Terminal}
+\begin{Console}
+piccardi@anarres:~/gapil/sources$ \textbf{./endtest}
Using value ABCDEF01
val[0]=AB
val[1]=CD
val[2]=EF
val[3]= 1
-\end{Terminal}
+\end{Console}
+%$
L'attenzione alla \textit{endianness} nella programmazione è importante, perché
se si fanno assunzioni relative alla propria architettura non è detto che
% LocalWords: capability MEMLOCK limits getpagesize RLIMIT munlock sys const
% LocalWords: addr len EINVAL EPERM mlockall munlockall flags l'OR CURRENT IFS
% LocalWords: argc argv parsing questofile txt getopt optstring switch optarg
-% LocalWords: optind opterr optopt ForkTest POSIXLY CORRECT long options NdA
+% LocalWords: optind opterr optopt POSIXLY CORRECT long options NdA
% LocalWords: option parameter list environ PATH HOME XPG tab LOGNAME LANG PWD
% LocalWords: TERM PAGER TMPDIR getenv name SVr setenv unsetenv putenv opz gcc
% LocalWords: clearenv libc value overwrite string reference result argument
projects / gapil.git / blobdiff