Correzioni da parte di D. Masini

diff --git a/ChangeLog b/ChangeLog
index ae3d058674394de96fc29d7f0f4c6ad8be215e89..b1b381487e818a170d847bfaa6075d42f4b2fd13 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2002-03-19  Simone Piccardi  <piccardi@firenze.linux.it>
+
+       * fileintro.tex, filedir.tex, fileunix.tex, filestd.tex:
+       correzioni multiple da D. Masini. 
+

 2002-03-18  Simone Piccardi  <piccardi@firenze.linux.it>
 
        * fileintro.tex: Correzioni varie su suggerimenti di A. Frusciante. 
 2002-03-18  Simone Piccardi  <piccardi@firenze.linux.it>
 
        * fileintro.tex: Correzioni varie su suggerimenti di A. Frusciante. 

diff --git a/filedir.tex b/filedir.tex
index d7cfa6f9c77cb87f4a051ff65bdb44b89bc738d1..f7ce34067ad456b55f0d582acdb8b57323f15c9c 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -40,7 +40,7 @@ fare questa operazione.
 
 Come spiegato in \secref{sec:file_filesystem} l'accesso al contenuto di un
 file su disco avviene attraverso il suo inode\index{inode}, e il nome che si
 
 Come spiegato in \secref{sec:file_filesystem} l'accesso al contenuto di un
 file su disco avviene attraverso il suo inode\index{inode}, e il nome che si

-trova in una directory è solo una etichetta associata ad un puntatore a che fa
+trova in una directory è solo un'etichetta associata ad un puntatore a che fa

 riferimento al suddetto inode.
 
 Questo significa che la realizzazione di un link è immediata in quanto uno
 riferimento al suddetto inode.
 
 Questo significa che la realizzazione di un link è immediata in quanto uno


@@ -142,14 +142,14 @@ del file o proprietari della directory (o root, per cui nessuna delle
 restrizioni è applicata).
 
 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
 restrizioni è applicata).
 
 Una delle caratteristiche di queste funzioni è che la creazione/rimozione

-della nome dalla directory e l'incremento/decremento del numero di riferimenti
+del nome dalla directory e l'incremento/decremento del numero di riferimenti

 nell'inode devono essere effettuati in maniera atomica (si veda
 \secref{sec:proc_atom_oper}) senza possibili interruzioni fra le due
 nell'inode devono essere effettuati in maniera atomica (si veda
 \secref{sec:proc_atom_oper}) senza possibili interruzioni fra le due

-operazioni, per questo entrambe queste funzioni sono realizzate tramite una
+operazioni. Per questo entrambe queste funzioni sono realizzate tramite una

 singola system call.
 
 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
 singola system call.
 
 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti

-i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
+i riferimenti ad esso sono stati cancellati: solo quando il \textit{link

   count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
 questo però si aggiunge un'altra condizione, e cioè che non ci siano processi
 che abbiano detto file aperto.  
   count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
 questo però si aggiunge un'altra condizione, e cioè che non ci siano processi
 che abbiano detto file aperto.  


@@ -264,10 +264,10 @@ ad una directory.
 
 Per ovviare a queste limitazioni i sistemi Unix supportano un'altra forma di
 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
 
 Per ovviare a queste limitazioni i sistemi Unix supportano un'altra forma di
 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,

-come avviene in altri sistemi operativi, dei file speciali che contengono il
+come avviene in altri sistemi operativi, dei file speciali che contengono

 semplicemente il riferimento ad un altro file (o directory). In questo modo è
 semplicemente il riferimento ad un altro file (o directory). In questo modo è

-possibile effettuare link anche attraverso filesystem diversi, a file posti
-in filesystem che non supportano i link diretti, a delle directory, ed anche a
+possibile effettuare link anche attraverso filesystem diversi, a file posti in
+filesystem che non supportano i link diretti, a delle directory, ed anche a

 file che non esistono ancora.
 
 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
 file che non esistono ancora.
 
 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali


@@ -506,7 +506,7 @@ nuovi file nella directory.
 \label{sec:file_mknod}
 
 Finora abbiamo parlato esclusivamente di file, directory e link simbolici; in
 \label{sec:file_mknod}
 
 Finora abbiamo parlato esclusivamente di file, directory e link simbolici; in

-\secref{sec:file_file_types} abbiamo visto però che il sistema preveda pure
+\secref{sec:file_file_types} abbiamo visto però che il sistema prevede pure

 degli altri tipi di file, come i file di dispositivo e le fifo (i socket sono
 un caso a parte, che vedremo in \secref{cha:socket_intro}). 
 
 degli altri tipi di file, come i file di dispositivo e le fifo (i socket sono
 un caso a parte, che vedremo in \secref{cha:socket_intro}). 
 


@@ -609,7 +609,7 @@ struttura \var{struct dirent}.
 A ciascun processo è associato ad una directory nel filesystem che è chiamata
 directory corrente o directory di lavoro (\textit{current working directory})
 che è quella a cui si fa riferimento quando un filename è espresso in forma
 A ciascun processo è associato ad una directory nel filesystem che è chiamata
 directory corrente o directory di lavoro (\textit{current working directory})
 che è quella a cui si fa riferimento quando un filename è espresso in forma

-relativa, dove il relativa fa riferimento appunto a questa directory.
+relativa, dove il ``relativa'' fa riferimento appunto a questa directory.

 
 Quando un utente effettua il login questa directory viene settata alla
 \textit{home directory} del suo account. Il comando \cmd{cd} della shell
 
 Quando un utente effettua il login questa directory viene settata alla
 \textit{home directory} del suo account. Il comando \cmd{cd} della shell


@@ -664,9 +664,9 @@ Una seconda funzione simile 
 sostanzialmente equivalente ad una \code{getcwd(NULL, 0)}, con la sola
 differenza che essa ritorna il valore della variabile di ambiente \macro{PWD},
 che essendo costruita dalla shell può contenere un pathname comprendente anche
 sostanzialmente equivalente ad una \code{getcwd(NULL, 0)}, con la sola
 differenza che essa ritorna il valore della variabile di ambiente \macro{PWD},
 che essendo costruita dalla shell può contenere un pathname comprendente anche

-con dei link simbolici. Usando \func{getcwd} infatti, essendo il
-pathname ricavato risalendo all'indietro l'albero della directory, si
-perderebbe traccia di ogni passaggio attraverso eventuali link simbolici.
+dei link simbolici. Usando \func{getcwd} infatti, essendo il pathname ricavato
+risalendo all'indietro l'albero della directory, si perderebbe traccia di ogni
+passaggio attraverso eventuali link simbolici.

 
 Per cambiare la directory di lavoro corrente si può usare la funzione
 \func{chdir} (equivalente del comando di shell \cmd{cd}) il cui nome sta
 
 Per cambiare la directory di lavoro corrente si può usare la funzione
 \func{chdir} (equivalente del comando di shell \cmd{cd}) il cui nome sta


@@ -764,12 +764,13 @@ la prima valida delle seguenti:
 \end{itemize*}
 
 In ogni caso, anche se la generazione del nome è casuale, ed è molto difficile
 \end{itemize*}
 
 In ogni caso, anche se la generazione del nome è casuale, ed è molto difficile

-ottere un nome duplicato, nulla assicura che un altro processo non possa avere
-creato, fra l'ottenimento del nome e l'apertura del file, un altro file con lo
-stesso nome; per questo motivo quando si usa il nome ottenuto da una di queste
-funzioni occorre sempre aprire il nuovo file in modalità di esclusione (cioè
-con l'opzione \macro{O\_EXCL} per i file descriptor o con il flag \code{x} per
-gli stream) che fa fallire l'apertura in caso il file sia già esistente.
+ottenere un nome duplicato, nulla assicura che un altro processo non possa
+avere creato, fra l'ottenimento del nome e l'apertura del file, un altro file
+con lo stesso nome; per questo motivo quando si usa il nome ottenuto da una di
+queste funzioni occorre sempre aprire il nuovo file in modalità di esclusione
+(cioè con l'opzione \macro{O\_EXCL} per i file descriptor o con il flag
+\code{x} per gli stream) che fa fallire l'apertura in caso il file sia già
+esistente.

 
 Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
 POSIX definisce la funzione \func{tempfile}, il cui prototipo è:
 
 Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
 POSIX definisce la funzione \func{tempfile}, il cui prototipo è:


@@ -789,9 +790,9 @@ POSIX definisce la funzione \func{tempfile}, il cui prototipo 
 \noindent essa restituisce direttamente uno stream già aperto (in modalità
 \code{r+b}, si veda \secref{sec:file_fopen}) e pronto per l'uso, che viene
 automaticamente cancellato alla sua chiusura o all'uscita dal programma. Lo
 \noindent essa restituisce direttamente uno stream già aperto (in modalità
 \code{r+b}, si veda \secref{sec:file_fopen}) e pronto per l'uso, che viene
 automaticamente cancellato alla sua chiusura o all'uscita dal programma. Lo

-standard non specifica in quale directory verrà aperto il file, ma \acr{glibc}
-prima tentano con \macro{P\_tmpdir} e poi con \file{/tmp}. Questa funzione è
-rientrante e non soffre di problemi di \textit{race condition}.
+standard non specifica in quale directory verrà aperto il file, ma le
+\acr{glibc} prima tentano con \macro{P\_tmpdir} e poi con \file{/tmp}. Questa
+funzione è rientrante e non soffre di problemi di \textit{race condition}.

 
 Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
 caso si possono usare le vecchie funzioni \func{mktemp} e \func{mkstemp} che
 
 Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
 caso si possono usare le vecchie funzioni \func{mktemp} e \func{mkstemp} che


@@ -985,7 +986,7 @@ riportato in \ntab.
     \macro{S\_ISSOCK(m)} & socket \\
     \hline    
   \end{tabular}
     \macro{S\_ISSOCK(m)} & socket \\
     \hline    
   \end{tabular}

-  \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h})}
+  \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h}).}

   \label{tab:file_type_macro}
 \end{table}
 
   \label{tab:file_type_macro}
 \end{table}
 


@@ -1038,7 +1039,7 @@ un'opportuna combinazione.
     \hline    
   \end{tabular}
   \caption{Costanti per l'identificazione dei vari bit che compongono il campo
     \hline    
   \end{tabular}
   \caption{Costanti per l'identificazione dei vari bit che compongono il campo

-    \var{st\_mode} (definite in \file{sys/stat.h})}
+    \var{st\_mode} (definite in \file{sys/stat.h}).}

   \label{tab:file_mode_flags}
 \end{table}
 
   \label{tab:file_mode_flags}
 \end{table}
 


@@ -1065,12 +1066,12 @@ i trasferimenti sui file (che 
 per l'interfaccia degli stream); scrivere sul file a blocchi di dati di
 dimensione inferiore sarebbe inefficiente.
 
 per l'interfaccia degli stream); scrivere sul file a blocchi di dati di
 dimensione inferiore sarebbe inefficiente.
 

-Si tenga conto che lunghezza del file riportata in \var{st\_size} non è detto
-che corrisponda all'occupazione dello spazio su disco per via della possibile
-esistenza dei cosiddetti \textit{holes} (letteralmente \textsl{buchi}) che
-si formano tutte le volte che si va a scrivere su un file dopo aver eseguito
-una \func{lseek} (vedi \secref{sec:file_lseek}) oltre la sua conclusione
-corrente.
+Si tenga conto che la lunghezza del file riportata in \var{st\_size} non è
+detto che corrisponda all'occupazione dello spazio su disco per via della
+possibile esistenza dei cosiddetti \textit{holes} (letteralmente
+\textsl{buchi}) che si formano tutte le volte che si va a scrivere su un file
+dopo aver eseguito una \func{lseek} (vedi \secref{sec:file_lseek}) oltre la
+sua fine.

 
 In questo caso si avranno risultati differenti a seconda del modo in cui si
 calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
 
 In questo caso si avranno risultati differenti a seconda del modo in cui si
 calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il


@@ -1149,7 +1150,7 @@ riportato un esempio delle funzioni che effettuano cambiamenti su di essi.
     \func{utime} & \cmd{-c} \\ 
     \hline
   \end{tabular}
     \func{utime} & \cmd{-c} \\ 
     \hline
   \end{tabular}

-  \caption{I tre tempi associati a ciascun file}
+  \caption{I tre tempi associati a ciascun file.}

   \label{tab:file_file_times}
 \end{table}
 
   \label{tab:file_file_times}
 \end{table}
 


@@ -1556,12 +1557,12 @@ usati per guadagnare privilegi non consentiti (l'argomento 
 dettaglio in \secref{sec:proc_perms}).
 
 La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere rilevata con
 dettaglio in \secref{sec:proc_perms}).
 
 La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere rilevata con

-il comando \cmd{ls -l}, che una lettera \cmd{s} al posto della \cmd{x} in
-corrispondenza dei permessi di utente o gruppo. La stessa lettera \cmd{s} può
-essere usata nel comando \cmd{chmod} per settare questi bit. Infine questi bit
-possono essere controllati all'interno di \var{st\_mode} con l'uso delle due
-costanti \macro{S\_ISUID} e \macro{S\_IGID}, i cui valori sono riportati in
-\tabref{tab:file_mode_flags}.
+il comando \cmd{ls -l}, che visualizza una lettera \cmd{s} al posto della
+\cmd{x} in corrispondenza dei permessi di utente o gruppo. La stessa lettera
+\cmd{s} può essere usata nel comando \cmd{chmod} per settare questi bit.
+Infine questi bit possono essere controllati all'interno di \var{st\_mode} con
+l'uso delle due costanti \macro{S\_ISUID} e \macro{S\_IGID}, i cui valori sono
+riportati in \tabref{tab:file_mode_flags}.

 
 Gli stessi bit vengono ad assumere in significato completamente diverso per le
 directory, normalmente infatti Linux usa la convenzione di SVR4 per indicare
 
 Gli stessi bit vengono ad assumere in significato completamente diverso per le
 directory, normalmente infatti Linux usa la convenzione di SVR4 per indicare


@@ -1570,7 +1571,7 @@ veda \secref{sec:file_ownership} per una spiegazione dettagliata al
 proposito).
 
 Infine Linux utilizza il bit \acr{sgid} per una ulteriore estensione mutuata
 proposito).
 
 Infine Linux utilizza il bit \acr{sgid} per una ulteriore estensione mutuata

-da SVR4. Il caso in cui un file ha il bit \acr{sgid} settato senza che lo sia
+da SVr4. Il caso in cui un file ha il bit \acr{sgid} settato senza che lo sia

 anche il corrispondente bit di esecuzione viene utilizzato per attivare per
 quel file il \textit{mandatory locking} (argomento che affronteremo in
 dettagliopiù avanti in \secref{sec:file_mand_locking}).
 anche il corrispondente bit di esecuzione viene utilizzato per attivare per
 quel file il \textit{mandatory locking} (argomento che affronteremo in
 dettagliopiù avanti in \secref{sec:file_mand_locking}).


@@ -1655,7 +1656,7 @@ automaticamente propagato, restando coerente a quello della directory di
 partenza, in tutte le sottodirectory. La semantica SVr4 offre la possibilità
 di scegliere, ma per ottenere lo stesso risultato di coerenza che si ha con
 BSD necessita che per le nuove directory venga anche propagato anche il bit
 partenza, in tutte le sottodirectory. La semantica SVr4 offre la possibilità
 di scegliere, ma per ottenere lo stesso risultato di coerenza che si ha con
 BSD necessita che per le nuove directory venga anche propagato anche il bit

-\acr{sgid}. Questo è il comportamento di default di \func{mkdir}, ed é in
+\acr{sgid}. Questo è il comportamento di default di \func{mkdir}, ed è in

 questo modo ad esempio che Debian assicura che le sottodirectory create nelle
 home di un utente restino sempre con il \acr{gid} del gruppo primario dello
 stesso.
 questo modo ad esempio che Debian assicura che le sottodirectory create nelle
 home di un utente restino sempre con il \acr{gid} del gruppo primario dello
 stesso.


@@ -1713,7 +1714,7 @@ contrario (o di errore) ritorna -1.
     \hline
   \end{tabular}
   \caption{Valori possibile per il parametro \var{mode} della funzione 
     \hline
   \end{tabular}
   \caption{Valori possibile per il parametro \var{mode} della funzione 

-    \func{access}}
+    \func{access}.}

   \label{tab:file_access_mode_val}
 \end{table}
 
   \label{tab:file_access_mode_val}
 \end{table}
 


@@ -1814,7 +1815,7 @@ particolare:
 
 Per alcuni filesystem\footnote{il filesystem \acr{ext2} supporta questa
   caratteristica, che è mutuata da BSD.} è inoltre prevista una ulteriore
 
 Per alcuni filesystem\footnote{il filesystem \acr{ext2} supporta questa
   caratteristica, che è mutuata da BSD.} è inoltre prevista una ulteriore

-misura di sicurezza, volta ad scongiurare l'abuso dei bit \acr{suid} e
+misura di sicurezza, volta a scongiurare l'abuso dei bit \acr{suid} e

 \acr{sgid}; essa consiste nel cancellare automaticamente questi bit qualora un
 processo che non appartenga all'amministratore scriva su un file. In questo
 modo anche se un utente malizioso scopre un file \acr{suid} su cui può
 \acr{sgid}; essa consiste nel cancellare automaticamente questi bit qualora un
 processo che non appartenga all'amministratore scriva su un file. In questo
 modo anche se un utente malizioso scopre un file \acr{suid} su cui può


@@ -1897,7 +1898,7 @@ cambiare il gruppo dei file che gli appartengono solo se il nuovo gruppo 
 suo gruppo primario o uno dei gruppi a cui appartiene.
 
 La funzione \func{chown} segue i link simbolici, per operare direttamente su
 suo gruppo primario o uno dei gruppi a cui appartiene.
 
 La funzione \func{chown} segue i link simbolici, per operare direttamente su

-in link simbolico si deve usare la funzione \func{lchown}.\footnote{fino alla
+un link simbolico si deve usare la funzione \func{lchown}.\footnote{fino alla

   versione 2.1.81 in Linux \func{chown} non seguiva i link simbolici, da
   allora questo comportamento è stato assegnato alla funzione \func{lchown},
   introdotta per l'occasione, ed è stata creata una nuova system call per
   versione 2.1.81 in Linux \func{chown} non seguiva i link simbolici, da
   allora questo comportamento è stato assegnato alla funzione \func{lchown},
   introdotta per l'occasione, ed è stata creata una nuova system call per

diff --git a/fileintro.tex b/fileintro.tex
index 2dce07e878e8190bf31b8c060e5bbd8e42e35212..0632b7a8fade79cc6f1094d378e1b91dd3a69e7a 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -25,13 +25,13 @@ delle modalit
 \section{L'architettura generale}
 \label{sec:file_access_arch}
 
 \section{L'architettura generale}
 \label{sec:file_access_arch}
 

-Per poter accedere ai file il kernel deve mettere a disposizione dei programmi
-le opportune interfacce che consentano di leggerne il contenuto; il sistema
-cioè deve provvedere ad organizzare e rendere accessibile in maniera opportuna
-l'informazione tenuta sullo spazio grezzo disponibile sui dischi. Questo viene
-fatto strutturando l'informazione sul disco attraverso quello che si chiama un
-\textit{filesystem} (vedi \ref{sec:file_arch_func}), essa poi viene resa
-disponibile ai processi attraverso quello che viene chiamato il
+Per poter accedere ai file, il kernel deve mettere a disposizione dei
+programmi le opportune interfacce che consentano di leggerne il contenuto; il
+sistema cioè deve provvedere ad organizzare e rendere accessibile in maniera
+opportuna l'informazione tenuta sullo spazio grezzo disponibile sui dischi.
+Questo viene fatto strutturando l'informazione sul disco attraverso quello che
+si chiama un \textit{filesystem} (vedi \ref{sec:file_arch_func}), essa poi
+viene resa disponibile ai processi attraverso quello che viene chiamato il

 \textsl{montaggio} del \textit{filesystem}.
 % (approfondiremo tutto ciò in \secref{sec:file_arch_func}).
 
 \textsl{montaggio} del \textit{filesystem}.
 % (approfondiremo tutto ciò in \secref{sec:file_arch_func}).
 


@@ -118,7 +118,7 @@ questa sia la directory radice, allora il riferimento 
 \subsection{I tipi di file}
 \label{sec:file_file_types}
 
 \subsection{I tipi di file}
 \label{sec:file_file_types}
 

-Come detto in precedenza in Unix esistono vari tipi di file; in Linux questi
+Come detto in precedenza, in Unix esistono vari tipi di file; in Linux questi

 sono implementati come oggetti del \textit{Virtual File System} (vedi
 \secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal
 sono implementati come oggetti del \textit{Virtual File System} (vedi
 \secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal


@@ -170,7 +170,7 @@ per il cosiddetto ``accesso diretto'' come nel caso del VMS.\footnote{con i
   ha nulla a che fare con questo, trattandosi solo di operazioni fatte senza
   passare attraverso un filesystem.}
 
   ha nulla a che fare con questo, trattandosi solo di operazioni fatte senza
   passare attraverso un filesystem.}
 

-Una seconda differenza è nel formato dei file ASCII; in Unix la fine riga è
+Una seconda differenza è nel formato dei file ASCII: in Unix la fine riga è

 codificata in maniera diversa da Windows o Mac, in particolare il fine riga è
 il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR} (\verb|\r|)
 del Mac e del \texttt{CR LF} di Windows.\footnote{per questo esistono in Linux
 codificata in maniera diversa da Windows o Mac, in particolare il fine riga è
 il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR} (\verb|\r|)
 del Mac e del \texttt{CR LF} di Windows.\footnote{per questo esistono in Linux


@@ -335,21 +335,22 @@ strato intermedio che il kernel usa per accedere ai pi
 mantenendo la stessa interfaccia per i programmi in user space. Esso fornisce
 un livello di indirezione che permette di collegare le operazioni di
 manipolazione sui file alle operazioni di I/O, e gestisce l'organizzazione di
 mantenendo la stessa interfaccia per i programmi in user space. Esso fornisce
 un livello di indirezione che permette di collegare le operazioni di
 manipolazione sui file alle operazioni di I/O, e gestisce l'organizzazione di

-queste ultime nei vari modi in cui diversi filesystem le effettuano,
+queste ultime nei vari modi in cui i diversi filesystem le effettuano,

 permettendo la coesistenza di filesystem differenti all'interno dello stesso
 albero delle directory.
 
 permettendo la coesistenza di filesystem differenti all'interno dello stesso
 albero delle directory.
 

-Quando un processo esegue una system call che opera su un file il kernel
+Quando un processo esegue una system call che opera su un file, il kernel

 chiama sempre una funzione implementata nel VFS; la funzione eseguirà le
 chiama sempre una funzione implementata nel VFS; la funzione eseguirà le

-manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alla
+manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alle

 opportune routine del filesystem specifico a cui si fa riferimento. Saranno
 queste a chiamare le funzioni di più basso livello che eseguono le operazioni
 opportune routine del filesystem specifico a cui si fa riferimento. Saranno
 queste a chiamare le funzioni di più basso livello che eseguono le operazioni

-di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig.
+di I/O sul dispositivo fisico, secondo lo schema riportato in
+\figref{fig:file_VFS_scheme}.

 
 \begin{figure}[htb]
   \centering
   \includegraphics[width=7cm]{img/vfs}
 
 \begin{figure}[htb]
   \centering
   \includegraphics[width=7cm]{img/vfs}

-  \caption{Schema delle operazioni del VFS}
+  \caption{Schema delle operazioni del VFS.}

   \label{fig:file_VFS_scheme}
 \end{figure}
 
   \label{fig:file_VFS_scheme}
 \end{figure}
 


@@ -475,12 +476,12 @@ operazioni previste dal kernel 
 
 In questo modo per ciascun file diventano possibili una serie di operazioni
 (non è detto che tutte siano disponibili), che costituiscono l'interfaccia
 
 In questo modo per ciascun file diventano possibili una serie di operazioni
 (non è detto che tutte siano disponibili), che costituiscono l'interfaccia

-astratta del VFS.  Qualora se ne voglia eseguire una il kernel andrà ad
-utilizzare la opportuna routine dichiarata in \var{f\_ops} appropriata al tipo
+astratta del VFS.  Qualora se ne voglia eseguire una, il kernel andrà ad
+utilizzare l'opportuna routine dichiarata in \var{f\_ops} appropriata al tipo

 di file in questione.
 
 In questo modo è possibile scrivere allo stesso modo sulla porta seriale come
 di file in questione.
 
 In questo modo è possibile scrivere allo stesso modo sulla porta seriale come

-su un file di dati normale; ovviamente certe operazioni (nel caso della
+su normale un file di dati; ovviamente certe operazioni (nel caso della

 seriale ad esempio la \code{seek}) non saranno disponibili, però con questo
 sistema l'utilizzo di diversi filesystem (come quelli usati da Windows o
 MacOs) è immediato e (relativamente) trasparente per l'utente ed il
 seriale ad esempio la \code{seek}) non saranno disponibili, però con questo
 sistema l'utilizzo di diversi filesystem (come quelli usati da Windows o
 MacOs) è immediato e (relativamente) trasparente per l'utente ed il


@@ -493,9 +494,9 @@ programmatore.
 Come già accennato in \secref{sec:file_organization} Linux (ed ogni sistema
 unix-like) organizza i dati che tiene su disco attraverso l'uso di un
 filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
 Come già accennato in \secref{sec:file_organization} Linux (ed ogni sistema
 unix-like) organizza i dati che tiene su disco attraverso l'uso di un
 filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è

-quella di poter supportare grazie al VFS una enorme quantità di filesystem
+quella di poter supportare, grazie al VFS, una enorme quantità di filesystem

 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità

-proprie.  Per questo per il momento non entreremo nei dettagli di un
+proprie.  Per questo, per il momento non entreremo nei dettagli di un

 filesystem specifico, ma daremo una descrizione a grandi linee che si adatta
 alle caratteristiche comuni di qualunque filesystem di sistema unix-like.
 
 filesystem specifico, ma daremo una descrizione a grandi linee che si adatta
 alle caratteristiche comuni di qualunque filesystem di sistema unix-like.
 


@@ -512,7 +513,8 @@ lista degli inodes e lo spazio a disposizione per i dati e le directory.
 \begin{figure}[htb]
   \centering
   \includegraphics[width=12cm]{img/disk_struct}
 \begin{figure}[htb]
   \centering
   \includegraphics[width=12cm]{img/disk_struct}

-  \caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
+  \caption{Organizzazione dello spazio su un disco in partizioni e
+  filesystem.}

   \label{fig:file_disk_filesys}
 \end{figure}
 
   \label{fig:file_disk_filesys}
 \end{figure}
 


@@ -525,7 +527,7 @@ esemplificare la situazione con uno schema come quello esposto in \nfig.
 \begin{figure}[htb]
   \centering
   \includegraphics[width=12cm]{img/filesys_struct}
 \begin{figure}[htb]
   \centering
   \includegraphics[width=12cm]{img/filesys_struct}

-  \caption{Strutturazione dei dati all'interno di un filesystem}
+  \caption{Strutturazione dei dati all'interno di un filesystem.}

   \label{fig:file_filesys_detail}
 \end{figure}
 
   \label{fig:file_filesys_detail}
 \end{figure}
 


@@ -553,7 +555,7 @@ ricordare sempre che:
   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 \func{unlink}, ed in realtà non cancella affatto i dati del
   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 \func{unlink}, ed in realtà non cancella affatto i dati del

-  file, ma si limita a eliminare la relativa voce da una directory e
+  file, ma si limita ad 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}
   decrementare il numero di riferimenti nell'\textit{inode}.
 
 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}


@@ -561,25 +563,25 @@ ricordare sempre che:
   riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo limita
   l'uso del comando \cmd{ln} (che crea una nuova voce per un file
   esistente, con la funzione \func{link}) al filesystem corrente.
   riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo limita
   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 \cmd{mv} attraverso la funzione
-  \func{rename}).
+  
+\item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto
+  del file non viene spostato fisicamente, 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 \cmd{mv} attraverso la
+  funzione \func{rename}).

 
 \end{enumerate}
 
 Infine è bene avere presente che, essendo file pure loro, esiste un numero di
 
 \end{enumerate}
 
 Infine è bene avere presente che, essendo file pure loro, esiste un numero di

-riferimenti anche per le directory; per cui se a partire dalla situazione
+riferimenti anche per le directory; per cui, se a partire dalla situazione

 mostrata in \curfig\ creiamo una nuova directory \file{img} nella directory
 mostrata in \curfig\ creiamo una nuova directory \file{img} nella directory

-\file{gapil}: avremo una situazione come quella in \nfig, dove per chiarezza
+\file{gapil}, avremo una situazione come quella in \nfig, dove per chiarezza

 abbiamo aggiunto dei numeri di inode.
 
 \begin{figure}[htb]
   \centering 
   \includegraphics[width=12cm]{img/dir_links}
 abbiamo aggiunto dei numeri di inode.
 
 \begin{figure}[htb]
   \centering 
   \includegraphics[width=12cm]{img/dir_links}

-  \caption{Organizzazione dei link per le directory}
+  \caption{Organizzazione dei link per le directory.}

   \label{fig:file_dirs_link}
 \end{figure}
 
   \label{fig:file_dirs_link}
 \end{figure}
 


@@ -587,8 +589,8 @@ La nuova directory avr
 è referenziata dalla directory da cui si era partiti (in cui è inserita la
 nuova voce che fa riferimento a \file{img}) e dalla voce \file{.}
 che è sempre inserita in ogni directory; questo vale sempre per ogni directory
 è referenziata dalla directory da cui si era partiti (in cui è inserita la
 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 directory. Al contempo la directory da
-cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto
+che non contenga a sua volta altre directory. Al contempo, la directory da
+cui si era partiti avrà un numero di riferimenti di almeno tre, in quanto

 adesso sarà referenziata anche dalla voce \file{..} di \file{img}.
 
 
 adesso sarà referenziata anche dalla voce \file{..} di \file{img}.
 
 


@@ -598,11 +600,11 @@ adesso sar
 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
   filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le
 caratteristiche di un filesystem standard Unix, è in grado di gestire nomi di
 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
   filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le
 caratteristiche di un filesystem standard Unix, è in grado di gestire nomi di

-file lunghi (256 caratteri, estendibili a 1012), una dimensione fino a 4~Tb.
+file lunghi (256 caratteri, estendibili a 1012) con una dimensione massima di
+4~Tb.

 
 

-Oltre alle caratteristiche standard \acr{ext2} fornisce alcune estensioni che
-non sono presenti sugli altri filesystem Unix, le cui principali sono le
-seguenti:
+Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che
+non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti:

 \begin{itemize}
 \item i \textit{file attributes} consentono di modificare il comportamento del
   kernel quando agisce su gruppi di file. Possono essere settati su file e
 \begin{itemize}
 \item i \textit{file attributes} consentono di modificare il comportamento del
   kernel quando agisce su gruppi di file. Possono essere settati su file e

diff --git a/filestd.tex b/filestd.tex
index 5e6cdecf0f569fa061ca00e40958b9d2cff8343c..aa4d1ccfa3e1475b45e4fd019cca5e5acad96e7d 100644 (file)
--- a/filestd.tex
+++ b/filestd.tex
@@ -26,7 +26,7 @@ costituire il nucleo\footnote{queste funzioni sono state implementate la prima
 \subsection{I \textit{file stream}}
 \label{sec:file_stream}
 
 \subsection{I \textit{file stream}}
 \label{sec:file_stream}
 

-Come più volte ribadito l'interfaccia dei file descriptor è una interfaccia di
+Come più volte ribadito l'interfaccia dei file descriptor è un'interfaccia di

 basso livello, che non provvede nessuna forma di formattazione dei dati e
 nessuna forma di bufferizzazione per ottimizzare le operazioni di I/O.
 
 basso livello, che non provvede nessuna forma di formattazione dei dati e
 nessuna forma di bufferizzazione per ottimizzare le operazioni di I/O.
 


@@ -92,10 +92,10 @@ definiti nell'header \file{stdio.h} che sono:
   cui il processo riceve ordinariamente i dati in ingresso. Normalmente
   è associato dalla shell all'input del terminale e prende i caratteri
   dalla tastiera.
   cui il processo riceve ordinariamente i dati in ingresso. Normalmente
   è associato dalla shell all'input del terminale e prende i caratteri
   dalla tastiera.

-\item[\var{FILE *stdout}] Lo \textit{standard input} cioè lo stream su
+\item[\var{FILE *stdout}] Lo \textit{standard output} cioè lo stream su

   cui il processo invia ordinariamente i dati in uscita. Normalmente è
   associato dalla shell all'output del terminale e scrive sullo schermo.
   cui il processo invia ordinariamente i dati in uscita. Normalmente è
   associato dalla shell all'output del terminale e scrive sullo schermo.

-\item[\var{FILE *stderr}] Lo \textit{standard input} cioè lo stream su
+\item[\var{FILE *stderr}] Lo \textit{standard error} cioè lo stream su

   cui il processo è supposto inviare i messaggi di errore. Normalmente
   anch'esso è associato dalla shell all'output del terminale e scrive
   sullo schermo.
   cui il processo è supposto inviare i messaggi di errore. Normalmente
   anch'esso è associato dalla shell all'output del terminale e scrive
   sullo schermo.


@@ -121,7 +121,7 @@ La bufferizzazione 
 interfaccia degli stream; lo scopo è quello di ridurre al minimo il
 numero di system call (\func{read} o \func{write}) eseguite nelle
 operazioni di input/output. Questa funzionalità è assicurata
 interfaccia degli stream; lo scopo è quello di ridurre al minimo il
 numero di system call (\func{read} o \func{write}) eseguite nelle
 operazioni di input/output. Questa funzionalità è assicurata

-automaticamente dalla libreria, ma costituisce anche una degli aspetti
+automaticamente dalla libreria, ma costituisce anche uno degli aspetti

 più comunemente fraintesi, in particolare per quello che riguarda
 l'aspetto della scrittura dei dati sul file.
 
 più comunemente fraintesi, in particolare per quello che riguarda
 l'aspetto della scrittura dei dati sul file.
 


@@ -280,7 +280,7 @@ possono essere aperti con le funzioni delle librerie standard del C.
     \hline
   \end{tabular}
   \caption{Modalità di apertura di uno stream dello standard ANSI C che
     \hline
   \end{tabular}
   \caption{Modalità di apertura di uno stream dello standard ANSI C che

-    sono sempre presenti in qualunque sistema POSIX}
+    sono sempre presenti in qualunque sistema POSIX.}

   \label{tab:file_fopen_mode}
 \end{table}
 
   \label{tab:file_fopen_mode}
 \end{table}
 


@@ -321,7 +321,7 @@ valore \macro{S\_IRUSR|S\_IWUSR|S\_IRGRP|S\_IWGRP|S\_IROTH|S\_IWOTH}
 processo (si veda \secref{sec:file_umask}).
 
 In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è
 processo (si veda \secref{sec:file_umask}).
 
 In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è

-di messo una bufferizzazione; per questo motivo lo standard ANSI C
+di mezzo una bufferizzazione; per questo motivo lo standard ANSI C

 richiede che ci sia un'operazione di posizionamento fra un'operazione
 di output ed una di input o viceversa (eccetto il caso in cui l'input ha
 incontrato la fine del file), altrimenti una lettura può ritornare anche
 richiede che ci sia un'operazione di posizionamento fra un'operazione
 di output ed una di input o viceversa (eccetto il caso in cui l'input ha
 incontrato la fine del file), altrimenti una lettura può ritornare anche


@@ -601,7 +601,7 @@ viene implementata con una macro, per cui occorre stare attenti a cosa
 le si passa come argomento, infatti \param{stream} può essere valutato
 più volte nell'esecuzione, e non viene passato in copia con il
 meccanismo visto in \secref{sec:proc_var_passing}; per questo motivo se
 le si passa come argomento, infatti \param{stream} può essere valutato
 più volte nell'esecuzione, e non viene passato in copia con il
 meccanismo visto in \secref{sec:proc_var_passing}; per questo motivo se

-si passa una espressione si possono avere effetti indesiderati.
+si passa un'espressione si possono avere effetti indesiderati.

 
 Invece \func{fgetc} è assicurata essere sempre una funzione, per questo
 motivo la sua esecuzione normalmente è più lenta per via dell'overhead
 
 Invece \func{fgetc} è assicurata essere sempre una funzione, per questo
 motivo la sua esecuzione normalmente è più lenta per via dell'overhead


@@ -1155,7 +1155,7 @@ Entrambe le funzioni prendono come parametro \param{strptr} che deve essere
 l'indirizzo di un puntatore ad una stringa di caratteri, in cui verrà
 restituito (si ricordi quanto detto in \secref{sec:proc_var_passing} a
 proposito dei \textit{value result argument}) l'indirizzo della stringa
 l'indirizzo di un puntatore ad una stringa di caratteri, in cui verrà
 restituito (si ricordi quanto detto in \secref{sec:proc_var_passing} a
 proposito dei \textit{value result argument}) l'indirizzo della stringa

-allogata automaticamente dalle funzioni. Occorre inoltre ricordarsi di
+allocata automaticamente dalle funzioni. Occorre inoltre ricordarsi di

 invocare \func{free} per liberare detto puntatore quando la stringa non serve
 più, onde evitare memory leak.
 
 invocare \func{free} per liberare detto puntatore quando la stringa non serve
 più, onde evitare memory leak.
 

diff --git a/fileunix.tex b/fileunix.tex
index cacce238b486c7ad5e557067b3341e1c1530f710..fbc65cd02b6a267506ba8b866ce9eebb03330447 100644 (file)
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -13,7 +13,7 @@ dallo standard ANSI C che affronteremo al \capref{cha:files_std_interface}.
 \section{L'architettura di base}
 \label{sec:file_base_arch}
 
 \section{L'architettura di base}
 \label{sec:file_base_arch}
 

-In questa sezione faremo una breve introduzione sulla architettura su cui è
+In questa sezione faremo una breve introduzione sull'architettura su cui è

 basata dell'interfaccia dei \textit{file descriptor}, che, sia pure con
 differenze nella realizzazione pratica, resta sostanzialmente la stessa in
 tutte le implementazione di un sistema unix-like.
 basata dell'interfaccia dei \textit{file descriptor}, che, sia pure con
 differenze nella realizzazione pratica, resta sostanzialmente la stessa in
 tutte le implementazione di un sistema unix-like.


@@ -81,7 +81,7 @@ varie strutture di dati sulla quale essa 
   \centering
   \includegraphics[width=13cm]{img/procfile}
   \caption{Schema della architettura dell'accesso ai file attraverso
   \centering
   \includegraphics[width=13cm]{img/procfile}
   \caption{Schema della architettura dell'accesso ai file attraverso

-  l'interfaccia dei \textit{file descriptor}}
+  l'interfaccia dei \textit{file descriptor}.}

   \label{fig:file_proc_file}
 \end{figure}
 Ritorneremo su questo schema più volte, dato che esso è fondamentale per
   \label{fig:file_proc_file}
 \end{figure}
 Ritorneremo su questo schema più volte, dato che esso è fondamentale per


@@ -317,7 +317,7 @@ Il nuovo file descriptor non 
 sulla condivisione dei file, in genere accessibile dopo una \func{fork}, in
 \secref{sec:file_sharing}). Il nuovo file descriptor è settato di default per
 restare aperto attraverso una \func{exec} (come accennato in
 sulla condivisione dei file, in genere accessibile dopo una \func{fork}, in
 \secref{sec:file_sharing}). Il nuovo file descriptor è settato di default per
 restare aperto attraverso una \func{exec} (come accennato in

-\secref{sec:proc_exec}) ed l'offset è settato all'inizio del file.
+\secref{sec:proc_exec}) e l'offset è settato all'inizio del file.

 
 L'argomento \param{mode} specifica i permessi con cui il file viene
 eventualmente creato; i valori possibili sono gli stessi già visti in
 
 L'argomento \param{mode} specifica i permessi con cui il file viene
 eventualmente creato; i valori possibili sono gli stessi già visti in

diff --git a/prochand.tex b/prochand.tex
index cc64ab80a9210683e22b5e6b6bf61cdf0a1d6356..4bd9a46c034a1d34de5fcae5775838f1e71b6d5d 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -1423,11 +1423,11 @@ processo, come copie dell'\textit{effective user id} e dell'\textit{effective
 fossero utente e gruppo effettivi all'inizio dell'esecuzione di un nuovo
 programma.
 
 fossero utente e gruppo effettivi all'inizio dell'esecuzione di un nuovo
 programma.
 

-Il \textit{filesystem user id} e il \textit{filesystem group id} sono una
-estensione introdotta in Linux per rendere più sicuro l'uso di NFS (torneremo
-sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una replica dei
-corrispondenti \textit{effective id}, ai quali si sostituiscono per tutte le
-operazioni di verifica dei permessi relativi ai file (trattate in
+Il \textit{filesystem user id} e il \textit{filesystem group id} sono
+un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
+(torneremo sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una
+replica dei corrispondenti \textit{effective id}, ai quali si sostituiscono
+per tutte le operazioni di verifica dei permessi relativi ai file (trattate in

 \secref{sec:file_perm_overview}).  Ogni cambiamento effettuato sugli
 \textit{effective id} viene automaticamente riportato su di essi, per cui in
 condizioni normali se ne può tranquillamente ignorare l'esistenza, in quanto
 \secref{sec:file_perm_overview}).  Ogni cambiamento effettuato sugli
 \textit{effective id} viene automaticamente riportato su di essi, per cui in
 condizioni normali se ne può tranquillamente ignorare l'esistenza, in quanto


@@ -1587,9 +1587,10 @@ Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
 si porrebbe per i \textit{saved id}: queste funzioni derivano da
 un'implementazione che non ne prevede la presenza, e quindi non è possibile
 usarle per correggere la situazione come nel caso precedente. Per questo
 si porrebbe per i \textit{saved id}: queste funzioni derivano da
 un'implementazione che non ne prevede la presenza, e quindi non è possibile
 usarle per correggere la situazione come nel caso precedente. Per questo

-motivo in Linux tutte le volte che vengono usate per modificare uno degli
-identificatori ad un valore diverso dal \textit{real id} precedente, il
-\textit{saved id} viene sempre settato al valore dell'\textit{effective id}.
+motivo in Linux tutte le volte che tali funzioni vengono usate per modificare
+uno degli identificatori ad un valore diverso dal \textit{real id} precedente,
+il \textit{saved id} viene sempre settato al valore dell'\textit{effective
+  id}.

 
 
 
 
 
 


@@ -2047,6 +2048,7 @@ le strutture. In tutti questi casi 
 condiviso, onde evitare problemi con le ottimizzazioni del codice.
 
 
 condiviso, onde evitare problemi con le ottimizzazioni del codice.
 
 

+

 \subsection{Le \textit{race condition} e i \textit{deadlock}}
 \label{sec:proc_race_cond}
 
 \subsection{Le \textit{race condition} e i \textit{deadlock}}
 \label{sec:proc_race_cond}
 


@@ -2068,7 +2070,7 @@ funzioner
 
 Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
 che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
 
 Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
 che l'unico modo per evitarle è quello di riconoscerle come tali e prendere

-gli adeguati provvedimenti per far si che non si verifichino. Casi tipici di
+gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di

 \textit{race condition} si hanno quando diversi processi accedono allo stesso
 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
 condivisa. In questi casi, se non si dispone della possibilità di eseguire
 \textit{race condition} si hanno quando diversi processi accedono allo stesso
 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
 condivisa. In questi casi, se non si dispone della possibilità di eseguire


@@ -2114,12 +2116,12 @@ mai rientrante se usa una variabile globale o statica.
 Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
 cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
 ogni volta e ritornato indietro la funzione può essere rientrante, se invece
 Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
 cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
 ogni volta e ritornato indietro la funzione può essere rientrante, se invece

-esso viene individuato dalla funzione stessa, due chiamate alla stessa
-funzione potranno interferire quando entrambe faranno riferimento allo stesso
-oggetto.  Allo stesso modo una funzione può non essere rientrante se usa e
-modifica un oggetto che le viene fornito dal chiamante: due chiamate possono
-interferire se viene passato lo stesso oggetto; in tutti questi casi occorre
-molta cura da parte del programmatore.
+esso viene individuato dalla funzione stessa due chiamate alla stessa funzione
+potranno interferire quando entrambe faranno riferimento allo stesso oggetto.
+Allo stesso modo una funzione può non essere rientrante se usa e modifica un
+oggetto che le viene fornito dal chiamante: due chiamate possono interferire
+se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
+parte del programmatore.

 
 In genere le funzioni di libreria non sono rientranti, molte di esse ad
 esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
 
 In genere le funzioni di libreria non sono rientranti, molte di esse ad
 esempio utilizzano variabili statiche, le \acr{glibc} però mettono a