X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filestd.tex;h=3fde1d701e18309337d44b05337ecb1789341d97;hp=ba27efab1c721dece86975c39ddaf8bb8c84c2d6;hb=6f8e0ca42d3d0b97b5e5747798a1eaffb44e8521;hpb=fa6f00d7ff97c2b7e88a40885be73ae54824f139

diff --git a/filestd.tex b/filestd.tex
index ba27efa..3fde1d7 100644
--- a/filestd.tex
+++ b/filestd.tex
@@ -72,18 +72,19 @@ sez.~\ref{sec:file_access_control} per il controllo di accesso.
 \index{file!stream|)}
 
 
-\subsection{Gli oggetti \ctyp{FILE}}
+\subsection{Gli oggetti \type{FILE}}
 \label{sec:file_FILE}
 
+
 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
-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
@@ -113,14 +114,13 @@ definiti nell'header \file{stdio.h} che sono:
   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}
@@ -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
-\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
@@ -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}.}
 
-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