-1

In my application, a Tun interface was created and the process keep reading the associated fd with read(2) in a select(2) loop. But, when I was debugging an issue in the application, I found that in some moments the read(2) operation on the Tun file descriptor can return zero. Is this possible and what's the condition it can happen?

Thanks in advance. woody

Woody Wu
  • 358
  • 3
  • 13
  • you need to provide code, no one is able to help you with a simple description like this. – Mox Nov 23 '18 at 02:09
  • Maybe I did not put it clear. Some info I provided is for giving a context, the real question in the post is: in what condition read(2) on a Tun file descriptor can return 0. If copy/paste the code, it would contain a lot of irrelevant information. – Woody Wu Nov 23 '18 at 05:57
  • The guideline here is that you have to show the code, else there is no way anyone can help you here. – Mox Nov 23 '18 at 05:58

1 Answers1

0

Here is the information from the manpage on read(2)click here

Return Value

On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number. It is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because read() was interrupted by a signal. On error, -1 is returned, and errno is set appropriately. In this case it is left unspecified whether the file position (if any) changes.

Community
  • 1
  • 1
Mox
  • 2,355
  • 2
  • 26
  • 42
  • Yes, I knew read(2) in general. But I don't understand what means EOF for a tun device which was created by the same process that called the read(2). – Woody Wu Nov 23 '18 at 09:14
  • EOF means end of file which indicates that the file offset is current at the end. This can mean there is no more data to be read. – Mox Nov 23 '18 at 10:15