同步ReadFile读取的字节数

发布于 2024-09-11 18:02:35 字数 344 浏览 9 评论 0原文

假设我有 1Mb 文件,文件指针位于文件的开头。我调用同步ReadFile:

ReadFile(Handle, Buffer, 1024, Result, nil);

调用成功,没有发生错误。结果值(读取的字节数)是否可能小于 1024(读取的字节数)?

我认为这对于磁盘文件来说是不可能的,我不确定ReadFile可以访问其他资源。在编写可以使用不同资源的通用代码时,我是否应该考虑上述情况?


为了避免哲学猜测,我可以将问题重新表述如下:

同步 ReadFile 执行时没有错误,并且读取的字节数小于要读取的字节数。我可以确定达到 EOF 吗?

Assume I have 1Mb file, file pointer is at the beginning of the file. I call synchronous ReadFile:

ReadFile(Handle, Buffer, 1024, Result, nil);

the call is succesful, no error occured. Is it possible that Result value (number of bytes read) is less than 1024 (number of bytes to read)?

I think that is impossible for disk files, I am not sure about other resources that can be accessed by ReadFile. Should I take the above scenario into account while writing a general code that can work with different resources?


To avoid philosophical speculations I can reformulate the question as follows:

Synchronous ReadFile was executed without error and a number of bytes read is less than a number of to read. Can I be sure that EOF is reached?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

泪痕残 2024-09-18 18:02:35

在您给定的场景中,对于磁盘文件来说,似乎不可能接收到比请求的字节数更少的读取字节数。

但是,编写可以处理不同资源的通用代码时,在位置+请求的字节数小于要传输的字节总数的情况下,您不应该依赖于始终接收请求的字节数。

例如,当名为 WriteFile 的命名管道的另一端有 0 字节要写入时,Readfile 可以在成功调用时返回 0 字节读取...

In your given scenario, it does seem that for disk files it would be impossible to receive less bytes read than the requested number of bytes.

However, writing general code that can work with different resources, you should not rely on always receiving the requested number of bytes in the situation where position + bytes requested is less than the total number of bytes to be transferred.

For example Readfile can return 0 bytes read on a successful call when the other end of a named pipe called WriteFile with 0 bytes to write...

水水月牙 2024-09-18 18:02:35

当 ReadFile 返回小于文件请求的字节数(即不是套接字、管道等)时,MSDN 似乎只说了以下内容: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365467(v=vs .85).aspx

当同步读取操作到达文件末尾时,ReadFile 返回 TRUE 并将 *lpNumberOfBytesRead 设置为零。

我找不到任何证据或反驳,表明 ReadFile 不会读取文件的较小块,并在文件包含不少于最初请求的字节数时返回该块的大小。因此,我正在编写代码来检查 ReadFile 返回了多少字节,并再次调用 ReadFile(在循环中),只要返回的字节总数小于请求的字节数,除非 ReadFile 返回 0 字节,这意味着 EOF 根据MSDN。

实际含义:

  1. 调用 GetFileSizeEx 并分配由其报告的大小的缓冲区
    函数
  2. 调用 ReadFile 请求立即读取整个缓冲区,
  3. 程序员不能相信 ReadFile 不会读取较小的缓冲区
    chunk 报告读取的字节数

MSDN seems to say only the following w.r.t. when ReadFile returns less than the requested number of bytes for a file (i.e. not a socket, pipe, etc.): https://msdn.microsoft.com/en-us/library/windows/desktop/aa365467(v=vs.85).aspx

When a synchronous read operation reaches the end of a file, ReadFile returns TRUE and sets *lpNumberOfBytesRead to zero.

I can't find any proof or disproof that ReadFile will not read a smaller chunk of the file and return the size of that chunk when the file contains no less than the originally requested number of bytes. Thus I am writing code which checks how many bytes ReadFile returns, and calls ReadFile again (in a loop) so long as the total number of bytes returned is less than the requested number of bytes, unless ReadFile returns 0 bytes which means EOF according to MSDN.

A practical implication:

  1. call GetFileSizeEx and allocate a buffer of size reported by that
    function
  2. call ReadFile requesting to read the whole buffer at once
  3. the programmer can't rely that ReadFile will not read a smaller
    chunk reporting that number of bytes read
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文