filestd.tex

   1  \chapter{I file: l'interfaccia standard ANSI C}
   2 \label{cha:files_std_interface}
   3
   4 Esamineremo in questo capitolo l'interfaccia standard ANSI C per i file,
   5 quella che viene comunemente detta interfaccia degli \textit{stream}.
   6 Dopo una breve sezione introduttiva tratteremo le funzioni base per la
   7 gestione dell'input/output, mentre tratteremo le caratteristiche più avanzate
   8 dell'interfaccia nell'ultima sezione.
   9
  10
  11 \section{Introduzione}
  12 \label{sec:file_stream_intro}
  13
  14 Come visto in \capref{cap:file_unix_interface} le operazioni di I/O sui file
  15 sono gestibili a basso livello con l'interfaccia standard unix, che ricorre
  16 direttamente alle system call messe a disposizione dal kernel.
  17
  18 Questa interfaccia però non provvede le funzionalità previste dallo standard
  19 ANSI C, che invece sono realizzate attraverso opportune funzioni di libreria,
  20 queste, insieme alle altre funzioni definite dallo standard, vengono a
  21 costituire il nucleo\footnote{queste funzioni sono state implementate la prima
  22   volta da Ritchie nel 1976 e da allora sono rimaste sostanzialmente
  23   immutate.} delle \acr{glibc}.
  24
  25
  26 \subsection{I \textit{file stream}}
  27 \label{sec:file_stream}
  28
  29 Come più volte ribadito l'interfaccia dei file descriptor è una interfaccia di
  30 basso livello, che non provvede nessuna forma di formattazione dei dati e
  31 nessuna forma di bufferizzazione per ottimizzare le operazioni di I/O.
  32
  33 In \textit{Advanced Programming in the Unix Environment} Stevens descrive una
  34 serie di test sull'influenza delle dimensioni del blocco di dati (il parametro
  35 \param{buf} di \func{read} e \func{write}) nell'efficienza nelle operazioni di
  36 I/O con i file descriptor, evidenziando come le prestazioni ottimali si
  37 ottengano a partire da dimensioni del buffer dei dati pari a quelle dei
  38 blocchi del filesystem (il valore dato dal campo \var{st\_blksize} di
  39 \var{fstat}).
  40
  41 Se il programmatore non si cura di effettuare le operazioni in blocchi di
  42 dimensioni adeguate, le prestazioni sono inferiori.  La caratteristica
  43 principale dell'interfaccia degli stream è che essa provvede da sola alla
  44 gestione dei dettagli della bufferizzazione e all'esecuzione delle operazioni
  45 di lettura e scrittura in blocchi di dimensioni appropriate all'ottenimento
  46 della massima efficienza.
  47
  48 Per questo motivo l'interfaccia viene chiamata anche interfaccia dei
  49 \textit{file stream}, dato che non è più necessario doversi preoccupare di dei
  50 dettagli della comunicazione con il tipo di hardware sottostante (come nel
  51 caso della dimensione dei blocchi del filesystem), ed un file può essere
  52 sempre considerato come composto da un flusso continuo (da cui il nome
  53 \textit{stream}) di dati.
  54
  55 A parte i dettagli legati alla gestione delle operazioni di lettura e
  56 scrittura (sia per quel che riguarda la bufferizzazione, che le
  57 formattazioni), i file stream restano del tutto equivalenti ai file descriptor
  58 (sui quali sono basati), ed in particolare continua a valere quanto visto in
  59 \secref{sec:file_sharing} a proposito dell'accesso condiviso ed in
  60 \secref{sec:file_access_control} per il controllo di accesso.
  61
  62
  63 \subsection{Gli oggetti \type{FILE}}
  64 \label{sec:file_FILE}
  65
  66 Per ragioni storiche la struttura di dati che rappresenta uno stream è stata
  67 chiamata \type{FILE}, questi oggetti sono creati dalle funzioni di libreria e
  68 contengono tutte le informazioni necessarie a gestire le operazioni sugli
  69 stream, come la posizione corrente, lo stato del buffer e degli indicatori di
  70 stato e di fine del file.
  71
  72 Per questo motivo gli utenti non devono mai utilizzare direttamente o allocare
  73 queste strutture, ma usare sempre puntatori del tipo \type{FILE *} ottenuti
  74 dalla libreria stessa (tanto che in certi casi il termine di puntatore a file
  75 è diventato sinonimo di stream).
  76
  77 Tutte le funzioni della libreria che operano sui file accettano come parametri
  78 solo variabili di questo tipo, che diventa accessibile includendo l'header
  79 file \file{stdio.h}.
  80
  81
  82
  83 \subsection{Gli stream standard}
  84 \label{sec:file_std_stream}
  85
  86 Ai tre file descriptor standard (vedi \secref{sec:file_std_descr})
  87 aperti per ogni processo, corrispondono altrettanti stream, che
  88 rappresentano i canali standard di input/output prestabiliti; anche
  89 questi tre stream sono identificabili attraverso dei nomi simbolici
  90 definiti nell'header \file{stdio.h} che sono:
  91
  92 \begin{itemize}
  93 \item \var{FILE * stdin} Lo \textit{standard input} cioè lo stream da
  94   cui il processo riceve ordinariamente i dati in ingresso. Normalmente
  95   è associato dalla shell all'input del terminale e prende i caratteri
  96   dalla tastiera.
  97 \item \var{FILE * stdout} Lo \textit{standard input} cioè lo stream su
  98   cui il processo invia ordinariamente i dati in uscita. Normalmente è
  99   associato dalla shell all'output del terminale e scrive sullo schermo.
 100 \item \var{FILE * stderr} Lo \textit{standard input} cioè lo stream su
 101   cui il processo è supposto inviare i messaggi di errore. Normalmente
 102   anch'esso è associato dalla shell all'output del terminale e scrive
 103   sullo schermo.
 104 \end{itemize}
 105
 106 Nelle \acr{glibc} \var{stdin}, \var{stdout} e \var{stderr} sono
 107 effettivamente tre variabili di tipo \type{FILE *} che possono essere
 108 usate come tutte le altre, ad esempio si può effettuare una redirezione
 109 dell'output di un programma con il semplice codice:
 110 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
 111     fclose (stdout);
 112     stdout = fopen ("standard-output-file", "w");
 113 \end{lstlisting}
 114 ma in altri sistemi possono essere definite come macro, se si hanno
 115 problemi di portabilità e si vuole essere sicuri, diventa opportuno
 116 usare la funzione \func{freopen}.
 117
 118
 119 \subsection{Le modalità di bufferizzazione}
 120 \label{sec:file_buffering}
 121
 122 La bufferizzazione è una delle caratteristiche principali della
 123 interfaccia degli stream; lo scopo è quello di ridurre al minimo il
 124 numero di system call (\func{read} o \func{write}) eseguite nelle
 125 operazioni di input/output. Questa funzionalità è assicurata
 126 automaticamente dalla libreria, ma costituisce anche una degli aspetti
 127 più comunemente fraintesi, in particolare per quello che riguarda
 128 l'aspetto della scrittura dei dati sul file.
 129
 130 I caratteri che vengono scritti su uno stream normalmente vengono
 131 accumulati in un buffer e poi trasmessi in blocco in maniera asincrona
 132 rispetto alla scrittura (quello che viene chiamato lo \textsl{scarico}
 133 dei dati, dall'inglese \textit{flush}) tutte le volte che il buffer
 134 viene riempito. Un comportamento analogo avviene anche in lettura (cioè
 135 dal file viene letto un blocco di dati, anche se se ne sono richiesti
 136 una quantità inferiore), ma la cosa ovviamente ha rilevanza inferiore,
 137 dato che i dati letti sono sempre gli stessi; in caso di scrittura
 138 invece, quando si ha un accesso contemporaneo allo stesso file (ad
 139 esempio da parte di un altro processo) si potranno vedere solo le parti
 140 effettivamente scritte, e non quelle ancora presenti nel buffer.
 141
 142 Allo stesso modo, se si sta facendo dell'input/output interattivo
 143 bisognerà tenere presente le caratteristiche delle operazioni di scarico
 144 dei dati, poiché non è detto che ad una scrittura sullo stream
 145 corrisponda una immediata scrittura sul dispositivo.
 146
 147 Per rispondere ad esigenze diverse, lo standard definisce tre distinte
 148 modalità in cui può essere eseguita la bufferizzazione, delle quali
 149 occorre essere ben consapevoli, specie in caso di lettura e scrittura da
 150 dispositivi interattivi:
 151 \begin{itemize}
 152 \item \textit{unbuffered}: in questo caso non c'è bufferizzazione ed i
 153   caratteri vengono trasmessi direttamente al file non appena possibile
 154   (effettuando immediatamente una \func{write}).
 155 \item \textit{line buffered}: in questo caso i caratteri vengono
 156   normalmente trasmessi al file in blocco ogni volta che viene
 157   incontrato un carattere di \textit{newline} (il carattere ASCII
 158   \verb|\n|).
 159 \item \textit{fully buffered}: in questo caso i caratteri vengono
 160   trasmessi da e verso il file in blocchi di dimensione opportuna.
 161 \end{itemize}
 162
 163 Lo standard ANSI C specifica inoltre che lo standard output e lo
 164 standard input siano aperti in modalità \textit{fully buffered} quando
 165 non fanno riferimento ad un dispositivo interattivo, e che lo standard
 166 error non sia mai aperto in modalità \textit{fully buffered}.
 167
 168 Linux, come BSD e SVr4, specifica il comportamento di default in maniera
 169 ancora più precisa, e cioè impone che lo standard error sia sempre
 170 \textit{unbuffered} (in modo che i messaggi di errore siano mostrati il più
 171 rapidamente possibile) e che standard input e standard output siano aperti in
 172 modalità \textit{line buffered} quando sono associati ad un terminale (od
 173 altro dispositivo interattivo) ed in modalità \textit{fully buffered}
 174 altrimenti.
 175
 176 Il comportamento specificato per standard input e standard output vale anche
 177 per tutti i nuovi stream aperti da un processo; la selezione comunque avviene
 178 automaticamente, e la libreria apre lo stream nella modalità più opportuna a
 179 seconda del file o del dispositivo scelto.
 180
 181 La modalità \textit{line buffered} è quella che necessita di maggiori
 182 chiarimenti e attenzioni per quel che concerne il suo funzionamento. Come già
 183 accennato nella descrizione, \emph{di norma} i dati vengono inviati al kernel
 184 alla ricezione di un carattere di a capo; questo non è vero in tutti i casi,
 185 infatti, dato che le dimensioni del buffer usato dalle librerie sono fisse, se
 186 le si eccedono si può avere uno scarico dei dati anche prima che sia stato
 187 inviato un carattere di \textit{newline}.
 188
 189 Un secondo punto da tenere presente, particolarmente quando si ha a che fare
 190 con I/O interattivo, è che quando si effettua una lettura su uno stream che
 191 comporta l'accesso al kernel\footnote{questo vuol dire sempre se lo stream da
 192   cui si legge è in modalità \textit{unbuffered}.} viene anche eseguito lo
 193 scarico di tutti i buffer degli stream in scrittura.
 194
 195 In \secref{sec:file_buffering_ctrl} vedremo come la libreria definisca delle
 196 opportune funzioni per controllare le modalità di bufferizzazione e lo scarico
 197 dei dati.
 198
 199
 200
 201 \section{Funzioni base}
 202 \label{sec:file_ansi_base_func}
 203
 204 Esamineremo in questa sezione le funzioni base dell'interfaccia degli stream,
 205 analoghe a quelle di \secref{sec:file_base_func} per i file descriptor. In
 206 particolare vedremo come aprire, leggere, scrivere e cambiare la posizione
 207 corrente in uno stream.
 208
 209
 210 \subsection{Apertura e chiusura di uno stream}
 211 \label{sec:file_fopen}
 212
 213 Le funzioni che permettono di aprire uno stream sono tre\footnote{\func{fopen}
 214   e \func{freopen} fanno parte dello standard ANSI C, \func{fdopen} è parte
 215 dello standard POSIX.1.}, i loro prototipi sono:
 216 \begin{functions}
 217   \headdecl{stdio.h}
 218   \funcdecl{FILE * fopen(const char * path, const char *mode)}
 219   Apre il file specificato da \param{path}.
 220   \funcdecl{FILE * fdopen(int fildes, const char * mode)}
 221   Associa uno stream al file descriptor \param{fildes}.
 222   \funcdecl{FILE * freopen(const char * path, const char * mode, FILE *
 223   stream)}
 224   Apre il file specificato da \param{path} associandolo allo stream
 225   specificato da \param{stream}, se questo è già aperto prima lo chiude.
 226
 227   Le funzioni ritornano un puntatore valido in caso di successo e \macro{NULL}
 228   in caso di errore, in tal caso \var{errno} viene settata al valore ricevuto
 229   dalla funzione sottostante di cui è fallita l'esecuzione.
 230
 231   Gli errori pertanto possono essere quelli di \func{malloc} per tutte e tre
 232   le funzioni, quelli \func{open} per \func{fopen}, quelli di \func{fcntl} per
 233   \func{fdopen} e quelli di \func{fopen}, \func{fclose} e \func{fflush} per
 234   \func{freopen}.
 235 \end{functions}
 236
 237 Normalmente la funzione che si usa per aprire uno stream è \func{fopen}, essa
 238 apre il file specificato nella modalità specificata da \param{mode} che è una
 239 delle stringhe elencate in \tabref{tab:file_fopen_mode}.
 240
 241 L'uso di \func{freopen} è in genere per redirigere uno dei tre file standard
 242 (vedi \secref{sec:file_std_stream}): il file \param{path} viene associato a
 243 \param{stream} e se questo è uno stream aperto prima viene chiuso.
 244
 245 Infine \func{fdopen} viene usato per associare uno stream ad un file
 246 descriptor esistente ottenuto tramite una altra funzione (come \func{open},
 247 \func{dup}, \func{pipe}) e serve quando si vogliono usare gli stream con file
 248 speciali come le fifo od i socket, che non possono essere aperti con le
 249 funzioni delle librerie standard del C.
 250
 251 \begin{table}[htb]
 252   \centering
 253   \begin{tabular}[c]{|l|p{8cm}|}
 254     \hline
 255     \textbf{Valore} & \textbf{Significato}\\
 256     \hline
 257     \hline
 258     \texttt{r} & Il file viene aperto in sola lettura; lo stream è posizionato
 259     all'inizio del file.\\
 260     \texttt{r+} & Il file viene aperto in lettura e scrittura; lo stream è
 261     posizionato all'inizio del file. \\
 262 %    \hline
 263     \texttt{w} & Il file viene troncato a lunghezza nulla (o creato se non
 264     esiste), ed aperto in sola lettura; lo stream è posizionato all'inizio del
 265     file.\\
 266     \texttt{w+} & Il file viene troncato a lunghezza nulla (o creato se non
 267     esiste), ed aperto in scrittura e lettura; lo stream è posizionato
 268     all'inizio del file.\\
 269 %    \hline
 270     \texttt{a} & Il file è aperto in \textit{append mode} in sola scrittura
 271     (o creato se non esiste). \\
 272     \texttt{a+} & Il file è aperto in \textit{append mode} in lettura e
 273     scrittura (o creato se non esiste). \\
 274     \hline
 275   \end{tabular}
 276   \caption{Modalità di apertura di uno stream}
 277   \label{tab:file_fopen_mode}
 278 \end{table}
 279
 280 In realtà lo standard ANSI C prevede un totale di 15 possibili valori
 281 diversi per \param{mode}, ma in \tabref{tab:file_fopen_mode} si sono
 282 riportati solo i sei valori effettivi, ad essi può essere aggiunto pure
 283 il carattere \func{b} (come ultimo carattere o nel mezzo agli altri per
 284 le stringhe di due caratteri) che in altri sistemi operativi serve a
 285 distinguere i file binari dai file di testo; in un sistema POSIX questa
 286 distinzione non esiste e il valore viene accettato solo per
 287 compatibilità, ma non ha alcun effetto.
 288
 289 Inoltre nel caso si usi \func{fdopen} i valori specificati da
 290 \param{mode} devono essere compatibili con quelli con cui il file
 291 descriptor è stato aperto. Inoltre i modi \cmd{w} e \cmd{w+} non
 292 troncano il file. La posizione nello stream viene settata a quella
 293 corrente nel file descriptor, e le variabili di errore e di fine del
 294 file sono cancellate. Il file non viene duplicato e verrà chiuso alla
 295 chiusura dello stream.
 296
 297 I nuovi file saranno creati secondo quanto visto in
 298 \secref{sec:file_ownership} ed avranno i permessi di accesso settati al
 299 valore \macro{S\_IRUSR|S\_IWUSR|S\_IRGRP|S\_IWGRP|S\_IROTH|S\_IWOTH}
 300 (pari a \macro{0666}) modificato secondo il valore di \acr{umask} per il
 301 processo (si veda \secref{sec:file_umask}).
 302
 303 In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è
 304 di messo una bufferizzazione; per questo motivo lo standard ANSI C
 305 richiede che ci sia una operazione di posizionamento fra una operazione
 306 di output ed una di input o viceversa (eccetto il caso in cui l'input ha
 307 incontrato la fine del file), altrimenti una lettura può ritornare anche
 308 il risultato di scritture precedenti l'ultima effettuata.
 309
 310 Per questo motivo è una buona pratica (e talvolta necessario) far seguire ad
 311 una scrittura una delle funzioni \func{fflush}, \func{fseek}, \func{fsetpos} o
 312 \func{rewind} prima di eseguire una rilettura; viceversa nel caso in cui si
 313 voglia fare una scrittura subito dopo aver eseguito una lettura occorre prima
 314 usare una delle funzioni \func{fseek}, \func{fsetpos} o \func{rewind}. Anche
 315 una operazione nominalmente nulla come \func{fseek(file, 0, SEEK\_CUR)} è
 316 sufficiente a garantire la sincronizzazione.
 317
 318 Una volta aperto lo stream, si può cambiare la modalità di bufferizzazione
 319 (vedi \secref{sec:file_buffering_ctrl}) fintanto che non si è effettuato
 320 alcuna operazione di I/O sul file.
 321
 322 Uno stream viene chiuso con la funzione \func{fclose} il cui prototipo è:
 323 \begin{prototype}{stdio.h}{int fclose(FILE * stream)}
 324   Chiude lo stream \param{stream}.
 325
 326   Restituisce 0 in caso di successo e \macro{EOF} in caso di errore, nel qual
 327   caso setta \var{errno} a \macro{EBADF} se il file descriptor indicato da
 328   \param{stream} non è valido, o uno dei valori specificati dalla sottostante
 329   funzione che è fallita (\func{close}, \func{write} o \func{fflush}).
 330 \end{prototype}
 331
 332 La funzione effettua uno scarico di tutti i dati presenti nei buffer di uscita
 333 e scarta tutti i dati in ingresso, se era stato allocato un buffer per lo
 334 stream questo verrà rilasciato. La funzione effettua lo scarico solo per i
 335 dati presenti nei buffer in user space usati dalle \acr{glibc}; se si essere
 336 sicuri che il kernel forzi la scrittura su disco occorrerà effettuare .
 337
 338 Linux supporta, come estensione implementata dalle \acr{glibc}, anche una
 339 altra funzione, \func{fcloseall}, che serve a chiudere tutti i file, il suo
 340 prototipo è:
 341 \begin{prototype}{stdio.h}{int fcloseall(void)}
 342   Chiude tutti gli stream.
 343
 344   Restituisce 0 se non ci sono errori ed \macro{EOF} altrimenti.
 345 \end{prototype}
 346 la funzione esegue lo scarico dei dati bufferizzati in uscita e scarta quelli
 347 in ingresso, chiudendo tutti i file. Questa funzione è provvista solo per i
 348 casi di emergenza, quando si è verificato un errore ed il programma deve
 349 essere abortito, ma si vuole compiere qualche altra operazione dopo aver
 350 chiuso i file e prima di uscire (si ricordi quanto visto in
 351 \secref{sec:proc_exit}).
 352
 353
 354 \subsection{Lettura e scrittura su uno stream}
 355 \label{sec:file_io}
 356
 357 Una delle caratteristiche più utili dell'interfaccia degli stream è la
 358 ricchezza delle funzioni disponibili per le operazioni di lettura e
 359 scrittura sui file. Sono infatti previste ben tre diverse modalità
 360 modalità di input/output non formattato:
 361 \begin{enumerate}
 362 \item\textsl{binario} in cui legge/scrive un blocco di dati alla
 363   volta, vedi \secref{sec:file_binary_io}.
 364 \item\textsl{di linea} in cui si legge/scrive una linea (terminata dal
 365   carattere di newline \verb|\n|) alla volta, vedi
 366   \secref{sec:file_line_io}.
 367 \item\textsl{a caratteri} in cui si legge/scrive un carattere alla
 368   volta (con la bufferizzazione gestita automaticamente dalla libreria),
 369   vedi \secref{sec:file_char_io}.
 370 \end{enumerate}
 371 ed inoltre la modalità di input/output formattato.
 372
 373 A differenza dell'interfaccia dei file descriptor il raggiungimento della fine
 374 del file è considerato un errore, e viene notificato come tale dai valori di
 375 uscita delle varie funzioni; nella maggior parte dei casi questo avviene con
 376 la restituzione del valore intero (di tipo \type{int}) \macro{EOF}\footnote{la
 377   costante deve essere negativa, le \acr{glibc} usano -1, altre
 378   implementazioni possono avere valori diversi.}  definito anch'esso
 379 nell'header \func{stdlib.h}.
 380
 381 Dato che le funzioni dell'interfaccia degli stream sono funzioni di libreria
 382 che si appoggiano a delle system call, esse non settano direttamente la
 383 variabile \var{errno}, che mantiene il valore settato dalla system call che ha
 384 riportato l'errore.
 385
 386 Siccome la condizione di end-of-file è anch'essa segnalata come errore, nasce
 387 il problema di come distinguerla da un errore effettivo; basarsi solo sul
 388 valore di ritorno della funzione e controllare il valore di \var{errno}
 389 infatti non basta, dato che quest'ultimo potrebbe essere stato settato in una
 390 altra occasione, (si veda \secref{sec:sys_errno} per i dettagli del
 391 funzionamento di \var{errno}).
 392
 393 Per questo motivo tutte le implementazioni delle librerie standard
 394 mantengono per ogni stream almeno due flag all'interno dell'oggetto
 395 \type{FILE}, il flag di \textit{end-of-file}, che segnala che si è
 396 raggiunta la fine del file in lettura, e quello di errore, che segnala
 397 la presenza di un qualche errore nelle operazioni di input/output;
 398 questi flag possono essere riletti dalle funzioni:
 399 \begin{functions}
 400   \headdecl{stdio.h}
 401   \funcdecl{int feof(FILE *stream)}
 402   Controlla il flag di end-of-file di \param{stream}.
 403   \funcdecl{int ferror(FILE *stream)}
 404   Controlla il flag di errore di \param{stream}.
 405
 406   Entrambe le funzioni ritornano un valore diverso da zero se i relativi
 407   flag sono settati.
 408 \end{functions}
 409 \noindent si tenga presente comunque che la lettura di questi flag segnala
 410 soltanto che c'è stato un errore, o che si è raggiunta la fine del file in una
 411 qualunque operazione sullo stream, il controllo quindi deve essere effettuato
 412 ogni volta che si chiama una funzione di libreria.
 413
 414 Entrambi i flag (di errore e di end-of-file) possono essere cancellati usando
 415 la funzione \func{clearerr}, il cui prototipo è:
 416 \begin{prototype}{stdio.h}{void clearerr( FILE *stream)}
 417   Cancella i flag di errore ed end-of-file di \param{stream}.
 418 \end{prototype}
 419 \noindent in genere si usa questa funziona una volta che si sia identificata e
 420 corretta la causa di un errore per evitare di mantenere i flag attivi,
 421 così da poter rilevare una successiva ulteriore condizione di errore.
 422
 423
 424 \subsection{Input/output binario}
 425 \label{sec:file_binary_io}
 426
 427 La prima modalità di input/output non formattato ricalca quella della
 428 intefaccia dei file descriptor, e provvede semplicemente la scrittura e
 429 la lettura dei dati da un buffer verso un file e vicecersa. In generale
 430 questa è la modalità che si usa quando si ha a che fare con dati non
 431 formattati. Le due funzioni che si usano per l'I/O binario sono:
 432 \begin{functions}
 433   \headdecl{stdio.h}
 434   \funcdecl{size\_t fread(void * ptr, size\_t size,
 435     size\_t nmemb, FILE * stream)}
 436   \funcdecl{size\_t fwrite(const void *
 437     ptr, size\_t size, size\_t nmemb, FILE * stream)}
 438
 439   Le funzioni rispettivamente leggono e scrivono \param{nmemb} elementi
 440   di dimensione \param{size} dal buffer \param{ptr} al file \param{stream}.
 441
 442   Entrambe le funzioni ritornano il numero di elementi letti o scritti,
 443   in caso di errore o fine del file viene restituito un numero di
 444   elementi inferiore al richiesto.
 445 \end{functions}
 446
 447 In genere si usano queste funzioni quando si devono trasferire su file
 448 blocchi di dati binari in maniera compatta e veloce; un primo caso di uso
 449 tipico è quello in cui si salva un vettore (o un certo numero dei suoi
 450 elementi) con una chiamata del tipo:
 451 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
 452 int WriteVect(FILE * stream, double * vec, size_t nelem)
 453 {
 454     int size, nread;
 455     size = sizeof(*vec);
 456     if ( (nread = fwrite(vec, size, nelem, stream)) != nelem) {
 457         perror("Write error");
 458     }
 459     return nread;
 460 }
 461 \end{lstlisting}
 462 in questo caso devono essere specificate le dimensioni di ciascun
 463 elemento ed il numero di quelli che si vogliono scrivere. Un secondo
 464 caso è invece quello in cui si vuole trasferire su file una struttura;
 465 si avrà allora una chiamata tipo:
 466 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
 467 struct histogram {
 468     int nbins;
 469     double max, min;
 470     double * bin;
 471 } histo;
 472
 473 int WriteStruct(FILE * stream, struct histogram * histo, size_t nelem)
 474 {
 475     if ( fwrite(vec, sizeof(*histo), 1, stream) !=1) {
 476         perror("Write error");
 477     }
 478     return nread;
 479 }
 480 \end{lstlisting}
 481 in cui si specifica la dimensione dell'intera struttura ed un solo
 482 elemento. In realtà quello che conta nel trasferimento dei dati sono le
 483 dimensioni totali, che sono sempre pari al prodotto \func{size * nelem},
 484 la sola differenza è che le funzioni non ritornano il numero di bytes
 485 scritti, ma il numero di elementi.
 486
 487 La funzione \func{fread} legge sempre un numero intero di elementi, se
 488 si ha un errore o si incontra la fine del file l'oggetto letto
 489 parzialmente viene scartato
 490
 491
 492 Benché queste funzioni assicurino
 493
 494
 495 \subsection{Input/output a caratteri singoli}
 496 \label{sec:file_char_io}
 497
 498
 499
 500
 501 \subsection{Input/output di linea}
 502 \label{sec:file_line_io}
 503
 504
 505 \subsection{Input/output formattato}
 506 \label{sec:file_formatted_io}
 507
 508
 509 \subsection{Posizionamento su uno stream}
 510 \label{sec:file_fseek}
 511
 512
 513
 514 \section{Funzioni avanzate}
 515 \label{sec:file_stream_adv_func}
 516
 517 In questa sezione esamineremo le funzioni che permettono di controllare alcune
 518 caratteristiche più particolari degli stream, come la lettura degli attributi,
 519 le modalità di bufferizzazione, etc.
 520
 521
 522 \subsection{Le funzioni di controllo}
 523 \label{sec:file_stream_cntrl}
 524
 525 Al contrario di quanto avviene con i file descriptor le librerie standard del
 526 C non prevedono nessuna funzione come la \func{fcntl} per la lettura degli
 527 attributi degli stream; le \acr{glibc} però supportano alcune estensioni
 528 derivate da Solaris, che permettono di ottenere informazioni utili.
 529
 530 In certi casi può essere necessario sapere se un certo stream è accessibile in
 531 lettura o scrittura. In genere questa informazione non è disponibile, e si
 532 deve ricordare come il file è stato aperto. La cosa può essere complessa se le
 533 operazioni vengono effettuate un una subroutine, che a questo punto
 534 necessiterà di informazioni aggiuntive rispetto al semplice puntatore allo
 535 stream; questo può essere evitato con le due funzioni \func{\_\_freadable} e
 536 \func{\_\_fwritable} i cui prototipi sono:
 537 \begin{functions}
 538   \headdecl{stdio\_ext.h}
 539   \funcdecl{int \_\_freadable (FILE * stream)}
 540   Restituisce un valore diverso da zero se \param{stream} consente la lettura.
 541
 542   \funcdecl{int \_\_fwritable(FILE * stream)}
 543   Restituisce un valore diverso da zero se \param{stream} consente la
 544   scrittura.
 545 \end{functions}
 546
 547 Altre due funzioni, \func{\_\_freading} e \func{\_\_fwriting} servono ad un
 548 uso ancora più specialistico, il loro prototipo è:
 549 \begin{functions}
 550   \headdecl{stdio\_ext.h}
 551   \funcdecl{int \_\_freading (FILE * stream)}
 552   Restituisce un valore diverso da zero se \param{stream} è aperto in sola
 553   lettura o se l'ultima operazione è stata di lettura.
 554
 555   \funcdecl{int \_\_fwriting(FILE * stream)}
 556   Restituisce un valore diverso da zero se \param{stream} è aperto in sola
 557   scrittura o se l'ultima operazione è stata di scrittura.
 558 \end{functions}
 559
 560 Le due funzioni hanno lo scopo di determinare di che tipo è stata l'ultima
 561 operazione eseguita su uno stream aperto in lettura/scrittura; ovviamente se
 562 uno stream è aperto in sola lettura (o sola scrittura) la modalità dell'ultima
 563 operazione è sempre determinata; l'unica ambiguità è quando non sono state
 564 ancora eseguite operazioni, in questo caso le funzioni rispondono come se
 565 una operazione ci fosse comunque stata.
 566
 567 La conoscenza dell'ultima operazione effettuata su uno stream aperto in
 568 lettura/scrittura è utile in quanto permette di trarre conclusioni sullo stato
 569 del buffer e del suo contenuto.
 570
 571
 572 \subsection{Il controllo della bufferizzazione}
 573 \label{sec:file_buffering_ctrl}
 574
 575 Come accennato in \secref{sec:file_buffering} le librerie definiscono una
 576 serie di funzioni che permettono di controllare il comportamento degli
 577 stream; se non si è
 578
 579
 580 \subsection{Dettagli dell'implementazione}
 581 \label{sec:file_stream_details}
 582
 583
 584 \subsection{File temporanei}
 585 \label{sec:file_temp_file}
 586
 587
 588 \subsection{Efficienza}
 589 \label{sec:file_stream_efficiency}
 590