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

[gapil.git] / filestd.tex

diff --git a/filestd.tex b/filestd.tex
index 4526eb060e876555a25d3b878ad9470d86636332..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


@@ -746,19 +746,17 @@ viene restituito un \val{NULL}, ed il buffer \param{buf} non viene toccato.
 L'uso di \func{gets} è deprecato e deve essere assolutamente evitato; la
 funzione infatti non controlla il numero di byte letti, per cui nel caso la
 stringa letta superi le dimensioni del buffer, si avrà un \textit{buffer
 L'uso di \func{gets} è deprecato e deve essere assolutamente evitato; la
 funzione infatti non controlla il numero di byte letti, per cui nel caso la
 stringa letta superi le dimensioni del buffer, si avrà un \textit{buffer

-  overflow}\index{\textit{buffer~overflow}}, con sovrascrittura della memoria
-del 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).
+  overflow}\itindex{buffer~overflow}, con sovrascrittura della memoria del
+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 \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


@@ -864,10 +862,10 @@ contenente le dimensioni del buffer suddetto.
 
 Se il buffer di destinazione è sufficientemente ampio la stringa viene scritta
 subito, altrimenti il buffer viene allargato usando \func{realloc} e la nuova
 
 Se il buffer di destinazione è sufficientemente ampio la stringa viene scritta
 subito, altrimenti il buffer viene allargato usando \func{realloc} e la nuova

-dimensione ed il nuovo puntatore vengono passata indietro (si noti infatti
+dimensione ed il nuovo puntatore vengono restituiti indietro (si noti infatti

 come per entrambi gli argomenti si siano usati dei
 come per entrambi gli argomenti si siano usati dei

-\index{\textit{value~result~argument}}\textit{value result argument}, passando
-dei puntatori anziché i valori delle variabili, secondo la tecnica spiegata in
+\itindex{value~result~argument}\textit{value result argument}, passando dei
+puntatori anziché i valori delle variabili, secondo la tecnica spiegata in

 sez.~\ref{sec:proc_var_passing}).
 
 Se si passa alla funzione l'indirizzo di un puntatore impostato a \val{NULL} e
 sez.~\ref{sec:proc_var_passing}).
 
 Se si passa alla funzione l'indirizzo di un puntatore impostato a \val{NULL} e


@@ -876,7 +874,7 @@ necessaria a contenere la linea. In tutti i casi si ottiene dalla funzione un
 puntatore all'inizio del testo della linea letta. Un esempio di codice può
 essere il seguente: 
 \includecodesnip{listati/getline.c} 
 puntatore all'inizio del testo della linea letta. Un esempio di codice può
 essere il seguente: 
 \includecodesnip{listati/getline.c} 

-e per evitare memory leak\index{\textit{memory~leak}} occorre ricordarsi di
+e per evitare \textit{memory leak}\itindex{memory~leak} occorre ricordarsi di

 liberare \var{ptr} con una \func{free}.
 
 Il valore di ritorno della funzione indica il numero di caratteri letti
 liberare \var{ptr} con una \func{free}.
 
 Il valore di ritorno della funzione indica il numero di caratteri letti


@@ -931,9 +929,8 @@ quello specificato) la terza permette di stampare su una stringa, in genere
 l'uso di \func{sprintf} è sconsigliato in quanto è possibile, se non si ha la
 sicurezza assoluta sulle dimensioni del risultato della stampa, eccedere le
 dimensioni di \param{str}, con conseguente sovrascrittura di altre variabili e
 l'uso di \func{sprintf} è sconsigliato in quanto è possibile, se non si ha la
 sicurezza assoluta sulle dimensioni del risultato della stampa, eccedere le
 dimensioni di \param{str}, con conseguente sovrascrittura di altre variabili e

-possibili \textit{buffer overflow}\index{\textit{buffer~overflow}}; per questo
-motivo si consiglia l'uso dell'alternativa \funcd{snprintf}, il cui prototipo
-è:
+possibili \textit{buffer overflow}\itindex{buffer~overflow}; per questo motivo
+si consiglia l'uso dell'alternativa \funcd{snprintf}, il cui prototipo è:

 \begin{prototype}{stdio.h}
 {snprintf(char *str, size\_t size, const char *format, ...)} 
   Identica a \func{sprintf}, ma non scrive su \param{str} più di
 \begin{prototype}{stdio.h}
 {snprintf(char *str, size\_t size, const char *format, ...)} 
   Identica a \func{sprintf}, ma non scrive su \param{str} più di


@@ -1118,7 +1115,7 @@ scritti sulla stringa di destinazione:
   \param{size} caratteri.
 \end{prototype}
 \noindent in modo da evitare possibili buffer
   \param{size} caratteri.
 \end{prototype}
 \noindent in modo da evitare possibili buffer

-overflow\index{\textit{buffer~overflow}}.
+overflow\itindex{buffer~overflow}.

 
 
 Per eliminare alla radice questi problemi, le \acr{glibc} supportano una
 
 
 Per eliminare alla radice questi problemi, le \acr{glibc} supportano una


@@ -1140,14 +1137,15 @@ sono:
 
   \bodydesc{Le funzioni ritornano il numero di caratteri stampati.}
 \end{functions}
 
   \bodydesc{Le funzioni ritornano il numero di caratteri stampati.}
 \end{functions}

+

 Entrambe le funzioni prendono come argomento \param{strptr} che deve essere
 l'indirizzo di un puntatore ad una stringa di caratteri, in cui verrà
 restituito (si ricordi quanto detto in sez.~\ref{sec:proc_var_passing} a
 Entrambe le funzioni prendono come argomento \param{strptr} che deve essere
 l'indirizzo di un puntatore ad una stringa di caratteri, in cui verrà
 restituito (si ricordi quanto detto in sez.~\ref{sec:proc_var_passing} a

-proposito dei \index{\textit{value~result~argument}}\textit{value result
-  argument}) l'indirizzo della stringa 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\index{\textit{memory~leak}}.
+proposito dei \itindex{value~result~argument}\textit{value result argument})
+l'indirizzo della stringa allocata automaticamente dalle funzioni. Occorre
+inoltre ricordarsi di invocare \func{free} per liberare detto puntatore quando
+la stringa non serve più, onde evitare \textit{memory
+  leak}\itindex{memory~leak}.

 
 Infine una ulteriore estensione GNU definisce le due funzioni \func{dprintf} e
 \func{vdprintf}, che prendono un file descriptor al posto dello stream. Altre
 
 Infine una ulteriore estensione GNU definisce le due funzioni \func{dprintf} e
 \func{vdprintf}, che prendono un file descriptor al posto dello stream. Altre