Bagaimana `fsetpos()` dapat digunakan untuk mengizinkan akses acak pada file yang terlalu besar untuk ditangani dengan `fseek()`?

Meskipun saya memahami bahwa fpos_t adalah tipe buram yang dimaksudkan untuk diinisialisasi oleh fungsi fgetpos(), §7.19.9.1 dari Dasar pemikiran C99 menyatakan bahwa:

fgetpos dan fsetpos ditambahkan ke C89 untuk memungkinkan operasi akses acak pada file yang terlalu besar untuk ditangani dengan fseek dan ftell.

dan §7.19.9.2:

Kebutuhan untuk mengkodekan posisi rekaman dan posisi dalam rekaman dalam nilai long dapat membatasi ukuran file teks yang dapat digunakan fseek dan ftell menjadi jauh lebih kecil daripada ukuran file biner.

...

fgetpos dan fsetpos ditambahkan untuk menangani file yang terlalu besar untuk ditangani dengan fseek dan ftell.

Hal ini tampaknya terutama berfokus pada file teks (file dibuka dengan mode tidak termasuk flag b), karena beberapa implementasi mungkin memerlukan penyimpanan dua posisi (posisi rekaman file dan posisi karakter rekaman), yang secara signifikan dapat mengurangi jangkauan efektif fseek() dan fungsi ftell() untuk aliran teks.

Namun demikian, saya tidak mengerti bagaimana hal ini sangat berguna untuk aliran teks, dan saya tentu saja tidak mengerti bagaimana hal ini dapat secara efektif digunakan untuk "akses acak".

Tampaknya satu-satunya cara untuk benar-benar memanfaatkan fungsi-fungsi ini adalah dengan membaca setiap karakter file dan menyimpan nilai fgetpos()d fpos_t di dalamnya, yang sepertinya merupakan hal terbaik, karena Anda hampir pasti tidak ingin membaca mendekati LONG_MAX karakter.

Apa yang dipikirkan "Komite"? Apakah ada dasar pemikiran C99?


c stdio c99
person gw0    schedule 31.03.2016    source sumber

Jawaban (1)


arrow_upward
0
arrow_downward

Saya percaya bahwa pada beberapa sistem (mungkin mainframe kuno) file teks disimpan sebagai rangkaian "catatan" (baris) dan oleh karena itu posisi file dibuat sebagai indeks catatan dan posisi dalam catatan, itulah yang sepertinya dirujuk oleh teks rasional. Pada tingkat sistem operasi, operasi pencarian memerlukan indeks rekaman dan posisi dalam rekaman, bukan posisi byte dalam file; hal ini menyebabkan masalah bahwa indeks rekaman dan posisi di dalamnya harus dikodekan dalam nilai long untuk digunakan dengan fseek dan ftell. Oleh karena itu, implementasi perpustakaan perlu menetapkan sejumlah bit untuk setiap indeks dan posisi rekaman, dan ini membatasi jumlah rekaman dan posisinya.

Misalnya, jika long memiliki 32 bit, maka ini dapat dibagi menjadi 25 bit untuk indeks rekaman dan 7 bit untuk posisi dalam rekaman (memungkinkan panjang rekaman maksimum yang dapat digunakan sebesar 127, dan 2^25 ~= 33k rekaman). Namun sistem mungkin mengizinkan catatan yang lebih banyak dan lebih besar dari ini.

(Pernyataan di atas sebagian merupakan ingatan yang samar-samar, dan sebagian lagi merupakan kesimpulan dari teks dasar pemikiran).

Namun, masalah sebenarnya dengan fseek dan ftell bahkan pada sistem desktop modern adalah nilai long mungkin tidak cukup untuk mewakili seluruh posisi file. Pada sistem 32-bit long biasanya 32 bit, namun file sering kali masih bisa tumbuh hingga lebih besar dari 2 GB. Oleh karena itu diperlukan mekanisme berbeda untuk menentukan offset file.

Saya tentu saja tidak mengerti bagaimana hal ini dapat digunakan secara efektif untuk "akses acak".

Dalam hal ini dengan "akses acak" yang mereka bicarakan adalah kemampuan untuk mencari titik mana pun yang telah dikunjungi, yaitu, Anda dapat mengubah posisi (menggunakan fsetpos) posisi mana pun yang telah Anda peroleh (melalui fgetpos). Ini bukan tentang mencari posisi byte yang sewenang-wenang. Bisa dibilang "akses acak" adalah istilah yang salah, tapi menurut saya mereka hanya ingin membedakannya dari akses sekuensial murni.

person davmac    schedule 31.03.2016
comment
+1, namun mainframe IBM tidak lebih kuno dibandingkan ASCII atau POSIX: www -03.ibm.com/systems/z/index.html - person Andrew Henle; 31.03.2016