\label{cha:files_and_dirs}
In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
-files e directories, ed in particolare esamineremo come è strutturato il
-sistema base di protezioni e controllo di accesso ai files, e tutta
-l'interfaccia che permette la manipolazione dei vari attributi di files e
-directories. Tutto quello che riguarda invece la manipolazione del contenuto
-dei file è lasciato ai capitoli successivi.
+file e directory, ed in particolare esamineremo come è strutturato il sistema
+base di protezioni e controllo di accesso ai file, e tutta l'interfaccia che
+permette la manipolazione dei vari attributi di file e directory. Tutto quello
+che riguarda invece la manipolazione del contenuto dei file è lasciato ai
+capitoli successivi.
-\section{La gestione di file e directory}
+
+\section{Il controllo di accesso ai file}
+\label{sec:filedir_access_control}
+
+Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella
+del controllo di accesso ai file, che viene implementato per qualunque
+filesystem standard. In questa sezione ne esamineremo i concetti essenziali e
+le funzioni usate per gestirne i vari aspetti.
+
+
+\subsection{I permessi per l'accesso ai file}
+\label{sec:filedir_perm_overview}
+
+Il controllo di accesso ai file in unix segue un modello abbastanza semplice,
+ma adatto alla gran parte delle esigenze, in cui si dividono i permessi su tre
+livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem di
+tipo unix, e non è detto che sia applicabile a un filesystem
+qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,
+ per il quale vengono assegnati in maniera fissa con un opzione in fase di
+ montaggio}. Esistono inoltre estensioni che permettono di implementare le
+ACL (\textit{Access Control List}) che sono un meccanismo di controllo di
+accesso molto più sofisticato.
+
+Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto
+\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli
+identificatoti di utenti e gruppi (uid e gig) già accennato in
+\secref{sec:intro_multiuser}, e un insieme di permessi che sono divisi in tre
+classi, e cioè attribuiti rispettivamente al proprietario, a qualunque utente
+faccia parte del gruppo cui appartiene il file, e a tutti gli altri utenti.
+
+I permessi sono espressi da un insieme di 12 bit: di questi i nove meno
+significativi sono usati a gruppi di tre per indicare i permessi base di
+lettura, scrittura ed esecuzione (indicati rispettivamente con le lettere
+\textit{w}, \textit{r} \textit{x} nell'output di \cmd{ls}) applicabili
+rispettivamente al proprietario, al gruppo, a tutti (una descrizione più
+dettagliata dei vari permessi associati ai file è riportata in
+\secref{sec:filedir_suid_sgid}). I restanti tre bit sono usati per indicare
+alcune caratteristiche più complesse (\textit{suid}, \textit{sgid}, e
+\textit{sticky}) su cui pure torneremo in seguito (vedi
+\secref{sec:filedir_suid_sgid} e \secref{sec:filedir_sticky}).
+
+Tutte queste informazioni sono tenute per ciascun file nell'inode, in
+opportuni bit del campo \var{st\_mode} della struttura letta da \func{stat}
+(vedi \figref{fig:filedir_stat_struct}) che possono essere controllati con i
+valori riportati in \ntab.
+
+\begin{table}[htb]
+ \centering
+
+ \caption{I bit deipermessi di accesso ai file, come definiti in
+ \texttt{<sys/stat.h>}}
+ \label{tab:file_bit_perm}
+\end{table}
+
+
+% Quando un processo cerca l'accesso al file esso controlla i propri uid e gid
+% confrontandoli con quelli del file e se l'operazione richiesta è compatibile
+% con i permessi associati al file essa viene eseguita, altrimenti viene
+% bloccata ed è restituito un errore di \texttt{EPERM}. Questo procedimento non
+% viene eseguito per l'amministratore di sistema (il cui uid è zero) il quale
+% a
+% pertanto accesso senza restrizione a qualunque file del sistema.
+
+% In realtà il procedimento è più complesso di quanto descritto in maniera
+% elementare qui; inoltre ad un processo sono associati diversi identificatori,
+% torneremo su questo in maggiori dettagli in seguito in \secref{sec:proc_perms}.
+
+
+\subsection{I flag \texttt{suid} e \texttt{sgid}}
+\label{sec:filedir_suid_sgid}
+
+\subsection{La titolarità di nuovi files e directory}
+\label{sec:filedir_ownership}
+
+
+\subsection{La funzione \texttt{access}}
+\label{sec:filedir_access}
+
+
+\subsection{La funzione \texttt{umask}}
+\label{sec:filedir_umask}
+
+
+\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
+\label{sec:filedir_chmod}
+
+\subsection{Il flag \texttt{sticky}}
+\label{sec:filedir_sticky}
+
+\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
+\label{sec:filedir_chown}
+
+
+
+
+%La struttura fondamentale che contiene i dati essenziali relativi ai file è il
+%cosiddetto \textit{inode}; questo conterrà informazioni come il
+%tipo di file (file di dispositivo, directory, file di dati, per un elenco
+%completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi
+%\secref{sec:file_times}).
+
+
+
+
+\section{La manipolazione di file e directory}
Le prime funzioni che considereremo sono quelle relative alla gestione di file
e directory, secondo le caratteristiche standard che essi presentano in un
ma data la struttura del sistema ci sono due metodi sostanzialmente diversi
per fare questa operazione.
-Come si è appena detto l'accesso al contenuto di un file su disco avviene
-attraverso il suo inode, e il nome che si trova in una directory è solo una
-etichetta associata ad un puntatore a detto inode. Questo significa che la
-realizzazione di un link è immediata in quanto uno stesso file può avere tanti
-nomi diversi allo stesso tempo, dati da altrettante diverse associazioni allo
-stesso inode; si noti poi che nessuno di questi nomi viene ad assumere una
-particolare preferenza rispetto agli altri.
+Come spiegato in \secref{sec:fileintr_architecture} l'accesso al contenuto di
+un file su disco avviene attraverso il suo inode, e il nome che si trova in
+una directory è solo una etichetta associata ad un puntatore a detto inode.
+Questo significa che la realizzazione di un link è immediata in quanto uno
+stesso file può avere tanti nomi diversi allo stesso tempo, dati da
+altrettante diverse associazioni allo stesso inode; si noti poi che nessuno di
+questi nomi viene ad assumere una particolare preferenza rispetto agli altri.
Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si
suole chiamare questo tipo di associazione un collegamento diretto (o
Crea un nuovo collegamento diretto al file indicato da \texttt{oldpath}
dandogli nome \texttt{newpath}.
- La funzione restituisce zero in caso di successo e -1 per un errore, in caso
- di errore. La variabile \texttt{errno} viene settata secondo i seguenti
- codici di errore:
+ La funzione restituisce zero in caso di successo e -1 in caso di errore. La
+ variabile \texttt{errno} viene settata opportunamente, i principali codici
+ di errore sono:
\begin{errlist}
\item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo
stesso filesystem.
\item \texttt{EPERM} il filesystem che contiene \texttt{oldpath} e
\texttt{newpath} non supporta i link diretti o è una directory.
- \item \texttt{EFAULT} una delle stringhe passate come parametri è fuori
- dello spazio di indirizzi del processo.
- \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o
- per attraversare le directories), vedi \secref{sec:filedir_access_control}
- per i dettagli.
- \item \texttt{ENAMETOOLONG} una dei due pathname è troppo lungo.
- \item \texttt{ENOENT} un componente di \texttt{oldpath} o \texttt{newpath}
- non esiste o è un link simbolico spezzato.
- \item \texttt{ENOTDIR} un componente di \texttt{oldpath} o \texttt{newpath}
- non è una directory.
- \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
- completare l'operazione.
- \item \texttt{EROFS} la directory su cui si vuole inserire il nuovo link è
- su un filesystem montato readonly.
\item \texttt{EEXIST} un file (o una directory) con quel nome esiste di
già.
\item \texttt{EMLINK} ci sono troppi link al file \texttt{oldpath} (il
numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
\secref{sec:xxx_limits}).
- \item \texttt{ELOOP} si incontrati troppi link simbolici nella risoluzione
- di \texttt{oldpath} o \texttt{newpath}.
- \item \texttt{ENOSPC} la directory in cui si vuole creare il link non ha
- spazio per ulteriori voci.
- \item \texttt{EIO} c'è stato un errore di input/output.
\end{errlist}
+
\end{prototype}
La creazione di un nuovo collegamento diretto non copia il contenuto del file,
qual caso il file non viene toccato. La variabile \texttt{errno} viene
settata secondo i seguenti codici di errore:
\begin{errlist}
- \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o
- per attraversare le directories), vedi \secref{sec:filedir_access_control}
- per i dettagli.
- \item \texttt{EISDIR} \texttt{pathname} si riferisce ad una directory
+ \item \texttt{EISDIR} \var{pathname} si riferisce ad una directory
(valore specifico ritornato da linux che non consente l'uso di
\texttt{unlink} con le directory, e non conforme allo standard POSIX, che
prescrive invece l'uso di \texttt{EPERM} in caso l'operazione non sia
consnetita o il processo non abbia privilegi sufficienti).
- \item \texttt{EFAULT} la stringa
- passata come parametro è fuori dello spazio di indirizzi del processo.
- \item \texttt{ENAMETOOLONG} il pathname troppo lungo.
- \item \texttt{ENOENT} uno dei componenti del pathname non esiste o è un link
- simbolico spezzato.
- \item \texttt{ENOTDIR} uno dei componenti del pathname non è una directory.
- \item \texttt{EISDIR} \texttt{pathname} fa riferimento a una directory.
- \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
- completare l'operazione.
- \item \texttt{EROFS} \texttt{pathname} è su un filesystem montato in sola
- lettura.
- \item \texttt{ELOOP} ci sono troppi link simbolici nella risoluzione del
- pathname.
- \item \texttt{EIO} errore di input/output.
+ \item \texttt{EROFS} \var{pathname} è su un filesystem montato in sola
+ lettura.
+ \item \texttt{EISDIR} \var{pathname} fa riferimento a una directory.
\end{errlist}
\end{prototype}
\end{prototype}
+
\section{La manipolazione delle caratteristiche dei files}
\label{sec:filedir_infos}
i vari flag; ad esempio se si volesse controllare se un file è una directory o
un file ordinario si potrebbe definire la condizione:
\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
-#define IS_FILE_DIR(x) ( ((x) & S_IFMT) & (S_IFDIR | S_IFREG) )
+#define IS_FILE_DIR(x) (((x) & S_IFMT) & (S_IFDIR | S_IFREG))
\end{lstlisting}
in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e
poi si effettua il confronto con la combinazione di tipi scelta.
fino alla lunghezza scelta; in quest'ultimo caso lo spazio viene riempito con
zeri (e in genere si ha la creazione di un hole nel file).
+
\subsection{I tempi dei file}
\label{sec:filedir_file_times}
\end{table}
Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di
-creazione del file usato da molti altri sistemi operativi, che in unix non
+creazione del file, usato da molti altri sistemi operativi, che in unix non
esiste.
molto più complicato da realizzare.
-\section{Il controllo di accesso ai file}
-\label{sec:filedir_access_control}
-
-In unix è implementata da qualunque filesystem standard una forma elementare
-(ma adatta alla maggior parte delle esigenze) di controllo di accesso ai
-files. Torneremo sull'argomento in dettaglio più avanti (vedi
-\secref{sec:filedir_access_control}), qui ci limitiamo ad una introduzione dei
-concetti essenziali.
-
-Si tenga conto poi che quanto diremo è vero solo per filesystem di tipo Unix,
-e non è detto che sia applicabile (ed infatti non è vero per il filesystem di
-Windows) a un filesystem qualunque. Esistono inoltre estensioni che permettono
-di implementare le ACL (\textit{Access Control List}) che sono un meccanismo
-di controllo di accesso molto più sofisticato.
-
-Ad ogni file Unix associa sempre l'utente che ne è proprietario (il cosiddetto
-\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli uid e
-gid accennato in \secref{sec:intro_multiuser}, e un insieme di permessi che
-sono divisi in tre classi, e cioè attribuiti rispettivamente al proprietario,
-a qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti
-gli altri utenti.
-
-I permessi sono espressi da un insieme di 12 bit: di questi i nove meno
-significativi sono usati a gruppi di tre per indicare i permessi base di
-lettura, scrittura ed esecuzione (indicati rispettivamente con le lettere
-\textit{w}, \textit{r} \textit{x}) applicabili rispettivamente al
-proprietario, al gruppo, a tutti (una descrizione più dettagliata dei vari
-permessi associati ai file è riportata in \secref{sec:filedir_suid_sgid}). I
-restanti tre bit sono usati per indicare alcune caratteristiche più complesse
-(\textit{suid}, \textit{sgid}, e \textit{sticky}) su cui pure torneremo in
-seguito (vedi \secref{sec:filedir_suid_sgid} e \secref{sec:filedir_sticky}).
-
-Tutte queste informazioni sono tenute per ciascun file nell'inode. Quando un
-processo cerca l'accesso al file esso controlla i propri uid e gid
-confrontandoli con quelli del file e se l'operazione richiesta è compatibile
-con i permessi associati al file essa viene eseguita, altrimenti viene
-bloccata ed è restituito un errore di \texttt{EPERM}. Questo procedimento non
-viene eseguito per l'amministratore di sistema (il cui uid è zero) il quale ha
-pertanto accesso senza restrizione a qualunque file del sistema.
-
-% In realtà il procedimento è più complesso di quanto descritto in maniera
-% elementare qui; inoltre ad un processo sono associati diversi identificatori,
-% torneremo su questo in maggiori dettagli in seguito in \secref{sec:proc_perms}.
-
-\subsection{I flag \texttt{suid} e \texttt{sgid}}
-\label{sec:filedir_suid_sgid}
-
-
-
-
-
-
-\subsection{La titolarità di nuovi files e directory}
-\label{sec:filedir_ownership}
-
-\subsection{La funzione \texttt{access}}
-\label{sec:filedir_access}
-
-\subsection{La funzione \texttt{umask}}
-\label{sec:filedir_umask}
-
-\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
-\label{sec:filedir_chmod}
-
-\subsection{Il flag \texttt{sticky}}
-\label{sec:filedir_sticky}
-
-\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
-\label{sec:filedir_chown}
-
-
-
-
-%La struttura fondamentale che contiene i dati essenziali relativi ai file è il
-%cosiddetto \textit{inode}; questo conterrà informazioni come il
-%tipo di file (file di dispositivo, directory, file di dati, per un elenco
-%completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi
-%\secref{sec:file_times}).
-
\begin{figure}[htb]
\centering
- \includegraphics[width=5cm]{img/vfs.eps}
+ \includegraphics[width=7cm]{img/vfs.eps}
\caption{Schema delle operazioni del VFS}
\label{fig:fileintr_VFS_scheme}
\end{figure}
\begin{table}[htb]
\centering
- \begin{tabular}[c]{|c|p{7cm}}
+ \begin{tabular}[c]{|c|p{7cm}|}
\hline
\textbf{funzione} & \textbf{operazione} \\
\hline
comuni di un qualunque filesystem standard unix.
Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni
-partizione può contenere un filesystem; quest'ultimo è in genere strutturato
-secondo \nfig, con una lista di inodes all'inizio e il resto dello spazio a
-disposizione per i dati e le directory.
+partizione può contenere un filesystem; la strutturazione tipica
+dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento
+alla struttura del filesystem ext2, che prevede una separazione dei dati in
+\textit{blocks group} che replicano il superblock (ma sulle caratteristiche di
+ext2 torneremo in \secref{sec:fileintr_ext2}). È comunque caratteristica
+comune di tutti i filesystem unix, indipendentemente da come poi viene
+strutturata nei dettagli questa informazione, prevedere una divisione fra la
+lista degli inodes e lo spazio a disposizione per i dati e le directory.
\begin{figure}[htb]
\centering
-
+ \includegraphics[width=9cm]{img/disk_struct.eps}
\caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
\label{fig:fileintr_disk_filesys}
\end{figure}
-Se si va ad esaminare come è strutturata l'informazione all'interno di un
-singolo filesystem (tralasciando le parti connesse alla strutturazione e al
-funzionamento del filesystem stesso come il super-block) avremo una situazione
-del tipo di quella esposta in \nfig.
+Se si va ad esaminare con maggiore dettaglio la strutturazione
+dell'informazione all'interno del singolo filesystem (tralasciando i dettagli
+relativi al funzionamento del filesystem stesso come la strutturazione in
+gruppi dei blocchi, il superblock e tutti i dati di gestione) possiamo
+esemplificare la situazione con uno schema come quello esposto in \nfig.
+
\begin{figure}[htb]
\centering
-
- \caption{Organizzazione di un filesystem}
+ \includegraphics[width=11cm]{img/filesys_struct.eps}
+ \caption{Strutturazionne dei dati all'interno di un filesystem}
\label{fig:fileintr_filesys_detail}
\end{figure}
-da questa figura si evidenziano alcune caratteristiche su cui è bene porre
-attenzione in quanto sono fondamentali per capire il funzionamento delle
-funzioni che manipolano i file e le directory su cui torneremo fra poco; in
-particolare è opportuno ricordare sempre che:
+
+Da \curfig\ si evidenziano alcune caratteristiche base di ogni filesystem su
+cui è bene porre attenzione in quanto sono fondamentali per capire il
+funzionamento delle funzioni che manipolano i file e le directory su cui
+torneremo in seguitp; in particolare è opportuno ricordare sempre che:
\begin{enumerate}
numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
solo quando questo contatore si annulla i dati del file vengono
effettivamente rimossi dal disco. Per questo la funzione per cancellare un
- file si chiama \texttt{unlink}, ed in realtà non cancella affatto i dati del
+ file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del
file, ma si limita a eliminare la relativa voce da una directory e
decrementare il numero di riferimenti nell'\textit{inode}.
\item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
nello stesso filesystem e non ci può essere una directory che contiene
riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo limita
- l'uso del comando \texttt{ln} (che crea una nuova voce per un file
- esistente, con la funzione \texttt{link}) al filesystem corrente.
+ l'uso del comando \cmd{ln} (che crea una nuova voce per un file
+ esistente, con la funzione \func{link}) al filesystem corrente.
\item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
del file non deve essere spostato, viene semplicemente creata una nuova voce
per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità
- in cui opera normalmente il comando \texttt{mv} attraverso la funzione
- \texttt{rename}).
+ in cui opera normalmente il comando \cmd{mv} attraverso la funzione
+ \func{rename}).
\end{enumerate}
Infine è bene avere presente che essendo file pure loro, esiste un numero di
riferimenti anche per le directories; per cui se ad esempio a partire dalla
-situazione mostrata in \curfig\ creiamo una nuova directory \texttt{textdir}
-nella directory corrente avremo una situazione come quella in \nfig, dove per
+situazione mostrata in \curfig\ creiamo una nuova directory \texttt{img} nella
+directory \file{gapil}: avremo una situazione come quella in \nfig, dove per
chiarezza abbiamo aggiunto dei numeri di inode.
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=11cm]{img/dir_links.eps}
+ \caption{Organizzazione dei link per le directory}
+ \label{fig:fileintr_dirs_link}
+\end{figure}
+
La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
è referenziata dalla directory da cui si era partiti (in cui è inserita la
-nuova voce che fa riferimento a \texttt{textdir}) e dalla voce \texttt{.}
+nuova voce che fa riferimento a \file{img}) e dalla voce \file{.}
che è sempre inserita in ogni directory; questo vale sempre per ogni directory
che non contenga a sua volta altre directories. Al contempo la directory da
cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto
-adesso sarà referenziata anche dalla voce \texttt{..} di \texttt{textdir}.
-
+adesso sarà referenziata anche dalla voce \file{..} di \file{img}.
\subsection{Il filesystem \texttt{ext2}}
\label{sec:fileintr_ext2}
sottodirectory ereditano sia il group id che il setgid.
\item l'amministratore può scegliere la dimensione dei blocchi del filesystem
in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
- peremttono un accesso più veloce, ma sprecano più spazio disco).
+ permettono un accesso più veloce, ma sprecano più spazio disco).
\item il filesystem implementa link simbolici veloci, in cui il nome del file
non è salvato su un blocco, ma tenuto all'interno dell'inode (evitando
letture multiple e spreco di spazio), non tutti i nomi però possono essere
\end{itemize}
La struttura di ext2 è stata ispirata a quella del filesystem di BSD, un
-filesystem è composto da un insieme di blocchi, la struttura generale è
-riportata in \nfig; su ciascun gruppo di blocchi contiene una copia delle
-informazioni essenziali del filesystem (superblock e descrittore del
-filesystem) per una maggiore affidabilità e possibilità di recupero in caso di
-corruzione del superblock principale.
+filesystem è composto da un insieme di blocchi, la struttura generale è quella
+riportata in \figref{fig:fileintr_filesys_detail}, in cui la partizione è
+divisa in gruppi di blocchi.
+
+Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
+filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
+una maggiore affidabilità e possibilità di recupero in caso di corruzione del
+superblock principale.
+
\begin{figure}[htb]
\centering
-
- \caption{Organizzazione logica del \textit{second extented filesystem}.}
- \label{fig:fileintr_ext2_struct}
+ \includegraphics[width=9cm]{img/dir_struct.eps}
+ \caption{Struttura delle directory nel \textit{second extented filesystem}.}
+ \label{fig:fileintr_ext2_dirs}
\end{figure}
L'utilizzo di raggrupamenti di blocchi ha inoltre degli effetti positivi nelle
performance dato che viene ridotta la distanza fra i dati e la tabella degli
inodes.
-Le directory sono implementate come una linked list di entrate di dimensione
-variabile. Ciascuna entry contiene il numero di inode, la sua lunghezza, il
-nome del file e la sua lunghezza.
-
+Le directory sono implementate come una linked list con voci di dimensione
+variabile. Ciascuna voce della lista contiene il numero di inode, la sua
+lunghezza, il nome del file e la sua lunghezza, secondo lo schema in \curfig;
+in questo modo è possibile implementare nomi per i file anche molto lunghi
+(fino a 1024 caratteri) senza sprecare spazio disco.
\begin{figure}[htb]
\centering
-
+ \includegraphics[width=8cm]{img/memory_layout.eps}
\caption{Disposizione tipica dei segmenti di memoria di un processo}
\label{fig:proc_mem_layout}
\end{figure}
voluta copiandoci automaticamente il contenuto, lo spazio in più non viene
inizializzato.
-Il fatto che il blocco di memoria restituito da \texttt{realloc} possa
-camabiare comporta che si deve sempre riassegnare al puntatore passato per il
+Il fatto che il blocco di memoria restituito da \func{realloc} possa
+cambiare comporta che si deve sempre riassegnare al puntatore passato per il
ridimensionamento il valore di ritorno della funzione, e che non ci devono
essere altri puntatori che puntino all'interno di un'area che si vuole
ridimensionare.
permettono di sostituire alle funzioni di libreria una propria versione (che
può essere più o meno specializzata per il debugging).
+
\subsection{La funzione \texttt{alloca}}
\label{sec:proc_mem_alloca}
Come è evidente questa funzione ha molti vantaggi, e permette di evitare i
problemi di memory leak non essendo più necessaria la deallocazione esplicita;
una delle ragioni principali per usarla è però che funziona anche quando si
-usa \texttt{longjump} per uscire con un salto non locale da una funzione (vedi
-\secref{sec:proc_longjmp}),
+usa \func{longjump} per uscire con un salto non locale da una funzione (vedi
+\secref{sec:proc_longjmp}),
Un altro vantaggio e che in Linux la funzione è molto veloce e non viene
sprecato spazio, infatti non è necessario gestire un pool di memoria da
segnale di \textit{segmentation violation} analogo a quello che si avrebbe da
una ricorsione infinita.
+Inoltre non è chiaramente possibile usare questa funzione per allocare memoria
+che deve poi essere usata anche al di fuori della funzione in cui questa viene
+chiamata, in quanto all'uscita dalla funzione lo spazio allocato diventerebbe
+libero, e potrebbe essere sovrascritto all'invocazione di nuove funzioni con
+conseguenze imprevedibili.
+
+Questo è lo stesso problema potenziale che si può avere con le variabili
+automatiche; un errore comune infatti è quello di restituire al chiamante un
+puntatore ad una di queste variabili, che sarà automaticamente distrutta
+all'uscita della funzione, con gli stessi problemi appena citati per
+\func{alloca}.
\subsection{Le funzioni \texttt{brk} e \texttt{sbrk}}
\label{sec:proc_mem_sbrk}
Il controllo del flusso di un programma in genere viene effettuato con le
varie istruzioni del linguaggio C, la più bistrattata delle quali è il
-\texttt{goto} ampiamente deprecato in favore di costrutti più puliti; esiste
+\texttt{goto}, ampiamente deprecato in favore di costrutti più puliti; esiste
però un caso in l'uso di questa istruzione porta all'implementazione più
efficiente, quello dell'uscita in caso di errore.
Oltre ai parametri passati da linea di comando ogni processo riceve dal
sistema un \textsl{ambiente}, nella forma di una lista di variabili
(\textit{environment list}) messa a disposizione dal processo costruita nella
-chiamata ad \finc{exec} che lo ha lanciato.
+chiamata ad \func{exec} che lo ha lanciato.
Come per la lista dei parametri anche questa lista è un array di puntatori a
caratteri, ciascuno dei quali punta ad una stringa (terminata da un null). A
projects / gapil.git / commitdiff