Come si può usare `fsetpos()` per "consentire l'accesso casuale su file che sono troppo grandi per gestire con` fseek() `?"

Question

Pur comprendendo che fpos_t è un tipo opaco destinato ad essere inizializzato dalla funzione fgetpos(), §7.19.9.1 degli stati che C99 rationale:

fgetpos e fsetpos sono stati aggiunti a C89 per consentire operazioni di accesso casuale sui file che sono troppo grandi per gestire con fseek e ftell.

e §7.19.9.2:

La necessità di codificare sia la posizione di registrazione e la posizione all'interno di un record in un valore long può limitare la dimensione dei file di testo su cui fseek e ftell può essere utilizzato per essere notevolmente più piccolo della dimensione dei file binari.

...

fgetpos e fsetpos sono stati aggiunti a che fare con i file che sono troppo grandi da gestire con fseek e ftell.

Questo sembra concentrarsi principalmente su file di testo (file aperti con un mode escludendo la bandiera b), perché alcune implementazioni possono richiedere la memorizzazione di due posizioni (una posizione di record di file e una posizione di carattere record), che potrebbero ridurre sensibilmente la gamma effettiva delle funzioni fseek() e ftell() per i flussi di testo.

Tuttavia, non ho idea di come questo sia particolarmente utile per i flussi di testo e certamente non capisco come possa essere effettivamente utilizzato per "accesso casuale".

Sembra che l'unico modo per utilizzare effettivamente queste funzioni è leggendo tutti i caratteri di un file e il caching loro fgetpos() d fpos_t valori, che sembra di nicchia nella migliore delle ipotesi, dal momento che quasi certamente non si vuole leggere da nessuna parte vicino LONG_MAX caratteri .

Cosa stava pensando "il Comitato"? C'è un fondamento logico C99?

Answer 1

Credo che su alcuni (probabilmente arcaico mainframe) i file di testo dei sistemi siano memorizzati come serie di "record" (righe) e la posizione del file pertanto sia costituita sia da un indice di registrazione sia da una posizione all'interno del record, che è ciò a cui il testo razionale sembra riferirsi. A livello di sistema operativo, l'operazione di ricerca richiede sia un indice di record e una posizione all'interno del record, piuttosto che una posizione di byte all'interno del file; questo porta al problema che sia l'indice di registrazione che la posizione all'interno devono essere codificati all'interno di un valore long da utilizzare con fseek e ftell. Pertanto, un'implementazione di una libreria deve assegnare un numero di bit a ciascun indice e posizione del record, e ciò limita il numero di record e la posizione.

Ad esempio, se long ha 32 bit, questo può essere diviso in 25 bit per l'indice del record e 7 bit per la posizione all'interno del record (consentendo una lunghezza massima utilizzabile del record di 127 e 2^25 ~ = 33k record). Il sistema può tuttavia consentire registrazioni più grandi e più grandi di questo.

(Le dichiarazioni di cui sopra sono in parte un vago ricordo e in parte deduzione dal testo razionale).

Tuttavia, il vero problema con fseek e ftell anche su sistemi desktop moderni è che un valore long potrebbe non essere sufficiente per rappresentare l'intero intervallo di posizioni dei file. Nei sistemi a 32 bit, long è in genere a 32 bit, ma i file possono spesso diventare ancora più grandi di 2 GB. Pertanto è necessario un diverso meccanismo per specificare gli offset di file.

Certamente non capisco come potrebbe essere effettivamente utilizzato per "accesso casuale".

In questo caso per "accesso casuale" che cosa stanno parlando è la possibilità di cercare in qualsiasi punto che è già stato visitato, cioè, è possibile riposizionare (usando fsetpos) qualsiasi posizione che si è già ottenuto (via fgetpos). Non si tratta di cercare qualsiasi posizione di byte arbitrario. Probabilmente "accesso casuale" è il termine sbagliato, ma penso che volessero solo distinguere dall'accesso puramente sequenziale.