Lavoro fatto a casa senza ADSL, correzioni multiple agli indici, documentato

[gapil.git] / filestd.tex

diff --git a/filestd.tex b/filestd.tex
index ba27efab1c721dece86975c39ddaf8bb8c84c2d6..3fde1d701e18309337d44b05337ecb1789341d97 100644 (file)
--- a/filestd.tex
+++ b/filestd.tex
@@ -72,18 +72,19 @@ sez.~\ref{sec:file_access_control} per il controllo di accesso.
 \index{file!stream|)}
 
 
 \index{file!stream|)}
 
 

-\subsection{Gli oggetti \ctyp{FILE}}
+\subsection{Gli oggetti \type{FILE}}

 \label{sec:file_FILE}
 
 \label{sec:file_FILE}
 

+

 Per ragioni storiche la struttura di dati che rappresenta uno stream è stata
 Per ragioni storiche la struttura di dati che rappresenta uno stream è stata

-chiamata \ctyp{FILE}, questi oggetti sono creati dalle funzioni di libreria e
+chiamata \type{FILE}, questi oggetti sono creati dalle funzioni di libreria e

 contengono tutte le informazioni necessarie a gestire le operazioni sugli
 stream, come la posizione corrente, lo stato del buffer e degli indicatori di
 stato e di fine del file.
 
 Per questo motivo gli utenti non devono mai utilizzare direttamente o allocare
 queste strutture (che sono dei \textsl{tipi opachi}\index{tipo!opaco}) ma
 contengono tutte le informazioni necessarie a gestire le operazioni sugli
 stream, come la posizione corrente, lo stato del buffer e degli indicatori di
 stato e di fine del file.
 
 Per questo motivo gli utenti non devono mai utilizzare direttamente o allocare
 queste strutture (che sono dei \textsl{tipi opachi}\index{tipo!opaco}) ma

-usare sempre puntatori del tipo \ctyp{FILE *} ottenuti dalla libreria stessa
+usare sempre puntatori del tipo \texttt{FILE *} ottenuti dalla libreria stessa

 (tanto che in certi casi il termine di puntatore a file è diventato sinonimo
 di stream).  Tutte le funzioni della libreria che operano sui file accettano
 come argomenti solo variabili di questo tipo, che diventa accessibile
 (tanto che in certi casi il termine di puntatore a file è diventato sinonimo
 di stream).  Tutte le funzioni della libreria che operano sui file accettano
 come argomenti solo variabili di questo tipo, che diventa accessibile


@@ -113,14 +114,13 @@ definiti nell'header \file{stdio.h} che sono:
   sullo schermo.
 \end{basedescript}
 
   sullo schermo.
 \end{basedescript}
 

-Nelle \acr{glibc} \var{stdin}, \var{stdout} e \var{stderr} sono
-effettivamente tre variabili di tipo \ctyp{FILE *} che possono essere
-usate come tutte le altre, ad esempio si può effettuare una redirezione
-dell'output di un programma con il semplice codice:
-\includecodesnip{listati/redir_stdout.c}
-ma in altri sistemi queste variabili possono essere definite da macro, e
-se si hanno problemi di portabilità e si vuole essere sicuri, diventa
-opportuno usare la funzione \func{freopen}.
+Nelle \acr{glibc} \var{stdin}, \var{stdout} e \var{stderr} sono effettivamente
+tre variabili di tipo \type{FILE}\texttt{ *} che possono essere usate come
+tutte le altre, ad esempio si può effettuare una redirezione dell'output di un
+programma con il semplice codice: \includecodesnip{listati/redir_stdout.c} ma
+in altri sistemi queste variabili possono essere definite da macro, e se si
+hanno problemi di portabilità e si vuole essere sicuri, diventa opportuno
+usare la funzione \func{freopen}.

 
 
 \subsection{Le modalità di bufferizzazione}
 
 
 \subsection{Le modalità di bufferizzazione}


@@ -422,7 +422,7 @@ funzionamento di \var{errno}).
 
 Per questo motivo tutte le implementazioni delle librerie standard
 mantengono per ogni stream almeno due flag all'interno dell'oggetto
 
 Per questo motivo tutte le implementazioni delle librerie standard
 mantengono per ogni stream almeno due flag all'interno dell'oggetto

-\ctyp{FILE}, il flag di \textit{end-of-file}, che segnala che si è
+\type{FILE}, il flag di \textit{end-of-file}, che segnala che si è

 raggiunta la fine del file in lettura, e quello di errore, che segnala
 la presenza di un qualche errore nelle operazioni di input/output;
 questi due flag possono essere riletti dalle funzioni \funcd{feof} e
 raggiunta la fine del file in lettura, e quello di errore, che segnala
 la presenza di un qualche errore nelle operazioni di input/output;
 questi due flag possono essere riletti dalle funzioni \funcd{feof} e


@@ -750,14 +750,13 @@ stringa letta superi le dimensioni del buffer, si avr
 processo adiacente al buffer.\footnote{questa tecnica è spiegata in dettaglio
   e con molta efficacia nell'ormai famoso articolo di Aleph1 \cite{StS}.}
 
 processo adiacente al buffer.\footnote{questa tecnica è spiegata in dettaglio
   e con molta efficacia nell'ormai famoso articolo di Aleph1 \cite{StS}.}
 

-Questa è una delle vulnerabilità più sfruttate per guadagnare accessi
-non autorizzati al sistema (i cosiddetti \textit{exploit}), basta
-infatti inviare una stringa sufficientemente lunga ed opportunamente
-forgiata per sovrascrivere gli indirizzi di ritorno nello stack
-(supposto che la \func{gets} sia stata chiamata da una subroutine), in
-modo da far ripartire l'esecuzione nel codice inviato nella stringa
-stessa (in genere uno \textit{shell code} cioè una sezione di programma
-che lancia una shell).
+Questa è una delle vulnerabilità più sfruttate per guadagnare accessi non
+autorizzati al sistema (i cosiddetti \textit{exploit}), basta infatti inviare
+una stringa sufficientemente lunga ed opportunamente forgiata per
+sovrascrivere gli indirizzi di ritorno nello \itindex{stack} stack (supposto
+che la \func{gets} sia stata chiamata da una subroutine), in modo da far
+ripartire l'esecuzione nel codice inviato nella stringa stessa (in genere uno
+\textit{shell code} cioè una sezione di programma che lancia una shell).

 
 La funzione \func{fgets} non ha i precedenti problemi di \func{gets} in quanto
 prende in input la dimensione del buffer \param{size}, che non verrà mai
 
 La funzione \func{fgets} non ha i precedenti problemi di \func{gets} in quanto
 prende in input la dimensione del buffer \param{size}, che non verrà mai