Wie kann `fsetpos()` verwendet werden, um "zufälligen Zugriff auf Dateien zu erlauben, die zu groß sind, um mit` fseek() `umzugehen?"

Question

Ich verstehe zwar, dass fpos_t eine undurchsichtige Art soll durch die fgetpos() Funktion initialisiert werden, §7.19.9.1 der C99 rationale lautet:

fgetpos und fsetpos zu C89 hinzugefügt wurden zufällige Zugriffe auf Dateien ermöglichen, Das sind zu groß, um mit fseek und ftell umzugehen.

und §7.19.9.2:

Die Notwendigkeit, sowohl Aufzeichnungsposition und die Position innerhalb eines Datensatzes in einem long Wert zu codieren, können die Größe von Textdateien beschränken, auf denen fseek und ftell kann verwendet werden, deutlich kleiner sein als die Größe von Binärdateien.

...

fgetpos und fsetpos wurden mit Dateien umgehen hinzugefügt, die zu groß sind, mit fseek und ftell zu behandeln.

Dies scheint auf Textdateien (Dateien mit einem mode ohne die b Flagge geöffnet), weil einige Implementierungen zwei Positionen (eine Datei Aufzeichnungsposition und eine Aufzeichnung Zeichenposition) speichert, kann erfordern in erster Linie zu konzentrieren, was signifikant verringern könnte der effektive Bereich der Funktionen fseek() und ftell() für Text Streams.

Dennoch bin ich ratlos, wie das besonders nützlich für Text-Streams ist, und ich verstehe sicherlich nicht, wie es effektiv für "Direktzugriff" verwendet werden könnte.

es der einzige Weg scheint, ist diese Funktionen tatsächlich zu nutzen, indem jedes Zeichen einer Datei zu lesen und das Caching ihre fgetpos() d fpos_t Werte, die Nische am besten scheint, da Sie nicht mit ziemlicher Sicherheit irgendwo in der Nähe LONG_MAX Zeichen lesen möchten .

Was war der "Ausschuss"? Gibt es eine logische Begründung für C99?

Answer 1

Ich glaube, dass auf einigen (wahrscheinlich archaischen Mainframe) -System Textdateien als Folge von "Datensätzen" (Zeilen) gespeichert werden und die Dateiposition daher einen Datensatzindex und eine Position innerhalb des Datensatzes ausmacht Darauf bezieht sich der Begründungstext. Auf der Betriebssystemebene erfordert die Suchoperation sowohl einen Datensatzindex als auch eine Position innerhalb des Datensatzes anstelle einer Byteposition innerhalb der Datei; Dies führt zu dem Problem, dass sowohl der Index als auch die Position innerhalb eines long Wertes zur Verwendung mit fseek und ftell kodiert werden müssen. Daher muss eine Bibliotheksimplementierung jedem Datensatzindex und jeder Position eine bestimmte Anzahl von Bits zuweisen, was die Anzahl der Datensätze und die Position begrenzt. Wenn long zum Beispiel 32 Bits hat, dann kann dies in 25 Bits für den Datensatzindex und 7 Bits für die Position innerhalb des Datensatzes unterteilt sein (was eine maximal nutzbare Aufzeichnungslänge von 127 und 2^25 ~ = erlaubt) 33k Datensätze). Das System kann jedoch mehr und größere Datensätze zulassen.

(Die obigen Aussagen sind teilweise vage Erinnerung und teilweise Schlussfolgerung aus dem Begründungstext).

Das eigentliche Problem mit fseek und ftell auf sogar modernen Desktop-Systemen ist jedoch, dass ein long Wert nicht genug sein kann, um den gesamten Bereich der Dateipositionen darzustellen. Auf 32-Bit-Systemen long ist in der Regel 32 Bit, aber Dateien können oft noch größer als 2 GB werden. Daher ist ein anderer Mechanismus zum Festlegen von Dateioffsets erforderlich.

Ich verstehe sicherlich nicht, wie es effektiv für "Direktzugriff" verwendet werden könnte.

In diesem Fall von „random access“, was sie reden, ist die Fähigkeit zu einem beliebigen Punkt zu suchen, die bereits besucht wurde, das heißt, Sie können (mit fsetpos) jede Position neu zu positionieren, die Sie bereits erhalten haben, (über fgetpos). Es geht nicht darum, nach irgendeiner beliebigen Byte-Position zu suchen. Wohl "zufälliger Zugang" ist der falsche Begriff, aber ich denke, sie wollten nur vom rein sequentiellen Zugriff unterscheiden.