 |
| ...con un cappello così si programma meglio... |
#include <stdio.h> #include <stdlib.h> // prototipi locali static int cpFile(const char* src, const char* dest); // funzione main() int main(int argc, char *argv[]) { // test argumenti if (argc != 3) { // errore: conteggio argomenti errato printf("%s: wrong arguments counts\n", argv[0]); printf("usage: %s srcfile destfile [e.g.: %s try.c try.save]\n", argv[0], argv[0]); return EXIT_FAILURE; } // esegue copy int retval; if ((retval = cpFile(argv[2], argv[1])) < 0) { // mostra errore ed esce fprintf(stderr, "%s: error: %d\n", argv[0], retval); exit(EXIT_FAILURE); } // esce return EXIT_SUCCESS; } // funzione cpFile() static int cpFile( const char *dest, // file destinazione const char *src) // file sorgente { // apre il file sorgente FILE *fp_in; if ((fp_in = fopen(src, "r")) == NULL) { // return con errore return -1; } // apre il file destinazione FILE *fp_out; if ((fp_out = fopen(dest, "w")) == NULL) { // chiude il file e return con errore fclose(fp_in); return -2; } // r/w loop per la copia usando buffered I/O size_t n_read; char buffer[BUFSIZ]; while ((n_read = fread(buffer, 1, sizeof(buffer), fp_in)) > 0) { if (! ferror(fp_in)) { // write buffer fwrite(buffer, 1, n_read, fp_out); if (ferror(fp_out)) { // chiude i file e return con errore fclose(fp_in); fclose(fp_out); return -3; } } else { // chiude i file e return con errore fclose(fp_in); fclose(fp_out); return -4; } } // chiude i file fclose(fp_in); fclose(fp_out); // return con Ok return 0; }Ok, come vedete è ampiamente commentato e quindi è auto-esplicativo, per cui non mi dilungherò sulle singole istruzioni e/o gruppi di istruzioni (leggete i commenti! sono li per quello!), ma aggiungerò, solo, qualche dettaglio strutturale. Il main(), come anticipato, è praticamente identico, mentre nella cpFile() si ripetono, esattamente, le spesse operazioni della versione unbuffered, usando però fopen(3) invece di open(2), fclose(3) invece di close(2), ecc. Dove troviamo qualche (piccola) differenza? Solo nel test di (eventuali) errori di lettura/scrittura, che nella versione unbuffered erano impliciti nelle operazioni di read/write (testando se il risultato era uguale a -1), mentre che in questo caso bisogna usare una funzione a parte, ferror(3), e questo perché:
On success, fread() and fwrite() return the number of items read or written. This number equals the number of bytes transferred only when size is 1. If an error occurs, or the end of the file is reached, the return value is a short item count (or zero). fread() does not distinguish between end-of-file and error, and callers must use feof(3) and ferror(3) to determine which occurred.Quello sopra è quello che riporta la man-page di fread(3)/fwrite(3), e credo che sia una giustificazione sufficiente sul perché ho scritto il codice così (e, per lo stesso motivo, non possiamo usare strerror(3) nel main() per segnalare gli errori). Quindi, come anticipato, le versioni buffered e unbuffered devono essere quasi sovrapponibili, e mi sembra che sia esattamente il risultato raggiunto.
Ed ora la digressione promessa: mi è capitato di trovare in rete (anche in pregevoli blog/siti di programmazione) esempi di implementazione di buffered-copy di file che usano dei loop di questo tipo:
while (!feof(fp_in)) { // legge e scrive buffer ... }ecco, come si può commentare questo? Con una sola parola:
NO
Se uno scrive il loop in questa maniera vuol dire che non ha letto la man-page di fread(3)/fwrite(3) o l'ha letta e non ne ha capito il contenuto. Non c'è bisogno di reinventare la ruota, ripeto: fread(3)/fwrite(3) funzionano quasi nello stesso modo di read(2)/write(2), quindi, se l'esempio della cpFile() unbuffered del post precedente era buono (e lo era!), allora l'esempio del post attuale deve risultare (quasi) uguale. Il loop con un while() che testa feof(3) è corretto sintatticamente ma non lo è logicamente, perché inizia testando qualcosa che non è ancora usabile (uhmm, un test predittivo?) e che, oltretutto, non serve testare. Bah, non voglio dilungarmi ulteriormente e vi rimando alla ottima analisi contenuta là (nel sempre ottimo stackoverflow.com).
Ovviamente spero di non aver offeso nessuno (con la digressione precedente): ricordate, errare humanum est... e, sicuramente, anche in questo blog avrò scritto in passato qualche scemata (spero non grave come quella appena mostrata). Vi assicuro, però, che sto sempre attentissimo a non proporre soluzioni che non ho avuto tempo di scrivere e provare in maniera approfondita, se no invece di un blog di programmazione artistica questo sarebbe un blog di programmazione alla speriamo che funziona...
Ciao e al prossimo post!
