fseek过去了 [英] fseek past the eof

问题描述

任何人都可以告诉我标准中有关使用fseek（在二进制

文件中）寻找文件结尾的内容吗？我在（草稿）

标准副本中找不到任何内容，也不在FAQ中找到。


谢谢

解决方案

Xenos写道：

任何人都可以告诉我关于使用fseek（在二进制文件上）寻求过去的标准说明了什么档案结尾？我无法在我的（草稿）
标准副本中找到任何内容，也无法在常见问题解答中找到任何内容。

谢谢

我很好奇为什么你愿意，以及你期望找到什么，

寻找过去的文件结尾。也许我误解了。


仍然好奇，你怎么知道文件的结尾是什么，以及你b $ b正在寻找它？


常见问题解答，fseek的语义处理文件开头的

，文件的结尾和相对的抵消

文件。实际地址是long类型。假设

正确打开了一些大小的文件（FILE * fp），..


long bof = 0; / *不需要计算。文件从0 * /

long eof开始; / *现在定义它* /

if（fseek（fp，0，SEEK_END）！= 0）puts（fseek failed，die），exit（9）;

eof = ftell（fp）;


现在eof实际上是文件长度。它指向文件中最后一个字节后面的一个字节，实际上是下一个字节可能写入的地方。


但是''过去的文件末尾''对我没有意义。文件结束+ 3？


-

Joe Wright mailto：jo ******** @ comcast.net

所有东西都应尽可能简单，但不能简单。

---阿尔伯特爱因斯坦---

>>任何人都可以告诉我标准说使用fseek（在二进制

文件中）寻找文件结尾？我无法在我的（草稿）
标准副本中找到任何内容，也无法在常见问题解答中找到任何内容。

谢谢
我很好奇为什么你会这样做，以及什么你期望找到，
寻找过去的文件结尾。也许我误解了。

在UNIX下，可以寻找过去的文件结尾，写一些东西

（这会移动结束 - 文件到你写的内容的结尾，并且

稍后再次寻找并阅读它。读取未写入的数据会回读

二进制0字节。在某些版本的UNIX磁盘块上

完全不成文也没有分配，留下了适用于软盘大小文件系统的千兆字节文件的可能性。

仍然很好奇，你怎么知道档案的最终位置以及你正在寻求过去？


这种奇怪的索引文件的许多用途都不关心

文件结尾的位置。您计算数据记录密钥的哈希码，

乘以数据块大小，这就是您放置

数据的位置。如果你想读取这样的记录，你可以对密钥进行散列，然后将数据块大小乘以它，并尝试读取它。如果你得到所有字节

零或文件结束，那么就没有写入记录。散列冲突

通过在数据块中放入多个条目来处理，或者通过使用散列中的更多位来定位不同的块来处理
。


以上是对UNIXdbm的粗略描述。文件工作。

它通常占用磁盘空间的1/4，而不是基于它的尺寸所需的b $ b。

文件的开头，文件的结尾和文件中的相对偏移量。实际地址是long类型。假设
正确打开了一些大小的文件（FILE * fp），..

long bof = 0; / *不需要计算。文件从0 * /
长eof开始; / *现在定义它* /
if（fseek（fp，0，SEEK_END）！= 0）puts（fseek failed，die），exit（9）;
eof = ftell （fp）;

现在eof实际上是文件长度。它指向文件中最后一个字节之后的一个字节，实际上是写入下一个字节的位置。

但是''过去的结尾 - 文件''对我没有意义。文件结束+ 3？

fseek（fp，32767，SEEK_END）;


Gordon L. Burditt

" Xenos" <做********** @ spamhate.com>写道：

任何人都可以告诉我标准说使用fseek（在二进制文件上）寻找文件结尾？

没什么，AFAICT。这意味着，除非我遗漏了某些东西，否则它是未定义的行为。这很奇怪;我原本以为

未指定：要么从fseek（）返回非零，要么允许它并且执行

特定于系统但是没有崩溃到文件。


Richard

Can anyone tell me what the standard says about using fseek (on a binary
file) to seek past the end-of-file? I can''t find anything in my (draft)
copy of the standard, nor in the FAQ.

Thanks

解决方案

Xenos wrote:

Can anyone tell me what the standard says about using fseek (on a binary
file) to seek past the end-of-file? I can''t find anything in my (draft)
copy of the standard, nor in the FAQ.

Thanks

I''m curious why you would, and what you would expect to find,
seeking past end-of-file. Perhaps I misunderstand.

Still curious, how would you know where end-of-file is and that you
are seeking past it?

The FAQ not withstanding, the semantics of fseek deal with the
beginning of the file, the end of the file and relative offsets
within the file. The actual address is of type long. Assuming a
properly opened file (FILE *fp) of some size, ..

long bof = 0; /* no calc needed. files begin at 0 */
long eof; /* just define it for now */
if (fseek(fp, 0, SEEK_END) != 0) puts("fseek failed, die"), exit(9);
eof = ftell(fp);

Now eof is actually the file length. It ''points'' one byte after the
last byte in the file, actually to where the next byte might be
written.

But ''past end-of-file'' has no meaning to me. end-of-file + 3?

--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

>> Can anyone tell me what the standard says about using fseek (on a binary

file) to seek past the end-of-file? I can''t find anything in my (draft)
copy of the standard, nor in the FAQ.

Thanks
I''m curious why you would, and what you would expect to find,
seeking past end-of-file. Perhaps I misunderstand.

Under UNIX it is possible to seek past end-of-file, write something
(which moves the end-of-file to the end of what you wrote), and
later seek again and read it. Reading unwritten data reads back
binary 0 bytes. On some versions of UNIX disk "blocks" that were
wholly unwritten were also not allocated, leaving the possibility
of the gigabyte-sized file that fits on a floppy-sized filesystem.
Still curious, how would you know where end-of-file is and that you
are seeking past it?
Many uses for this odd kind of indexed file don''t CARE where the
end-of-file is. You compute a hash code for the data record key,
multiply it by the data block size, and that''s where you put the
data. If you want to read such a record, you hash the key, multiply
it by the data block size, and try to read it. If you get all bytes
zero or end-of-file, there is no record written there. Hash collisions
are dealt with by putting multiple entries in a "data block", or
by using more bits in the hash to locate a different block.

The above is a crude description of how a UNIX "dbm" file works.
It typically occupies about 1/4 of the disk space than what you''d
expect based on its size.
beginning of the file, the end of the file and relative offsets
within the file. The actual address is of type long. Assuming a
properly opened file (FILE *fp) of some size, ..

long bof = 0; /* no calc needed. files begin at 0 */
long eof; /* just define it for now */
if (fseek(fp, 0, SEEK_END) != 0) puts("fseek failed, die"), exit(9);
eof = ftell(fp);

Now eof is actually the file length. It ''points'' one byte after the
last byte in the file, actually to where the next byte might be
written.

But ''past end-of-file'' has no meaning to me. end-of-file + 3?

fseek(fp, 32767, SEEK_END);

Gordon L. Burditt

"Xenos" <do**********@spamhate.com> wrote:

Can anyone tell me what the standard says about using fseek (on a binary
file) to seek past the end-of-file?

Nothing, AFAICT. Which means that, unless I missed something, it''s
undefined behaviour. Which is odd; I''d have expected it to be
unspecified: either return non-zero from fseek(), or allow it and do
something system-specific but non-crashing to the file.

Richard

这篇关于fseek过去了的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！