EOF on any of natives file handles is an error.

Unless you can explain what EOF means on a tap device and why it isn't an error, I'd reject this PR.

Well the underlying (native) read operation does not return an error, since 0 is not listed as an error value in the posix documentation.. My vote would be to also continue with the read loop upon receiving a return value of 0. I have no idea why I am the only person, who has this behavior, but it is really annoying to use native when it crashes ever so often (;

The read operation is blocking, isn't it? Is there a timeout for this read operation to return with 0, or will this block infinitely?

read should only be called if data is available in the first place due to the interrupt based implementation around it. It should be non-blocking due to this as well. Anyway - this interrupt/poll based program flow is why I think zero is an error to begin with. It might be some strange and harmless race condition though.

I would suggest you check the tuntap implementations of Linux and BSD and find out why zero is returned.

Finally, I searched other tap users quickly and I think it was virtualbox who also ignored EOF on taps, so I expect it is in fact harmless.

For the record: with #2558 I do get this error as well if I run ifconfig in the test on an interface which has been freshly created on the host.

After reading the Linux implementation, I ACK ignoring the event, but not this implementation.
Please make it:

+    else if (nread == 0) {
+        DEBUG("_native_handle_tap_input: ignoring null-event");
+    }

addressed @LudwigOrtmann's comment

ACK

@LudwigOrtmann and Travis are happy => GO