3

I am attempting to come up with an algorithm to detect when the "end" of a QIODevice is reached (meaning no more data will ever be available for reading). Currently, my algorithm looks something like this:

However, the documentation for atEnd() contains the following caveat:

For some devices, atEnd() can return true even though there is more data to read. This special case only applies to devices that generate data in direct response to you calling read() (e.g., /dev or /proc files on Unix and OS X, or console input / stdin on all platforms).

This is where my algorithm breaks down. My next idea was to continuously check the value of bytesAvailable() when reading from a regular file. This yielded some very strange results for /dev/zero: bytesAvailable() returned 0 until I invoked read(amount), at which point it indicated that there were 16384 - amount bytes remaining.

Is there any "proper" way to determine if there is still data available to read from a QIODevice?

Nathan Osman
  • 71,149
  • 71
  • 256
  • 361
  • I would argue that it is impossible to determine end-of-file for such special files that only generate content on being read from without actually trying to read from them. – Moritz Bunkus May 01 '15 at 19:09
  • 3
    Put Qt and C++ away for a moment. What do you expect (e.g. expressed in English language or expressed as an image) to be an "end" of `/dev/zero` or `/dev/random`? – Simon Warta May 01 '15 at 19:23
  • @SimonWarta in that particular case, I don't _expect_ an end. My algorithm should always result in a conclusion that "there is more data available". – Nathan Osman May 01 '15 at 19:35
  • @NathanOsman Ok, what do you expect to be an "end" of a serial device? This is why QIODevice (and devices in general) don't provide and end-of-file signal, but provides (in certain cases an "hangup" signal when the other endpoint closes the communication (for example, a pipe). – HappyCactus May 02 '15 at 09:35

0 Answers0